Operating Systems

User and Operating System Interface

there are several ways for users to interface with the operating system. There are three fundamental approaches.
One provides a command-line interface, or command interpreter, that allows users to directly enter
commands to be performed by the operating system. The other
two allow users to interface with the operating system via a graphical user interface, or GUI.
1) Command Interpreters
Most operating systems, including Linux, UNIX, and Windows, treat the command interpreter as a special
program that is running when a process is initiated or when a user first logs on (on interactive systems). On
systems with multiple command interpreters to choose from, the interpreters are known as shells.
For example, on UNIX and Linux systems, a user may choose among several different shells, including the C
shell, Bourne-Again shell, Korn shell, and others. Most shells provide similar functionality. Figure below
shows the Bourne-Again (or bash) shell command interpreter being used on macOS.
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 various shells available on UNIX systems operate in this way. These
commands can be implemented in two general ways.
--In one approach, 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 commands
through 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. Thus, the UNIX
command to delete a file rm file.txt would search for a file called rm, load the file into memory, and execute it
with the parameter file.txt. The logic associated with the rm command would be defined completely by the code
in the file rm. In this way, programmers can add new commands to the system easily by creating new files with
the proper
program logic. The command-interpreter program, which can be small, does not have to be changed for new
commands to be added.
2)Graphical User Interface
A second strategy for interfacing with the operating system is through a user friendly graphical user interface,
or GUI. Here, rather than entering commands directly via a command-line interface, users employ a mouse-
based window and menu system characterized by a desktop metaphor. The user moves the mouse to position
its pointer on images, or icons, on the screen (the desktop) that represent programs, files, directories, and
system functions. Depending
on the mouse pointer’s location, clicking a button on the mouse can invoke a program, select a file or directory
—known as a folder—or pull down a menu that contains commands.
History:Graphical user interfaces first appeared due in part to research taking place in the early 1970s at Xerox
PARC research facility. The first GUI appeared on the Xerox Alto computer in 1973. However, graphical
interfaces became more widespread with the advent of Apple Macintosh computers in the 1980s. The user
interface for the Macintosh operating system has undergone various changes over the years, the most
significant being the adoption of the Aqua interface that appeared with macOS. Microsoft’s first version of
Windows— Version 1.0—was based on the addition of a GUI interface to the MS-DOS operating system. Later
versions of Windows have made significant changes in the appearance of the GUI along with several
enhancements in its functionality. Traditionally, UNIX systems have been dominated by command-line
interfaces. Various GUI interfaces are available, however, with significant development in GUI designs from
various open-source projects, such as K Desktop Environment (or KDE) and the GNOME desktop by the GNU
project. Both the KDE and GNOME desktops run on Linux and various UNIX systems and are available under
open-source licenses,which means their source code is readily available for reading and for modification under
specific license terms.
3)Touch-Screen Interface
Because a either a command-line interface or a mouse-and-keyboard system is impractical for most mobile
systems, smartphones and handheld tablet computers typically use a touch-screen interface. Here, users interact
by making gestures on the touch screen—for example, pressing and swiping fingers across the screen.
Although earlier smartphones included a physical keyboard, most smartphones and tablets now simulate a
keyboard on the touch screen.
Figure below illustrates the touch screen of the Apple iPhone. Both the iPad and the iPhone use the
Springboard touch-screen interface.
Choice of Interface
The choice of whether to use a command-line or GUI interface is mostly one of personal preference.
--System administrators who manage computers and power users who have deep knowledge of a system
frequently use the command-line interface. For them, it is more efficient, giving them faster access to the
activities they need to perform. Indeed, on some systems, only a subset
of system functions is available via the GUI, leaving the less common tasks to those who are command-line
knowledgeable. Further, command-line interfaces usually make repetitive tasks easier, in part because they
have their own programmability. For example, if a frequent task requires a set of commandline steps, those
steps can be recorded into a file, and that file can be run just like a program. The program is not compiled into
executable code but rather is interpreted by the command-line interface. These shell scripts are very common
on systems that are command-line oriented, such as UNIX and Linux.
-- In contrast, most Windows users are happy to use the Windows GUI environment and almost never use the
shell interface. Recent versions of the Windows operating system provide both a standard GUI for desktop and
traditional laptops and a touch screen for tablets. The various changes undergone by the Macintosh operating
systems also provide a nice study in contrast. Historically, Mac OS has not provided a command-line interface,
always requiring its users to interface with the operating system using its GUI. However,with the release of
macOS (which is in part implemented using a UNIX kernel), the operating system now provides both an Aqua
GUI and a command-line interface.
Figure below is a screenshot of the macOS GUI:

