Introduction to Operating Systems

An operating system is a program that manages the computer hardware. It also provides a
basis for application programs and acts as an intermediary between the computer user and
computer hardware.
➢ Mainframe OS are designed primarily to optimize utilization of hardware.
➢ Personal Computer (PC) operating systems support complex games, business
applications and everything in between.
➢ Operating systems for handheld computers are designed to provide an environment in
which a user can easily interface/ interact with the computer to execute programs.
Thus, some operating systems are designed to be convenient, others to be efficient, and
others some combination of the two.

Operating System’s role in the overall Computer System

A computer system can be divided roughly into four components: the hardware, the
operating system, the application programs, and the users.

➢ Users: People, other computers, machines, etc.

➢ Application Programs:: Compilers, Database Systems, Video Games, business
applications, we browsers, etc., – define the ways in which these resources are used to
solve user’s computing problems.
➢ System Programs: Shells, editors, compilers, development tools, etc.
➢ Operating System: The system program which controls and coordinates the use of
hardware among application programs for various users.
➢ The hardware – the CPU, the memory, and the I/O devices – provides the basic
computing resources for the system.
We can also view a computer system as consisting of hardware, software, and data. The
operating system provides the means proper use of these resources in the operation of the
computer system. An operating system is like a government. Like a government, it performs
no useful function by itself. It simply provides an environment within which other programs
can do useful work. Firmware (BIOS) is a software which is permanently stored on chip but
upgradable. It loads operating system during the boot.

Layered View of Operating System Services

To understand more fully the operating system’s role, we next explore operating systems
from three viewpoints: that of the user, hardware and that of the system.
User View
The OS is an interface, hides the details which must be performed and presents a virtual
machine to the user that makes easier to use. OS provides the following services to the user:
➢ Execution of a program
➢ Access to I/O devices
➢ Controlled access to flies
➢ Error detection (hardware failures, and software errors)
The user’s view of the computer system varies according to the interface being used.
➢ Personal Computers consist of a monitor, keyboard, mouse, and system unit. Such a
system is designed for one user to monopolize its resources. The goal is to maximize the
work (or play) that the user is performing. In this case, the operating system is designed
mostly for ease of use, with some attention paid to performance and none paid to
resource utilization – how various hardware and software resources are shared. Rather
than the requirements of multiple users, such systems are optimized for the single-user
experience.
➢ Mainframe or a minicomputer has a terminal connected to it through which users can
interact. Other users can access the same computer through other terminals. These users
share resources and may exchange information. The operating system here is designed
to maximize resource utilization – to assure that all available CPU time, memory, and
I/O are used efficiently, and that no individual user takes more than his/her fair share.
➢ Workstations are connected to networks of other workstations and servers with which
users can interact. These users have dedicated resources at their disposal, but they also
share resources such as networking and servers – file, compute, and print servers.
 Therefore, their operating system is designed to compromise between individual
usability and resource utilization.
➢ Recently, many varieties of handheld computers have come into fashion. Most of these
devices are standalone units for individual users. Some are connected to networks,
either directly by wire or (more often) through wireless modems and networking.
Because of power, speed, interface limitations, they perform relatively few remote
operations. Their operating systems are designed mostly for individual usability, but
performance per unit of battery life is important as well.
➢ Some computers have little or no user view. For example, embedded computers in home
devices and automobiles may have numeric keypads and may turn indicator lights on or
off to show status, but they and their operating systems are designed primarily to run
without user intervention.
Hardware View
The OS manages the resources efficiently in order to offer the services to the user programs.
OS acts as resource manager:
➢ Allocation of resources
➢ Controlling the execution of a program
➢ Controls the operation of I/O devices
➢ Protection of resources
➢ Monitors the data
System View
OS is a program that functions in the same way as other programs. It is a set of instructions
that are executed by the processor. OS acts as a program to perform the following:
➢ Hardware upgrades
➢ New services
➢ Fixes the issue of resources
➢ Controls the user and hardware operations
Goals of Operating System: Primary goal is convenience and secondary goal is efficiency.

History of Operating System

