Summarize these pages to 4 or 5 pages

User and Operating-System Interface We mentioned earlier that there are several ways for users to interface with the operating system. Here, we discuss two 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 allows users to interface with the operating system via a graphical user interface, or GUI. 2.2.1 Command Interpreters Some operating systems include the command interpreter in the kernel. Others, such as Windows and UNIX, treat the command interpreter as a special program that is running when a job 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 Bourne shell, C shell, Bourne-Again shell, Korn shell, and others. Third-party shells and free user-written shells are also available. Most shells provide similar functionality, and a user's choice of which shell to use is generally based on personal preference. Figure 2.2 shows the Bourne shell command interpreter being used on Solaris 10. 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. 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 function associated with the rm command would 2.2 User and Operating-System Interface 59 Figure 2.2 The Boume shell command interpreter in Soirais 10. be defined completely by the code in the file ra. In this way, programmers can add new commands to the system easily by creating new files with the proper names. The command-interpreter program, which can be small, does not have to be changed for new commands to be added. 2.2.2 Graphical User Interfaces A second strategy for interfacing with the operating system is through a userfriendly graphical user interface, or cul. Here, rather than entering commands directly via a command-line interface, users employ a mouse-based windowand-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. Graphical user interfaces first appeared due in part to research taking place in the early 1970 s at Xerox PABC research facility. The first GUT 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 (Mac OS) has undergone various changes over the years, the most significant being the adoption of the Aqua interface that appeared with Mac csx. 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 cosmetic Chapter 2 Operating-System Structures changes in the appearance of the GUI along with several enhancements in its functionality. Because a mouse is impractical for most mobile systems, smartphones and handheld tablet computers typically use a touchsereen interface. Here, users interact by making gestures on the touchscreen-for example, pressing and swiping fingers across the screen. Figure 2.3 illustrates the touchscreen of the Apple iPad. Whereas earlier smartphones included a physical keyboard, most smartphones now simulate a keyboard on the touchscreen. Traditionally, UNIX systems have been dominated by command-line interfaces. Various GUT interfaces are available, however. These include the Common Desktop Environment (CDE) and X-Windows systems, which are common on commercial versions of UND, such as Solaris and IBM's AIX system. In addition, there has been 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. 2.2.3 Choice of Interface The choice of whether to use a command-line or CUI 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 GUL, leaving the less common tasks to those who are command-line knowledgeable. Further, commandline interfaces usually make repetitive tasks easier, in part because they have their own programmability. For example, if a frequent task requires a set of command-line 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 seripts ane 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 Gul environment and almost never use the MS-DOS shell interface. The various changes undergone by the Macintosh operating systems 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 GUL. However, with the release of Mac os X (which is in part implemented using a UNIX kernel), the operating system now provides both a Aqua interface and a command-line interface. Figure 2.4 is a screenshot of the Mac os X cUI. 62 Chapter 2 Operating-System Structures The user interface can vary from system to system and even from user to user within a system. It typically is substantially removed from the actual system structure. The design of a useful and friendly user interface is therefore not a direct function of the operating system. In this book, we concentrate on the fundamental problems of providing adequate service to user programs. From the point of view of the operating system, we do not distinguish between user programs and system programs. 2.3 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 have to be written using assembly-language instructions. Before we discuss how an operating system makes system calls available, let's first use an example to illustrate 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 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 nead from the keyboard the characters that define the two files. On mouse-bused 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 1/O system calls. Once the two file names have been obtained, the program must open the input file and create the output file. Each of these operations requires another system call. Possible error conditions for each operation can require additional system calls. When the program tries to open the input file, for example, 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 print a message on the console (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 disk space). Finally, after the entire file is copied, the program may close both files (another system call), 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 2.5. As you can see, even simple programs may make heavy use of the operating systern. Frequently, systems excute 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 (Ari). The Af specifies a set of functions that are available to an application programmer, including the parameters that are passed to each function and the retum values the programmer can expect. Three of the most common Arls available to application programmers are the Windows ArI for Windows systems, the rosix AP1 for ROSIX-based systems (which include virtually all versions of UNDC, Linux, and Mac OS X), 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 UNDX 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 Arr 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 inwokes the NTCreateProcess() system call in the Windows kernel. Why would an application programmer prefer programming according to an AP rather than invoking actual system calls? There are several reasons for doing so. One benefit concems program portability. An application program- Figure 2.5 Example of how system calls are used. EXAMPLE OFSIANDARD API As an example of a standard APL, consider the read () function that is available in UNIX and Linux systems. The AfI for this function is obtained from the man page by invoking the command man read on the command line. A description of this AII appears below: A program that uses the read() function must include the un is td. h header file, as this file defines the ssize.t and size-t data types (among other things). The parameters passed to read () are as follows: - int fd-the file descriptor to be read - void *buf - a buifer where the data will be read into - size.t count-the maximum number of bytes to be read into the buffer On a successful read, the number of bytes read is retumed. A return value of 0 indicates end of file. If an error occurs, read () returns 1. mer designing a program using an AMl can expect her program to compile and run on any system that supports the same ArI (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 AII and its associated system call within the kemel. In fact, many of the POSIX and Windows Al's are similar to the native system calls provided by the UNIX, Linux, and Windows operating systems. For most programming languages, the run-time support system (a set of functions built into libraries included with a compiler) provides a systemcall 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 Figure 2.6 The handing of a user application invoking the open () system call. then invokes the intended system call in the operating-bystem kernel and returns the status of the system call and any return values. 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 AP and are managed by the run-time support library. The relationship between an API, the system-call interface, and the operating system is shown in Figure 2.6, 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 2.7). 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. Figure 2.7 Passing of parameters as a table. User and Operating-System Interface We mentioned earlier that there are several ways for users to interface with the operating system. Here, we discuss two 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 allows users to interface with the operating system via a graphical user interface, or GUI. 2.2.1 Command Interpreters Some operating systems include the command interpreter in the kernel. Others, such as Windows and UNIX, treat the command interpreter as a special program that is running when a job 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 Bourne shell, C shell, Bourne-Again shell, Korn shell, and others. Third-party shells and free user-written shells are also available. Most shells provide similar functionality, and a user's choice of which shell to use is generally based on personal preference. Figure 2.2 shows the Bourne shell command interpreter being used on Solaris 10. 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. 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 function associated with the rm command would 2.2 User and Operating-System Interface 59 Figure 2.2 The Boume shell command interpreter in Soirais 10. be defined completely by the code in the file ra. In this way, programmers can add new commands to the system easily by creating new files with the proper names. The command-interpreter program, which can be small, does not have to be changed for new commands to be added. 2.2.2 Graphical User Interfaces A second strategy for interfacing with the operating system is through a userfriendly graphical user interface, or cul. Here, rather than entering commands directly via a command-line interface, users employ a mouse-based windowand-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. Graphical user interfaces first appeared due in part to research taking place in the early 1970 s at Xerox PABC research facility. The first GUT 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 (Mac OS) has undergone various changes over the years, the most significant being the adoption of the Aqua interface that appeared with Mac csx. 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 cosmetic Chapter 2 Operating-System Structures changes in the appearance of the GUI along with several enhancements in its functionality. Because a mouse is impractical for most mobile systems, smartphones and handheld tablet computers typically use a touchsereen interface. Here, users interact by making gestures on the touchscreen-for example, pressing and swiping fingers across the screen. Figure 2.3 illustrates the touchscreen of the Apple iPad. Whereas earlier smartphones included a physical keyboard, most smartphones now simulate a keyboard on the touchscreen. Traditionally, UNIX systems have been dominated by command-line interfaces. Various GUT interfaces are available, however. These include the Common Desktop Environment (CDE) and X-Windows systems, which are common on commercial versions of UND, such as Solaris and IBM's AIX system. In addition, there has been 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. 2.2.3 Choice of Interface The choice of whether to use a command-line or CUI 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 GUL, leaving the less common tasks to those who are command-line knowledgeable. Further, commandline interfaces usually make repetitive tasks easier, in part because they have their own programmability. For example, if a frequent task requires a set of command-line 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 seripts ane 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 Gul environment and almost never use the MS-DOS shell interface. The various changes undergone by the Macintosh operating systems 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 GUL. However, with the release of Mac os X (which is in part implemented using a UNIX kernel), the operating system now provides both a Aqua interface and a command-line interface. Figure 2.4 is a screenshot of the Mac os X cUI. 62 Chapter 2 Operating-System Structures The user interface can vary from system to system and even from user to user within a system. It typically is substantially removed from the actual system structure. The design of a useful and friendly user interface is therefore not a direct function of the operating system. In this book, we concentrate on the fundamental problems of providing adequate service to user programs. From the point of view of the operating system, we do not distinguish between user programs and system programs. 2.3 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 have to be written using assembly-language instructions. Before we discuss how an operating system makes system calls available, let's first use an example to illustrate 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 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 nead from the keyboard the characters that define the two files. On mouse-bused 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 1/O system calls. Once the two file names have been obtained, the program must open the input file and create the output file. Each of these operations requires another system call. Possible error conditions for each operation can require additional system calls. When the program tries to open the input file, for example, 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 print a message on the console (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 disk space). Finally, after the entire file is copied, the program may close both files (another system call), 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 2.5. As you can see, even simple programs may make heavy use of the operating systern. Frequently, systems excute 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 (Ari). The Af specifies a set of functions that are available to an application programmer, including the parameters that are passed to each function and the retum values the programmer can expect. Three of the most common Arls available to application programmers are the Windows ArI for Windows systems, the rosix AP1 for ROSIX-based systems (which include virtually all versions of UNDC, Linux, and Mac OS X), 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 UNDX 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 Arr 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 inwokes the NTCreateProcess() system call in the Windows kernel. Why would an application programmer prefer programming according to an AP rather than invoking actual system calls? There are several reasons for doing so. One benefit concems program portability. An application program- Figure 2.5 Example of how system calls are used. EXAMPLE OFSIANDARD API As an example of a standard APL, consider the read () function that is available in UNIX and Linux systems. The AfI for this function is obtained from the man page by invoking the command man read on the command line. A description of this AII appears below: A program that uses the read() function must include the un is td. h header file, as this file defines the ssize.t and size-t data types (among other things). The parameters passed to read () are as follows: - int fd-the file descriptor to be read - void *buf - a buifer where the data will be read into - size.t count-the maximum number of bytes to be read into the buffer On a successful read, the number of bytes read is retumed. A return value of 0 indicates end of file. If an error occurs, read () returns 1. mer designing a program using an AMl can expect her program to compile and run on any system that supports the same ArI (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 AII and its associated system call within the kemel. In fact, many of the POSIX and Windows Al's are similar to the native system calls provided by the UNIX, Linux, and Windows operating systems. For most programming languages, the run-time support system (a set of functions built into libraries included with a compiler) provides a systemcall 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 Figure 2.6 The handing of a user application invoking the open () system call. then invokes the intended system call in the operating-bystem kernel and returns the status of the system call and any return values. 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 AP and are managed by the run-time support library. The relationship between an API, the system-call interface, and the operating system is shown in Figure 2.6, 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 2.7). 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. Figure 2.7 Passing of parameters as a table