Although there are apps that provide a command-line interface for iOS and Android mobile systems, they are
rarely used. Instead, almost all users of mobile systems interact with their devices using the touch-screen
interface.
The user interface can vary from system to system and even from user to user within a system; however, it
typically is substantially removed from the actual system structure. The design of a useful and intuitive user
interface is therefore not a direct function of the operating system.
System Calls
System calls provide an interface to the services made available by an operating system. These calls are
generally available as functions written in C and C++, although certain low-level tasks (for example, tasks
where hardware must be accessed directly) may have to be written using assembly-language instructions.

Example:
The example below illustrates how system calls are used: writing a simple program to read data from one file
and copy them to another file. The first input that the program will need is the names of the two files: the input
file and the output file. These names can be specified in many ways, depending on the operating-system design.

-- One approach is to pass the names of the two files as part of the command—for example, the UNIX cp
command:
cp in.txt out.txt
This command copies the input file in.txt to the output file out.txt.
-- A second approach is for the program to ask the user for the names. In an interactive system, this approach
will require a sequence of system calls, first to write a prompting message on the screen and then to read from
the keyboard the characters that define the two files. On mouse-based and icon-based systems, a menu of file
names is usually displayed in a window. The user can then use the mouse to select the source name, and a
window can be opened for the destination name to be specified. This sequence requires many I/O system calls.
Once the two file names have been obtained, the program must open the input file and create and open the
output file. Each of these operations requires another system call. Possible error conditions for each system call
must be handled. For example, when the program tries to open the input file, it may find that there is no file of
that name or that the file is protected against access. In these cases, the program should output an error message
(another sequence
of system calls) and then terminate abnormally (another system call). If the input file exists, then we must
create a new output file. We may find that there is already an output file with the same name. This situation
may cause the program to abort (a system call), or we may delete the existing file (another system call) and
create a new one (yet another system call). Another option, in an interactive system, is to ask the user (via a
sequence of system calls to output the prompting message and to read the response from the terminal) whether
to replace the existing file or to abort the program.
When both files are set up, we enter a loop that reads from the input file (a system call) and writes to the output
file (another system call). Each read and write must return status information
regarding various possible error conditions. On input, the program may find that the end of the file has been
reached or that there was a hardware failure in the read (such as a parity error). The write operation may
encounter various errors, depending on the output device (for example, no more available disk space).
Finally, after the entire file is copied, the program may close both files (two system calls), write a message to
the console or window (more system calls), and finally terminate normally (the final system call). This system-
call sequence is shown in Figure below.
Application Programming Interface (API)
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 detail, 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 Windows API for Windows systems, the POSIX API for POSIX-based
systems (which include virtually all versions of UNIX, Linux, and macOS), and the Java API for programs that
run on the Java virtual machine. A programmer accesses an API via a library of code provided by the operating
system. In the case of UNIX and Linux for programs written in the C language, the library is called libc. Note
that—unless specified —the system-call names used throughout this text are generic examples. 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 Windows function CreateProcess() (which, unsurprisingly, is used to
create a new process) actually invokes the NTCreateProcess() system call in the Windows kernel.
Why would an application programmer prefer programming according to an API rather than invoking actual
system calls?
There are several reasons for doing so:
--One benefit concerns program portability. An application programmer
designing a program using an API can expect her program to compile and run on any system that supports the
same API (although, in reality, 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. Nevertheless, there often exists
a strong correlation between a function in the API and its associated system call within the kernel. In fact, many
of the POSIX and Windows APIs are similar to the native system calls provided by the UNIX, Linux, and
Windows operating systems.
--Another important factor in handling system calls is the run-time environment (RTE)—the full suite of
software needed to execute applications written in a given programming language, including its compilers or
interpreters as well as other software, such as libraries and loaders.
The RTE provides a system-call interface that serves as the link to system calls made available
by the operating system. The system-call interface intercepts function calls in the API and invokes the
necessary system calls within the operating system. Typically, a number is associated with each system call, and
the system-call interface maintains a table indexed according to these numbers. The system call interface then
invokes the intended system call in the operating-system kernel and returns the status of the system call.
The caller need know nothing about how the system call is implemented or what it does during execution.
Rather, the caller need only obey the API and understand what the operating system will do as a result of the
execution of that 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 RTE. The
relationship among an API, the system-call interface, and the operating system is shown in Figure below, 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. For example, to get input, we may need to specify the file or device to
use as the source, as well as the address and
length of the memory buffer into which the input should be read. Of course, the device or file and length may
be implicit in the 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 a parameter in a register (Figure below).
Linux uses a combination of these approaches. If there are five or fewer parameters, registers are used. If there
are more than five parameters, the block method is used. Parameters also can be placed, or pushed, onto a
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
System calls can be grouped roughly into six major categories:

1) Process control
2) Fil management
3) Device management
4) information maintenance
5) Communications,
6) protection.
Figure below summarizes the types of system calls normally provided by an operating system:
1) Process Control:
--A running program needs to be able to halt its execution either normally (end()) or abnormally (abort()). If a
system call is made to terminate the currently running program abnormally, or if the program runs into a
problem and causes an error trap, a dump of memory is sometimes taken and an error message generated. The
dump is written to a special log file on disk and may be examined by a debugger—a system program designed
to aid the programmer in finding and correcting errors, or bugs—to determine the cause of the problem.
--Under either normal or abnormal circumstances, the operating system must transfer control to the invoking
command interpreter. The command interpreter then reads the next command. In an interactive system, the
command interpreter simply continues with the next command; it is assumed that the user will issue an
appropriate command to respond to any error. In a GUI system, a pop-up window might alert the user to the
error and ask for guidance. Some systems may allow for special recovery actions in case an error occurs. If the
program discovers an error in its input and wants to terminate abnormally, it may also want to define an error
level. More severe errors can be indicated by a higher-level error parameter. It is then possible to combine
normal and abnormal termination by defining a normal termination as an error at level 0. The command
interpreter or a following program can use this error level to determine the next action automatically.
--A process executing one program may want to load() and execute() another program. This feature allows the
command interpreter to execute a program as directed by, for example, a user command or the click of a mouse.
The control is returned to that point where the existing program is lost, saved, or allowed to continue execution
concurrently with the new program.
--If control returns to the existing program when the new program terminates, we must save the memory image
of the existing program; thus, we have effectively created a mechanism for one program to call another
program. If both programs continue concurrently, we have created a new process to be multi-programmed.
Often, there is a system call specifically for this purpose
(create process()).
--If we create a new process, or perhaps even a set of processes, we should be able to control its execution. This
control requires the ability to determine and reset the attributes of a process, including the process’s priority, its
maximum allowable execution time, and so on (get process attributes() and set process attributes()).We may
also want to terminate a process that we created (terminate process()) if we find that it is incorrect or is no
longer needed.
--Having created new processes, we may need to wait for them to finish their execution. We may want to wait
for a certain amount of time to pass (wait time()). More probably, we will want to wait for a specific event to
occur (wait event()). The processes should then signal when that event has
occurred (signal event()).
--Quite often, two or more processes may share data. To ensure the integrity of the data being shared, operating
systems often provide system calls allowing a process to lock shared data. Then, no other process can access
the data until the lock is released. Typically, such system calls include acquire lock() and release lock().