➢ Tube Based (1945-1955): Hardware can run one program at a time (Serial processing)
➢ Transistors based (1955-1965): High level languages like Fortran (Batch processing)
➢ IC Circuits based (1965-1980): Time sharing and Multiprogramming,
➢ Working & PCs (1980-2000): Real-time, embedded, parallel and network programming
➢ Networking (2000-present): Parallel computer architectures. High speed networks
Types of Operating System
➢ Serial OS: Allow the hardware to run only one process at a time.
➢ Batch OS: The operating system in early computers was simple. Its major task was to
transfer control automatically from one job to the next. The operating system was
always in memory. To speed up processing, processes of similar functionality and
requirements were grouped as batches. The Batch OS used to execute them batch by
batch. During the 1960s people who wanted to execute computer processes used to
approach an operator. At the end of the day, the operator classifies all the processes
received to be executed into batches and then executes them.
❖ There is lack of interaction between the user and the job while it is executing.
❖ The CPU remains idle when a batch performs an I/O output operation. Only after
completely executing a batch, the CPU starts executing the next batch. Thus, CPU
utilization was slow.
❖ Batch systems are appropriate for executing large jobs that need little interaction. Ex:
Fortran, IBSYS709x, IBM OS/2
➢ Multiprogramming OS: Sharing the processor, when two or more programs reside in
memory at the same time, is referred as multiprogramming. Multiprogramming assumes
a single shared processor. A job pool on the disk consists of several jobs that are ready
to be executed. Subsets of these jobs reside in the main memory for execution. The OS
picks and executes one of the jobs in the main memory. If several jobs are ready to be
brought into memory and there is not enough room for all of them, then the system must
choose among them. Making this decision is job scheduling. The OS can implement
either ‘preemptive execution’ (execution of other jobs when the current running job
goes for I/O) or ‘non-preemptive execution’ (CPU remains idle when the current
running job goes for I/O).
➢ Multi-tasking (Timesharing system) OS: A multitasking OS is a logical extension to a
multiprogramming OS. Multitasking is when multiple jobs are executed by the CPU
simultaneously by switching between them. Switches occur so frequently that the users
may interact with each program while it is running. A timeshared operating system
allows many users to share the computer simultaneously. Since each action or command
in a timeshared system tends to be short, only a little CPU time is needed for each user.
As the system switches so rapidly from one user to the next, each user is given the
impression that he/she has her own computer, whereas one computer is being shared
among many users.
➢ Real-time OS: Real-time systems are dedicated operating systems which must guarantee
response to events within fixed periods of time to ensure correct performance. They can
be classified as “Hard” or “Soft”. While Hard Real-time OS is rigid in ensuring the
definiteness of process execution time, soft real-time OS is a way more lenient.
Satellites and Missile systems: Hard Realtime OS, Banking systems: Soft Realtime OS.
➢ Parallel systems (multiprocessor) OS: Multiprocessor system have more than one
processor in one close communication, sharing the computer bus, the clock, and
sometimes memory and peripheral devices. These systems are referred to as tightly
coupled systems. This system leads to increased throughput i.e., we get more work done
in a short period of time by increasing the number of processors. Functions can be
distributed among several processors now. The failure of one processor will not halt the
system but will rather slow it down. The ability to continue providing service
proportional to the level of surviving hardware is called graceful degradation. Systems
that are designed for graceful degradation are called fault tolerant.
❖ Symmetric Multiprocessing Model: In this each processor runs an identical copy of
the operating system and these copies communicate with one another as needed.
❖ Asymmetric processing model: In this model each processor is assigned a specific
task. A master processor controls the system; the other processors either look to
master for instruction or have predefined tasks. Thus scheme defines a master-slave
relationship. Master processor schedules and allocates work to the slave processors.
➢ Distributed OS: A distributed environment refers to multiple independent CPUs or
processors in a computer system located at different geographical locations not sharing
either their memory or clock. A single OS manages the communications between the
processors. They communicate with each other through various communication lines.
They are also referred to as loosely coupled systems.
➢ Clustered OS: Clustered OS is a distributed OS with the multiple independent CPUs
located at the same geographic location to perform a complex task.
➢ Network OS: Network OS refers to multiple independent CPUs or processors in a
computer system located at different geographical locations not sharing either their
memory or clock. Each CPU has individual operating systems. It allows interaction
between the machines by having a common communication architecture.
➢ Embedded OS: Embedded Operating Systems are the ones which perform a specific
task with least user – intervention.
➢ Handheld OS: Operating systems for handheld computers are designed to provide an
environment in which a user can easily interface/ interact with the computer to execute
programs. Handheld systems include Personal Digital Assistants(PDAs), such as Palm-
Pilots or Cellular Telephones with connectivity to a network such as the Internet. They
are usually of limited size due to which most handheld devices have a small amount of
memory, include slow processors, and feature small display screens.

Operating System Services

An operating system provides an environment for the execution of programs. It provides
certain services to programs and to users of those programs. One set operating-system
services provides functions that are helpful to the user.
➢ User Interface: Almost all operating systems have a user interface (UI). This interface
can take several forms:
❖ Command-Line Interface (CLI): CLI or command interpreter allows users to directly
enter commands that are to be performed by the operating system. Some operating
systems include the command interpreter in the kernel. Others, such as Windows XP
and UNIX, treat the command interpreter as a special program. On systems with
multiple command interpreters to choose from, the interpreters are known as shells.
Most shells provide similar functionality with only minor differences; most users
choose a shell based on personal preference. The main function of the command
interpreter is to get and execute the next user-specified command. Many of the
commands given at this level manipulate files: create, delete, list, print, copy,
execute, and so on. The MS-DOS and UNIX shells operate in this way. There are
two general ways in which these commands can be implemented:
The command interpreter itself contains the code to execute the command. For
example, a command to delete a file may cause the command interpreter to jump
to a section of its code that sets up the parameters and makes the appropriate
system call. In this case, the number of commands that can be given determines
the size of the command interpreter, since each command requires its own
implementing code.
An alternative approach – used by UNIX, among other operating systems –
implements most of the commands using system programs. In this case, the
command interpreter does not understand the command in any way; it merely
uses the command to identify a file to be loaded into memory and executed. In
this way, programmers can create new commands to the system easily by creating
new files with proper names. The command interpreter program, which can be
small, does not have to be changed for new commands to be added.
❖ Batch Interface: Batch interfaces are non-interactive user interfaces, where the user
specifies all the details of the batch job in advance to batch processing and receives
the output when all the processing is done. The computer does not prompt for further
input after the processing has started.
❖ Graphical User Interface (GUI): Rather than having users directly enter commands
via a command-line interface, a GUI provides a mouse-based window-and-menu
system as an interface. A GUI provides a desktop metaphor where the mouse is
moved to position on images, icons, on the screen (desktop) that represent programs,
files, directories, and system functions.
The choice of whether to use a command-line interface or GUI is mostly one of
personal preference. As a very general rule, UNIX prefers command line whereas
Windows users are pleased to use the GUI. Historically, Mac OS has not provided a
CLI but with the release of Mac OS X (which is in part implemented using a UNIX
 kernel), the OS now provides both a new aqua interface and a command line interface as
well.
➢ Program Execution
➢ I/O operations
➢ File system manipulation
➢ Communications
➢ Error detection
➢ Resource allocation
➢ Accounting
➢ Protection and Security

Spooling
Spooling is the acronym for Simultaneous Peripheral Operations Online. I/O devices are
relatively slow compared to the CPU. So, involving CPU in receiving and sending
information through I/O devices may waste valuable time of CPU. Therefore, instead of
involving CPU for input and output of data, if we reserve some space in the secondary
memory (disk) wherein we can directly store the input information received from multiple
input devices, CPU can spend time wholly in executing programs. Whenever the
information received from peripheral devices stored in the disk is required by the CPU, it
can be loaded into the main memory and can be used thereafter for processing. After the
usage, the output data can be stored back into the disk, which can later be sent to the
peripheral output devices directly from the disk. Thus, non-involvement of CPU in I/O of
information through peripheral devices increases the processing speed.