Examples of facets and variations of process control:

1)Single tasking system: The Arduino is a simple hardware platform consisting of a microcontroller along with
input sensors that respond to a variety of events, such as changes to light, temperature, and barometric pressure,
to just name a few. To write a program for the Arduino,
first the program on a PC is written and then uploaded the compiled program (known
as a sketch) from the PC to the Arduino’s flash memory via a USB connection. The standard Arduino platform
does not provide an operating system; instead, a small piece of software known as a boot loader loads the
sketch into a specific region in the Arduino’s memory (Figure below).
Once the sketch has been loaded, it begins running, waiting for the events that it is programmed to respond to.
For example, if the Arduino’s temperature sensor detects that the temperature
has exceeded a certain threshold, the sketch may have the Arduino start the motor for a fan. An Arduino is
considered a single-tasking system, as only one sketch can be present in memory at a time; if another sketch is
loaded, it replaces the existing sketch. Furthermore, the Arduino provides no user interface beyond hardware
input sensors.
2)Multi-tasking system: FreeBSD (derived from Berkeley UNIX) is an example of a multitasking
system. When a user logs on to the system, the shell of the user’s choice is run, awaiting commands and
running programs the user requests. However, since FreeBSD is a multitasking system, the command
interpreter may continue running while another program is executed (Figure below).
To start a new process, the shell executes a fork() system call. Then, the selected program is loaded into
memory via an exec() system call, and the program is executed. Depending on how the command was issued,
the shell then either waits for the process to finish or runs the process “in the background.” In the latter case,
the shell immediately waits for another command to be entered. When a process is running in the background,
it cannot receive input directly from the keyboard, because the shell is using this resource. I/O is therefore done
through files or through a GUI interface. Meanwhile, the user is free to ask the shell to run other programs, to
monitor the progress of the running process, to change that program’s priority, and so on. When the process is
done, it executes an exit() system call to terminate, returning to the invoking process a status code of 0 or a
nonzero error code. This status or error code is then available to the shell or other programs.
2) File Management: Here, several common system calls dealing with files have been identified.
We first need to be able to create() and delete() files. Either system call requires the name of the file and
perhaps some of the file’s attributes. Once the file is created, we need to open() it and to use it. We may also
read(), write(), or reposition() (rewind or skip to the end of the file, for example). Finally, we need to close() the
file, indicating that we are no longer using it.