Dual-Mode Operations
To ensure the proper execution of the operating system, we must be able to distinguish
between the execution of operating system code and user-defined code. The approach taken
by most computer systems is to provide hardware support that allows us to differentiate
among various modes of execution. We need two separate modes of operation:
➢ User mode (non-privileged mode)
➢ Kernel mode (supervisor/ system/privileged/ protected/ monitor mode)
A bit called the mode bit, is added to the hardware of the computer to indicate the current
mode: kernel (0) or user (1). With the mode bit, we can distinguish between a task that is
executed on behalf of the operating system and one that is executed on behalf of the user.
When the computer system is executing on behalf of a user application, the system is in
user mode. However, when a user application requests a service from the operating system
(via a system call), there must be a transition from user to kernel mode to fulfill the request.
As we shall see, this architectural enhancement is useful for many other aspects of system
operations as well.
At system boot time, the hardware starts in kernel mode. The operating system is then
loaded and starts user applications in user mode. Whenever a trap or interrupt occurs, the
hardware switches from user mode to kernel mode (i.e., changes the state of mode bit to 0).
Thus, whenever the operating system gains control of the computer, it is in kernel mode.
The system always switches to user mode (by setting the mode bit to 1) before passing
control to a user program.
The dual mode of operation provides us with the means for protecting the operating system
from errant users. We accomplish this protection by designating some of the machine
instructions that may cause harm as privileged instructions.

The hardware allows privileged instructions to be executed only in kernel mode. If an

attempt is made to execute a privileged instruction in user mode, the hardware does not
execute the instruction but rather treats it as illegal and traps it to the operating system. The
instruction to switch to user mode is an example of a privileged instruction.
➢ Privileged Instructions: I/O control, timers, interrupts, clear memory, set system lock,
remove process from memory, changing memory location of a process etc.
➢ Non-privileged Instructions: Read Clock, Generate trap, User to Kernel mode switch,
Reading the states of the CPU, sending the final printout to the printer, etc.
We can now see the life cycle of instruction execution in a computer system. Initial control
is within the operating system, where instructions are executed in kernel mode. When
control is given to a user application, the mode is set to user mode. Eventually, control is
switched back to the operating system via an interrupt, a trap, or a system call.
System calls provide the means for a user program to ask the operating system to perform
tasks reserved for the operating system on the user program’s behalf. A system call is
invoked in a variety of ways depending on the functionality provided by the underlying
processor. In all forms, it is the method used by a process to request an action that can only
be performed by the operating system. A system call usually takes the form of a trap to a
specific location in the interrupt vector. This trap can be executed by a generic trap
instruction, although some systems of the MIPS R200 family have a special syscall
instruction.
When a system call is executed, it is treated by the hardware as a software interrupt. Control
passes through the interrupt vector to a service routine in the operating system, and the
mode bit is set to kernel mode. The system call service routine is a part of the operating
system. The kernel examines the interrupt instruction to determine what system call has
occurred; a parameter indicates what type of service the user program is requesting.
Additional information needed for the request may be passed in registers, on the stack, or in
memory (with pointers to the memory locations passed in the registers). The kernel verifies
that with the parameters are correct and legal, executes the request, and returns the control,
back to the instruction following the system call.
The lack of hardware supported dual mode can cause serious shortcomings in an operating
system. A user program running away can wipe out the operating system by writing over it
with data; and multiple programs are able to write to a device at the same time, with
possible disastrous results. Dual mode operation and provides greater protection for the
operating system.
Once hardware protection is in place, errors violating modes are detected by the hardware,
these errors are normally handled by the operating system if a user program fails in some
way such as by trying either to execute an illegal instruction or to access memory that is not
in the user’s addressed space. An appropriate error message is given, and the memory of the
program may be dumped. The memory dump is usually written to a file so that the user or
programmer can examine it and perhaps correct it and restart the program.

System Calls
System calls provide an interface to the services made available by an operating system.
These calls are generally available as routines written in C and C++ although certain low-
level tasks (for example, tasks where hardware must be accessed directly), may need to be
written using assembly language instructions. Before how an operating system makes
system calls available, lets first use an example to illustrate how system calls are used:
writing a simple program to read data from a file and copy them to another file.
As we can see, even simple programs may make heavy use of the operating system.
Frequently, systems execute thousands of system-calls per second.
Most programmers never see this level of details. However, typically application developers
design programs according to an Application Programming Interface (API). The API
specifies a set of functions that are available to an application programmer including the
parameters that are passed to each function and the return values the programmer can
expect. Three of the most common APIs available to application programmers are the
Win32 API for windows systems, the POSIX API for POSIX – based systems (which
includes virtually all versions of UNIX, LINUX, and MacOS X), and the Java API for
designing programs that run on the Java virtual machine.
Each operating system has its own name for each system call. Behind the scenes, the
functions that make up an API typically invoke the actual system calls on behalf of the
application programmer. For example, the Win32 function Create Process() (which
unsurprisingly is used to create a new process) calls the NT Create Process() system call in
the Windows kernel.
Why would an application programmer prefer programming according to an API rather that
invoking actual system calls? There are several reasons for doing so. One benefit of
programming according to an API concerns program portability: an application programmer
is designing a program using an API can expect her program to compile and run on any
system that supports the same API (although, architectural differences often make this more
difficult than it may appear). Furthermore, actual system calls can often be more detailed
and difficult to work with than the API available to an application programmer.
The run-time support system (a set of functions built into libraries included with a compiler)
for most programming languages provides a system call interface that serves as the link to
system calls made available by the operating system. The system call interface intersects
function calls in the API and invokes the necessary system call within the operating system.
The system call interface then invokes the intended system call in the operating system
kernel and returns the status of the system call and any return values.
The caller needs to know nothing about how the system call is implemented or what it does
during execution. Rather, it just needs to obey the API and understand what the operating
system will do because of the execution of the system call. Thus, most of the details of the
operating system interface are hidden from the programmer by the API and are managed by
the runtime support library. The relationship between an API, the system call interface and
the operating system are shown in the figure above which illustrates how the operating
system handles a user application invoking the open() system call.
System calls occur in different ways depending on the computer in use. Often, more
information is required than simply the identity of the desired system call. The exact type
and amount of information vary according to the particular operating system and call.
Three general methods are used to pass parameters to the operating system. The simplest
approach is to pass the parameters in registers. In some cases, however, there may be more
parameters than registers. In these cases, the parameters are generally stored in a block or
table, in memory, and the address of the block is passed as parameter in a register. This is
the approach taken by LINUX and SOLARIS. Parameters also can be placed or pushed
onto the stack by the program and popped off the stack by the operating system.
Some operating systems prefer the block or stack method, because those approaches do not
limit the number or length of parameters being passed.

Types of System Calls

Example of Standard C Library

The standard C library provides a portion of the system call interface for many versions of
UNIX and LINUX. As an example, lots assume a C program invokes the printf() statement.
The C library intercepts this call and invokes the necessary system calls in the operating
system – in this instance, the write() system call. The C library takes the value returned by
write() and passes it back to the user program.

The fork() system call

System call fork() is used to create processes. It takes no arguments and returns a process
id. The purpose of fork() is to create a new process which becomes the child process of the
caller. After a new child process is executed both processes will execute the next instruction
following the fork() system call. Therefore, we must distinguish the parent from the child.
This can be done by testing the returned value of fork():
➢ If fork() returns -ve value, the creation of a child process was unsuccessful
➢ If fork() returns 0, creation of child process was successful, we are now in child process
➢ If fork() returns +ve, it is the process id of the child process created and we are currently
in the parent process.
The returned process ID is of type pid_t defined in sys/types.h. Normally, the process ID is
an integer. Moreover, a process can use getpid() to retrieve the process ID assigned to this
process. Therefore, after the system call to fork(), a simple test can tell which process is the
child. Please note that UNIX will make an exact copy of the parent’s address space and give
it to the child. Therefore, the parent and child processes have separate address spaces.
The exec() system call
The exec family of functions replace the current process with a new process. This system
call simply replaces the current process with a new program – the pid does not change the
exec() is issued by the calling process and what is executed is referred to as the new
program – not the new process since no new process is created. It is important to realize that
control is not passed back to the calling process unless an error occurred with the exec()
call. In case of an error, the exec() returns a value back to the calling process. If no error
occurs, the calling process is lost. The versions of exec are:

➢ int execl(const char* path, const char* arg, …)