We may need these same sets of operations for directories if we have a directory structure for organizing files in
the file system. In addition, for either files or directories, we need to be able to determine the values of various
attributes and perhaps to set them if necessary. File attributes include the file name, file type, protection codes,
accounting information, and so on. At least
two system calls, get file attributes() and set file attributes(), are required for this function. Some operating
systems provide many more calls, such as calls for file move() and copy(). Others might provide an API that
performs those operations using code and other system calls, and others might provide system programs to
perform the tasks. If the system programs are callable by other programs, then each can be considered an API
by other system programs.
2) Device Management: A process may need several resources to execute—main memory, disk drives, access
to files, and so on. If the resources are available, they can be granted, and control can be returned to the user
process. Otherwise, the process will have to wait until sufficient resources are available.
The various resources controlled by the operating system can be thought of as devices. Some of these devices
are physical devices (for example, disk drives), while others can be thought of as abstract or virtual devices (for
example, files).A system with multiple users may require us to first request() a device, to ensure exclusive use
of it. After we are finished with the device, we
release() it. These functions are similar to the open() and close() system calls for files. Other operating systems
allow unmanaged access to devices.
Once the device has been requested (and allocated to us), we can read(), write(), and (possibly) reposition() the
device, just as we can with files. In fact, the similarity between I/O devices and files is so great that many
operating systems, including UNIX, merge the two into a combined file–device structure. In this case, a set of
system calls is used on both files and devices. Sometimes, I/O devices are identified by special file names,
directory placement, or file
attributes.
The user interface can also make files and devices appear to be similar, even though the underlying system calls
are dissimilar. This is another example of the many design decisions that go into building an operating system
and user interface.
3) Information Maintenance: Many system calls exist simply for the purpose of transferring information
between the user program and the operating system. For example, most systems
have a system call to return the current time() and date(). Other system calls may return information about the
system, such as the version number of the operating system, the amount of free memory or disk space, and so
on.
Another set of system calls is helpful in debugging a program. Many systems provide system calls to dump()
memory. This provision is useful for debugging. The program strace, which is available on Linux systems, lists
each system call as it is executed. Even microprocessors provide a CPU mode, known as single step, in which a
trap is executed by the CPU after every
instruction. The trap is usually caught by a debugger.
Many operating systems provide a time profile of a program to indicate the amount of time that the program
executes at a particular location or set of locations. A time profile requires either a tracing facility or regular
timer interrupts. At every occurrence of the timer interrupt, the value of the program counter is recorded. With
sufficiently frequent timer interrupts, a statistical
picture of the time spent on various parts of the program can be obtained.
In addition, the operating system keeps information about all its processes, and system calls are used to access
this information. Generally, calls are also used to get and set the process information (get process attributes()
and set process attributes()).
4) Communication: There are two common models of interprocess communication: the message passing
model and the shared-memory model. In the message-passing model,
the communicating processes exchange messages with one another to transfer information. Messages can be
exchanged between the processes either directly or indirectly through a common mailbox. Before
communication can take place, a connection must be opened. The name of the other communicator must be
known, be it another process on the same system or a process on another computer connected by a
communications network. Each computer in
a network has a host name by which it is commonly known. A host also has a network identifier, such as an IP
address. Similarly, each process has a process name, and this name is translated into an identifier by which the
operating system can refer to the process. The get hostid() and get processid() system calls do this translation.
The identifiers are then passed to the general purpose
open() and close() calls provided by the file system or to specific open connection() and close connection()
system calls, depending on the system’s model of communication. The recipient process usually must give its
permission for communication to take place with an accept connection() call. Most processes that will be
receiving connections are special-purpose daemons, which are system programs provided for that purpose.
They execute a wait for connection() call and are awakened when a connection is made. The source of the
communication, known as the client, and the receiving daemon, known as a server, then exchange messages by
using read message() and write message() system calls. The close connection() call terminates the
communication.
In the shared-memory model, processes use shared memory create() and shared memory attach() system calls
to create and gain access to regions of memory owned by other processes. Recall that, normally, the operating
system tries to prevent one process from accessing another process’s memory. Shared memory requires that two
or more processes agree to remove this
restriction. They can then exchange information by reading and writing data in the shared areas. The form of
the data is determined by the processes and is not under the operating system’s control. The processes are also
responsible for ensuring that they are not writing to the same location simultaneously.
Both of the models just discussed are common in operating systems, and most systems implement both.
Message passing is useful for exchanging smaller amounts of data, because no conflicts need be avoided. It is
also easier to implement than is shared memory for intercomputer communication. Shared memory allows
maximum speed and convenience of communication,
since it can be done at memory transfer speeds when it takes place within a computer. Problems exist, however,
in the areas of protection and synchronization between the processes sharing memory.
4) Protection: Protection provides a mechanism for controlling access to the resources provided
by a computer system. Historically, protection was a concern only on multiprogrammed computer systems with
several users. However, with the advent of networking and the Internet, all computer systems, from servers to
mobile handheld devices, must be concerned with protection. Typically, system calls providing protection
include set permission() and get permission(), which manipulate the permission settings of resources such as
files and disks. The allow user() and deny user() system calls specify whether particular users can—or cannot—
be allowed access to certain resources.