➢ int execlp(const char* file, const char* arg, …)
➢ int execle(const char* path, const char* arg, …, char* const envp[])
➢ int execv(const char* path, const char* argv[])
➢ int execvp(const char* file, const char* argv[])
➢ int execvpe(const char* file, const char* argv[], char *const envp[])
Other System calls
➢ exit: exit tells the operating system to terminate the current process
➢ wait: wait allows a parent to wait for and detect the termination of child processes
➢ signal: signal allows a process to detect signals, which include software exceptions,
user-defined signals, and death of child signals.
➢ kill: kill sends a signal to a specified process. The signal can usually be detected with
signal. It does not kill the process unless the signal is a kill (or terminate) signal.

Interrupts
There are two types of Interrupts:
➢ Interrupt: Interrupt is hardware generated which changes the flow of execution within
the system. Interrupt handler deals with hardware generated interrupts to control such
interrupts. Interrupt can be used to signal the completion of I/O.
❖ External event
 ❖ Asynchronous event
❖ Independent of the currently executed process instructions
❖ Ex: Clock Interrupt, I/O interrupt and Memory fault.
➢ Trap: Trap is a software generated signal either to call operating system routines or to
catch the arithmetic errors.
❖ Exceptions and system calls
❖ Synchronous event
❖ Internal (exceptions) events or external events

Booting of OS
Hardware doesn’t know where the operating system resides and how to load it. Hence it
needs a special program to do this job i.e., a
bootstrap loader. Ex: BIOS (Boot Input Output
System). Bootstrap loader locates the kernel,
loads it into main memory and starts its
execution. In some systems, a simple
bootstrap loader fetches a more complex boot
program from disk, which in turn loads the
kernel.
Booting Process
➢ Reset event on CPU (power up, reboot) causes instruction register to be loaded with a
predefined memory location. It contains a jump instruction that transfers execution to
the location of Bootstrap program.
➢ This program is form of ROM, since RAM is in unknown state at system startup. ROM
is convenient as it needs no initialization and can't be affected by virus.
➢ Run diagnostics to determine state of machine. If diagnostics pass, booting continues.
➢ Runs a Power-On Self-Test (POST) to check the devices that the computer will rely on,
are functioning.
➢ BIOS goes through a preconfigured list of devices until it finds one that is bootable. If it
finds no such device, an error is given and the boot process stops.
➢ Initializes CPU registers, device controllers and contents of the main memory. After
this, it loads the OS.
➢ On finding a bootable device, the BIOS loads and executes its boot sector. In the case of
a hard drive, this is referred to as the Master Boot Record (MBR).
➢ The MBR code checks the partition table for an active partition. If one found, the MBR
code loads that partitions boot sector and executes it.
➢ The boot sector is often operating system specific, however in most operating systems
its main function is to load and execute a kernel, which continues to startup.
➢ If there is no active partition or the active partition’s boot sector is invalid, the MBR
may load secondary boot load and pass control to it and this secondary boot loader will
select a partition (often why user input) and load its boot sector.
➢ Examples of secondary boot loaders:
❖ GRUB: GRand Unified Bootloader
❖ LILO: LInux LOader
❖ NTLDR: NT LoaDeR
➢ Systems such as cellular phones, PDAs and game consoles store entire OS on ROM.
Done only for small OS, simple supporting hardware, and rugged operation.
➢ Changing bootstrap code would require changing ROM chips.

Types of Kernel Designs

➢ Monolithic kernel:
❖ All services operate in kernel space
❖ Good performance
❖ Disadvantages: Dependencies between system component. Complex and huge
(millions of lines of code)
➢ Microkernel:
❖ Minimalist approach
❖ IPC, virtual memory, thread scheduling
❖ Put the rest into user space
❖ Device drivers, networking, file system, user interface
❖ More stable with less services in kernel space
❖ Disadvantages: lots of system calls and context switches
❖ Example: Mach, L4, AmigaOS, Minix, K42.
➢ Hybrid kernel: It combines the best of both worlds
❖ Speed and simple design of a monolithic kernel
❖ Modularity and stability of microkernel
❖ Still similar to a monolithic kernel
❖ Example: Windows NT, NetWare, BeOS
➢ Exokernel:
❖ Follows end-to-end principle
❖ Extremely minimal
❖ Fewest hardware abstractions as possible
❖ Just allocates physical resources to apps
❖ Disadvantages: more work for application developers
❖ Example: Nemesis, ExOS