Operating Systems

Computer Science 4500
Operating Systems
Module 1
Introduction, Overview and History
2008 Stanley A. Wileman, Jr.
Operating Systems
Slide 1
Welcome!
Welcome to Operating Systems. This course is designed to
introduce you to the fundamentals of operating systems. The
course uses specific features of real operating systems to
illustrate and reinforce the fundamental concepts.
Prerequisites include a good knowledge of data structures and
computer organization. You should also have had reasonable
experience with assembler language programming for some
contemporary processor (e.g. IBM S/390 or Intel X86,) and
strong skills in the C or C++ programming language. C is the
programming language of choice, and it is used in all code
illustrations. While not required, a course in digital design will
prove helpful.
Operating Systems
Slide 2
In This Module
Basic material about the course
The study of operating systems
The OS API and the user interface
Processor modes
Computer system and OS history
Operating Systems
Slide 3
Programming Assignments
Programming assignments are used to reinforce the
concepts you learn in this course. There are three basic
types of assignments possible:
illustration of various system calls for one or more real
operating systems,
implementation of OS algorithms and simulation of
their effect, and
implementation of OS algorithms in the context of a
toy operating system, or a real system with readily
available source code (e.g. Linux, FreeBSD).
Your instructor will provide complete details on each of the
programming assignments you are to complete for the
course.
Operating Systems
Slide 4
Quizzes and Examinations

In addition to the programming assignments,
quizzes and examinations provide feedback on
your mastery of fundamental operating
system concepts. The number of quizzes and
examinations in this offering of the course is
described in the course notes provided by the
instructor.
Operating Systems
Slide 5
Reference Textbooks
There are many good operating system textbooks available
and your instructor may expect you to use one with these
modules. Some of these texts are
Operating Systems Design and Implementation (third
edition), by Tanenbaum and Woodhull (Prentice Hall,
2006).
Operating Systems (third edition), by Deitel, Deitel, and
Choffnes (Addison-Wesley, 2003).
Operating Systems: Internals and Design Principles,
(sixth edition) by Stallings (Prentice Hall, 2008).
Operating System Concepts (eighth edition), by
Silberschatz, Galvin, and Gagne (Wiley, 2008).
Operating Systems
Slide 6
The study of operating systems

There are two major ways to study
operating systems:
by examining the way in which application
programs can use the operating system, or
by examining the implementation (the
algorithms, data structures, etc.) of the
operating system
We will do some of each of these in this

course.
Operating Systems
Slide 7
Operating System Functions
Operating systems have two major functions:

to manage the computer systems resources, and
to provide the functions used by application programs for
the use of complex, shared, or restricted resources.
What are these resources?
The hardware of the computer system comprises the most
obvious set of resources. This includes the central
processor(s), the primary memory, and all the hardware
associated with input/output. Well cover each of these in
detail in this course.
Information is another important resource. The content of
every file or data set must be managed by the operating
system. We will also cover this resource in detail.
Operating Systems
Slide 8
Viewing an OS as a virtual machine

An easy way to view an operating system is as a virtual
machine that provides a convenient way for applications to
use resources.
A particular toy operating system provided with a textbook
has almost 3000 lines of complex C code for managing the
text-mode terminal (e.g. a monitor and keyboard on a PC).
Clearly we dont want application programs to include this
much code just to be able to read and write the terminal.
The virtual machine looks like any other computer system,
but you can think of it as having additional simplified
instructions (actually functions) that allow easier use of the
resources than if the bare machine was used.
Operating Systems
Slide 9
The Hierarchical View of a System

Computer systems include many layers of hardware and
software, and the operating system is just one of those
layers.
You may already be aware that many systems use
microprograms which essentially provide functions that
correspond to each machine language instruction. The code
in these functions manipulate the bare hardware to effect
the actions of the machine language instruction.
The operating system, as another layer, provides extended
instructions (functions) that provide easy access to, and
management of, the systems resources.
Application programs form a layer on top of the OS.
Operating Systems
Slide 10
10
A typical computer system

Games
Presentation
Software
Spreadsheet
Compilers
Command Line
Interpreters
Editors
Operating System
Machine Language
Microprogram
Bare hardware
Operating Systems
Slide 11
11
The Application Programming Interface

Application programs utilize system resources by
invoking the operating system. Requests from
application programs are passed to the operating
system through the application programming interface
(API) provided by the operating system. Different
operating systems may have different APIs, but the
functions are frequently similar.
The API for an operating system is frequently called the
set of system calls for that operating system.
Some systems may provide multiple different APIs.
Examples of these include IBMs OS/390 and Microsofts
Windows NT.
Operating Systems
Slide 12
12
The User Interface

Some functions you might normally think of as
belonging to the operating system are actually just
application programs usually provided with the system.
The most significant example is the application that
provides you with your primary interface to the system.
This could be a text-oriented interface (as in MVS,
UNIX, or MS-DOS), or a graphical user interface (as in
Windows or the MAC OS).
These applications, regardless of how complex, are not
part of the operating system. They accept user input
(by using the OS API) and carry out commands (again,
by using the OS API as required).
Operating Systems
Slide 13
13
Systems With No User Interface

To amplify the difference between the user interface and
the operating system, consider a microprocessor system
that you might find under the hood of a new car. If this
system is used to control the automobiles ignition, it is
highly unlikely that it has a user interface. But there are
still applications running on that microprocessor system
that use the CPU and memory resources, and that
perform input/output operations. And it likely has a
small operating system that provides an API for those
applications to use!
Operating Systems
Slide 14
14
Input/Output Interfaces
Most input/output devices are connected to a computer

system through an interface called a device controller. These
may have associated device registers that appear as
locations in a memory space accessible by the central
processor. For example, to set a timer device it is necessary
to write to three byte-sized registers, one indicating the
timer mode, and the other two providing a 16-bit timer
interval.
Other systems (e.g. an IBM mainframe) may have device
controllers that are accessed through a special processor
called a channel. Separate programs (strangely called
channel programs) must be prepared for the channel to
execute.
Operating Systems
Slide 15
15
Processor Modes (States)
Some resources must be accessed only by the operating system

if order is to be preserved in a system. Consider the use of a
printer connected to a multiuser system. Clearly only one user
should be printing at a time.
Processors on modern systems will usually have at least two
processor modes, or states. The mode in which user programs
(applications) usually execute is called the user mode, or the
problem state. In this mode certain instructions (e.g. those that
access device registers) may not be executed. In the other
mode, called the kernel mode, or the supervisor state, all
instructions may be executed and all resources may be
accessed. Some systems (e.g. DEC VAX) may have more than
two processor states, but well only consider two in this course.
Operating Systems
Slide 16
16
Operating System History

A brief survey of operating system history will prove useful
in understanding modern systems. When doing this well
talk about generations of computer systems. Successive
generations are usually introduced when major
technological advances are made.
Generation 0, if you will, began with Charles Babbages
design for his analytical engine to be used in calculating
entries of mathematical tables. This first design for a
digital computing device was conceived in the early 1820s!
Additionally, Ada Lovelace (the daughter of Lord Byron),
was the first programmer for this device. The
programming language ADA was named after her.
Operating Systems
Slide 17
17
Operating Systems
Slide 17.1
18
Operating Systems
Slide 17.2
19
Operating Systems
Slide 17.3
20
Half of Babbages
Brain and a Notebook
(in the Science
Museum, London)
Operating Systems
Slide 17.4
21
Generation 1: 1945-1955
The equipment in the first generation of practical
computing hardware consisted of hard-wired
plugboards, enormously heavy mechanical devices, and
vacuum-tube implementation of logical circuits.
There were no operating systems, programming
languages or networks in this generation.
Punched cards were introduced in the early 1950s.
Each card, the same size as a U. S. dollar bill, contained
80 bytes of data. Many devices existed to process data
in this format, including keypunches (to enter data onto
the cards), card sorters, and listing devices.
Operating Systems
Slide 18
22
An 80-column Punched Card
Operating Systems
Slide 18.1
23
Perhaps the most important technological advance in this
generation was the invention of the transistor. Vacuum tubes,
previously used in computing devices, generate enormous
amounts of heat and consume lots of energy. In contrast,
transistors generate little heat and consume little energy. Since
transistors dont operate by burning themselves up (like light
bulbs), the reliability of systems was also greatly improved.
Previously a computer system was completely dedicated to one
user at a time, requiring lots of time to set up a computation,
debug and run it, and then clean up the system afterwards. In
this generation, the concept of a job, a deck of cards containing
commands and data, reduced this overhead time significantly.
Operating Systems
Slide 19
24
Generation 2: Typical Systems

After a job was prepared off-line on a keypunch, it was
submitted to the computer system, where it processed
as a unit with little or no operator intervention. After it
was completed, the next job could be immediately
started.
There were two basic types of computer systems in this
generation. Scientific machines (typified by the IBM
7094) were used, as expected for jobs requiring large
amounts of computation. Business machines (typified
by the IBM 1401) were used for jobs that were
input/output intensive, but required limited numbers of
calculations.
Operating Systems
Slide 20
25
An IBM 7094 System
Operating Systems
Slide 20.1
26
An IBM 1401 System
Operating Systems
Slide 20.2
27
Generation 2: Batch Processing

In a clever combination of scientific and business
systems, batch processing was used to speed job
processing. Batches of jobs (that is, multiple sequential
jobs) were first copied to magnetic tape on an IBM 1401.
The tape was then physically moved to the IBM 7094,
where the jobs were read and processed, one after
another. Reading from magnetic tape is much faster than
reading from punched cards. Output was written to
magnetic tape, and when the batch was finished, the
magnetic tape was moved back to the IBM 1401, where
the printed output was copied from tape to paper (or
punched cards).
Operating Systems
Slide 21
28
Generation 2: A Typical Job

A typical job included a combination of control cards and
data (that is, program source statements and data).
Control cards could be distinguished by the presence of
a special character in the first few columns. Control
cards were used to define the beginning of a job,
request the execution of a program, or to define a
collection of data to be used by a program.
The typical programming languages in use during this
generation were FORTRAN and COBOL. Operating
systems included IBSYS and FMS.
Operating Systems
Slide 22
29
The major hardware development that introduced the third
generation was the integrated circuit. Instead of using discrete
components (transistors, resistors, etc.) to build a system, welldefined logical circuits were constructed as a single component.
This resulted in smaller and more power-efficient systems.
Another major architectural change united the features of
scientific and business computer systems. Instead of two
different machines (i.e. scientific and business), a single system
providing features of both types of machines was introduced.
The most popular of these was the IBM 360. Multiple models
this system was produced, varying in speed and features. Many
other manufacturers also produced similar systems.
Operating Systems
Slide 23
30
An IBM 360 System
Operating Systems
Slide 23.1
31
Generation 3: OS/360
Perhaps the most important operating system prevalent in the
third generation was IBMs OS/360. It was designed to
successfully accommodate the needs of all users on every
model of the S/360 computer system. This goal was never
completely achieved.
The OS/360 operating system included millions of lines of
assembler code written by thousands of programmers. It isnt
surprising, then, that the numbers of bugs in the system
remained essentially constant, even over many releases.
Even so, OS/360 satisfied the needs of almost all customers.
Operating Systems
Slide 24
32
Generation 3: New OS Features

Multiprogrammingallowed multiplexing of execution (on
the CPU) with input/output operations. This required
partitioning memory into regions, each of which contained
one program.
Spoolinginput/output from executing programs was
from/to disk files; these files were copied from/to physical
devices (card readers and printers). SPOOL is an acronym
for simultaneous peripheral operations on line.
Timesharingmultiple users at on-line terminals could
edit, compile, and test small programs while batch
programs ran in the background.
Operating Systems
Slide 25
33
Generation 3: New Architecture

During this generation, DEC (Digital Equipment Corp.)
introduced the PDP-1, a system based on a new
architecture. PDP is an acronym for Programmed Data
Processor. The PDP-1 was notable for its relatively small
size and cost, and enabled computer systems to be
employed in many environments where larger systems
would be too costly. This machine was the first of a
series, terminating with the PDP-11. Machines like these
were called minicomputers.
Operating Systems
Slide 26
34
Generation 3: New OS Designs
MULTICSMultiplexed Information and Computing Service.

MIT, Bell Labs, and GE developed the idea of a computing
utility (like a power plant) that could serve large numbers of
users; MULTICS introduced many seminal ideas in system
design.
The UNIX operating system from AT&T/Bell Labs.
Source code for early versions was licensed and widely
used in university courses.
Later versions (V7 and later) were restricted.
Other similar systems (notably FreeBSD, Linux, and
MINIX) are freely available in source code form.
The POSIX standard for UNIX-like systems was developed
by IEEE.
Operating Systems
Slide 27
35
Generation 4: 1980...
The development of large scale integrated circuits (LSI)
containing thousands of transistors and other components
enabled the development of complete processors in a
single circuit package. These microprocessor devices have
revolutionized computing, especially as additional
development led to very large scale integrated circuits
(VLSI) using complementary metal oxide semiconductor
(CMOS) technology containing hundreds of thousands,
even millions, of transistors.
Families of processors have been produced, starting with
small 4-bit systems. Today 64-bit microprocessor systems
are commonplace.
Operating Systems
Slide 28
36
Generation 4: New Peripherals

The fourth generation also saw the introduction of new
low-cost peripherals especially useful for small computer
systems. Examples include widespread use of graphic
displays and input devices, and increasingly smaller disk
systems, including removable media like floppy disks.
Another device with enormous impact is the network,
which enables communication between computer systems.
A major outgrowth of microprocessors and networking is
the Internet. Indeed, the Internet might be correctly
perceived as marking the beginning of a new generation of
computer systems.
Operating Systems
Slide 29
37
Generation 4: New Operating Systems

Widespread use of microprocessors spurred the development
of new operating systems. Some of the more notable of these
are
MS-DOS
Microsoft Windows and the Macintosh OS
UNIX is still popular in the fourth generation. High-end
workstations and supercomputers almost always use UNIX,
and Linux is gaining popularity, especially since it is now
available for many architectures, including S/390 mainframes.
IBMs OS/390 is the latest mainframe operating system, and
includes a traditional UNIX API, accompanied by the usual
UNIX utilities and shells.
Operating Systems
Slide 30
38
Next
In the next module well look at two
major operating system concepts:
processes and files.
Various system calls for managing
processes will be examined, and actual
programs using these system calls will
be developed.
Operating Systems
Slide 31
39
CSCI 4500
Operating Systems
Module 2
OS Concepts: Processes and File Systems
Updated: July 30, 2014
Operating Systems
Slide 1
In This Module
Operating System Concepts
Introduction to Processes
Files and Data Sets
Name Binding, Catalogs and Directories
System Calls for Processes and Tasks
Sample Programs Using Processes
Operating Systems
Slide 2
Operating System Concepts

Recall that we will study operating systems from
two points of view. These are the views of
Application writers, using the various system calls to
achieve interaction with the system and its
resources.
OS implementers, who must write the code for the
operating system that implements the system calls.
Lets consider two major system call categories,

those for processes and for file systems.
Operating Systems
Slide 3
Introduction to Processes (Tasks)

A process, sometimes called a task, is
essentially a packaged unit of work for a
computer system. In many cases when you
enter a command or double click on an icon,
a command interpreter process (a shell) will
create a new process to run the program.
Processes will always have
an address space in which they can execute, and
a set of processor registers to hold data, next
instruction address, and so forth.
Operating Systems
Slide 4
Processes
In a multiprogramming system, multiple
processes (at least one per user) are being
virtually executed. But its obvious only one
process can be actually executed at a time on a
single processor.
Thus, the process currently being executed is
occasionally freeze dried and another process
is executed for a while. This is called a context
switch, since the processors context changes.
When a process is not being executed, salient
details (e.g. CPU register contents and file
pointers) are stored away in a process table.
Operating Systems
Slide 5
Process Example: The CPU

executes some instructions from
process A
LOAD A
ADD B .
STORE C .
DIV X
.
ADD Z
STORE Y
Process A
LOAD K
DIV E
MPY T
STORE N
CMP L
JNE LOOP
Operating Systems
Process B
Slide 6
then saves process As context

and executes some instructions
from process B
LOAD A
ADD B
STORE C
DIV X
ADD Z
STORE Y
Process A
LOAD K
. DIV E
. MPY T
. STORE N
CMP L
JNE LOOP
Operating Systems
Process B
Slide 7
then saves process Bs context,

restores As context and executes
some more instructions.
LOAD A
ADD B
STORE C
DIV X
ADD Z
STORE Y
Process A
LOAD K
DIV E
MPY T
STORE N
CMP L
JNE LOOP
.
.
.
Operating Systems
Process B
Slide 8
System Calls for Processes

Key process-related system calls include
those in the following categories:
create or terminate a process;
cause a process to wait, if necessary, until it can
use a particular resource;
manage the memory used by a process; and
control the handling of asynchronous signals sent
to a process.
We will later examine some of these system

calls in detail, and use them in a program.
Operating Systems
Slide 9
Process Tables
A process table has one entry for every
process in the system.
Each process table entry contains
information about process ownership,
relation to other processes, process state,
and statistical information.
Process tables are frequently organized
as static arrays.
Operating Systems
Slide 10
10
Process Identification and Ownership

Each process in a system must be uniquely
identified. In UNIX systems, this identification
is provided by an integer called the process ID.
Each process is also owned by a particular user,
identified by a user ID (uid).
One uid, associated with the super user,
imparts special privileges (e.g. shutdown the
system, and read arbitrary files) to processes.
(OS/390 UNIX allows multiple super users.)
Operating Systems
Slide 11
11
Files and Data Sets

Another major operating system function is to
provide convenient access to information
organized in files, or data sets. (The term data
set is frequently used for files on mainframes.)
Files are named collections of information,
usually stored on disk or magnetic tape.
Files can also be stored on other devices,
including RAM disks and removable memory
cards for use with portable devices (e.g.
cameras and handheld computers).
Operating Systems
Slide 12
12
File Systems
A file system is a storage structure (like a
data structure, but normally tailored for a
secondary storage device like a disk).
There are many different types of file
systems, even for the same operating
system. Speed, reliability, media type, and
other factors influence the design of a file
system. For example, CD Rom file systems
differ considerably from those for hard drives.
Operating Systems
Slide 13
13
System Calls for File Manipulation

The usual system calls for manipulating files
include the following:
open prepare a file for input/output
read copy data from file to memory
write copy data from memory to file
close conclude I/O operations on a file
Other system calls may be provided for things like

file locking, random positioning, concurrent I/O,
tape positioning, communication functions, and so
forth.
We will later take a detailed look at a number of
these system calls and use them in a program.
Operating Systems
Slide 14
14
Organizing Files
Even systems designed for use by a single
user may have thousands of files. How are
these files organized?
Most systems use a hierarchical naming
scheme for files. A particular file is accessed
by giving first the name at the top level of the
hierarchy, then the second level name, and
so forth, finishing with the name of the
desired file.
Operating Systems
Slide 15
15
Hierarchical Naming Examples

A mainframe computer might use names like
STANW.SAMPLE.JOBS and
STANW.SAMPLE.CLIST for data sets
containing different types of sample code.
If these were stored in a UNIX file system,
they might be /u/stanw/sample/jobs and
/u/stanw/sample/clist.
Note that the basic concepts are the same.
Its much like describing a path through a
tree, from the root to a particular node.
Operating Systems
Slide 16
16
Binding
The term binding is used to indicate the
mechanism by which a name is associated
with an object.
For file systems, binding refers to the
mechanism used to associate a name with a
file.
There are many different binding techniques
used in different file systems.
Operating Systems
Slide 17
17
Binding Examples
The IBM MVS system uses catalogs, each of
which stores pairs of the form (name, location),
where name might be STANW.SAMPLE.JOBS and
location would identify the physical location of the
file.
UNIX systems use multiple directories are used to
store this information, each directory similar to an
interior node of a tree. Thus each directory entry
(called a link) contains one component of a
hierarchical name and a reference to the named
object, which could be another directory or a
regular file.
Operating Systems
Slide 18
18
Catalogs
STANW.SAMPLE.JOBS
STANW.SAMPLE.CLIST
.
.
.
Operating Systems
Slide 19
19
Directories
u
stanw
stanw
sample
sample
jobs
clist
Operating Systems
Slide 20
20
Catalogs and Directories

We frequently say a catalog or directory
contains a group of files, but this is only a
conceptual idea.
As we have seen, a directory or catalog only
contains a list of file identifiers and other
information, but not the files themselves.
Directories and catalogs are usually themselves
stored in files, but with limited access for writing
since their organization must be carefully
maintained. This is crucial for the proper
operation of the file system.
Operating Systems
Slide 21
21
Common Filesystems
Some common file systems include:
FAT (used with MS-DOS)
NTFS (used with Windows NT)
CDFS (used on CD-ROMs)
UFS (used with UNIX systems)
HFS (used with OS/390 UNIX)
MVS (used with mainframe systems)
Each of these has a unique way of naming and

storing files, and mapping from a file name to its
storage. The functions they provide, however,
are basically the same.
Operating Systems
Slide 22
22
Hierarchical File System Conventions

The top directory (node) in a hierarchical file
system tree is called, naturally, the root node or
root directory.
This concept does not apply to the MVS file
system. MVS may, however, have multiple
catalogs, the first of which is called the master
catalog.
The first component of a data sets name in MVS
is called the high level qualifier (HLQ).
Operating Systems
Slide 23
23
Relative and Absolute Path Names

In many systems (UNIX, Windows, etc.), a
unique file can be identified by giving a path to
it, starting from the root directory. This is
called an absolute, or complete path path to the
file.
A path may be given from a working directory,
which is just a directory identified as such by
the user. A default working directory, called the
users home directory, is in effect at login time.
Absolute paths always begin with /; a relative
path is one that does not start with /.
Operating Systems
Slide 24
24
Example Paths
Absolute or complete paths
/u/stanw/samples/jobs
/usr/man/man2/fork.2
Equivalent relative paths (where cwd means
current working directory)
jobs (with cwd of /u/stanw/samples)
man2/fork.2 (with cwd of /usr/man)
Operating Systems
Slide 25
25
System Calls for Directories

Windows NT:
CreateDirectory, RemoveDirectory
GetCurrentDirectory, SetCurrentDirectory
UNIX:
mkdir, rmdir
link, unlink, mount, unmount
chdir, chroot
Operating Systems
Slide 26
26
Non-Hierarchical File Systems

Some file systems do not support hierarchical
file naming (in the traditional manner).
For example, the CP/M operating system (the
predecessor of MS-DOS) only allows each file
to have 11 characters in its file name, in the
common 8.3 format (e.g. computer.txt).
There is only one directory, which contains an
entry for every file in the CP/M file system.
Operating Systems
Slide 27
27
File Permissions
Most systems provide some protection for files
to restrict who can read, write, create, or
delete particular files.
UNIX systems use a 9-bit code containing
three groups (for the user/owner, the users
group, and all others) of 3 bits each.
Each group of bits is interpreted as r w x. If r
is set, then reading is allowed; w = write; x =
execute.
Operating Systems
Slide 28
28
RACF (pronounced Rack F)

OS/390 provides optional security systems
(like RACF) that provide security external to
the file system. Each system call that seeks
to access an object (e.g. a file) causes the
operating system to query RACF to see if the
requested access is permitted.
This global approach to providing security is
different (and much more comprehensive)
than the file-system integral approach used
by UNIX.
Operating Systems
Slide 29
29
Access Control Lists

Windows NT and RACF also provide
ACLs, or Access Control Lists.
An ACL is a list of pairs, each pair
identifying a user or group of users, and
the type of access permitted to the file.
Each file system object may have an
associated ACL. RACF extends ACLs to
virtually every object in the system.
Operating Systems
Slide 30
30
Special Files
UNIX allows access to physical devices (for
suitably privileged processes) using the same
I/O system calls used for regular files.
Character special files are used to model
devices that do transfer one character at a
time. Examples include serial ports, mice,
keyboards, printers, etc.
Block special files model devices that transfer
a block of data at a time (disks and tapes).
Operating Systems
Slide 31
31
File Descriptors / Handles

Opening a file requires specification of the file
name, or the path to the file. The type of access
desired (e.g. read, write) is also indicated.
After the file is open, other system calls
referencing the file use a reference to a data
structure containing information about the open
file; this reference is returned by the open call.
In UNIX, this reference is called a file descriptor.
In Windows, it is called a handle. And in MVS it is
a pointer to a data control block.
Operating Systems
Slide 32
32
Files Automatically Open in

UNIX Processes
Three (or more) files are usually
available (opened automatically) when
a process begins execution:
Standard input (usually the keyboard)
Standard output (usually the CRT)
Standard error (usually also the CRT)
Standard print (in MS-DOS and Windows)
Operating Systems
Slide 33
33
High Level Language I/O

In a high-level language (like C or Pascal),
application programs rarely directly use the
reference returned by the open system call.
Instead, they use a reference to a higher-level
data structure managed by standard libraries
provided by the language.
For example, to read a character c from the
keyboard in C, we could use either
read (0, &c, 1);
(using the system call)
c = getchar(stdin); (using a standard library function)
Operating Systems
Slide 34
34
Pipes
A pipe is essentially queue of bytes treated as an
I/O device.
When a pipe is created, the user is usually given
two handles (or file descriptors).
The first handle is used for reading, and the
second handle is used for writing.
Data written into the pipe is conceptually written
at the tail of the queue; reading from the pipe
removes data from the head of the queue.
Pipes are frequently used for communication
between processes.
Operating Systems
Slide 35
35
Implementation of System Calls

Q. Since the operating system code usually
executes in kernel mode, and applications
run in user mode, how can an application
make a system call which requires the
application to enter the kernel mode?
A. Special instructions are used that cause
traps - just as in a divide by 0, but these
traps indicate to the OS that a system call
was made. While in kernel mode, the
application can only execute the specified
system calls code, thus ensuring security.
Operating Systems
Slide 36
36
Making System Calls from C

Rather than have users struggle with writing
special trap instructions, libraries are included
with C implementations that define functions
that execute the appropriate trap instructions.
Example (UNIX):
char buffer[80];
int count;
count = read (0,buffer,80);
The read function handles parameter passing
and arranges for the appropriate trap instruction
to be executed.
Operating Systems
Slide 37
37
System Call Results

Most system calls are designed to return a
unique code indicating failure. In UNIX, this is
usually 1.
When a system call fails, an additional
mechanism is available to identify the particular
reason for failure:
errno (a global variable in UNIX)
GetLastError (a function call in WindowsNT)
a processor registers contents in MVS
Operating Systems
Slide 38
38
Command Interpreters (Shells)

Character-oriented interfaces to operating
systems (as opposed to GUIs) utilize one or
more programs that interpret a command
language, frequently resulting in requests to
create processes and execute programs.
These interpreters are normally called shells
(e.g. sh, csh, mush, tcsh and ksh in UNIX).
Windows NT uses a program called cmd.exe,
and MS-DOS uses command.com.
Operating Systems
Slide 39
39
Typical Features of Shells

A user-configurable prompt is issued to
indicate the shell is ready for the next
command.
prog arg1 arg2 would be typed to request
creation of a process for execution of the
executable program in file prog (a relative
path) with arguments arg1 and arg2 (more
on arguments later).
Operating Systems
Slide 40
40
More Shell Features

prog < input executes prog with its standard
input redirected to the file input.
prog > output redirects standard output to
the named file.
prog < input > output redirects both
standard input and standard output.
prog1 | prog2 runs prog1 and prog2; the
standard output of prog1 piped to prog2s
input.
prog & runs prog concurrently with shell.
Operating Systems
Slide 41
41
Other Approaches
Note that the mechanism by which an
executable program is submitted for execution,
and how external objects (e.g. files and
terminals) are associated with the process, is
usually independent of the system calls made by
the process.
For example, in MVS, program execution is
requested by statements in a data set (file)
containing JCL (job command language). The
program itself, while unchanged, could have its
execution requested by a command line in UNIX.
Operating Systems
Slide 42
42
MVS Job Control Language

JCL statements usually have three fields: a label, a
statement type, and parameters.
The JOB statement is used to define a job consisting
of one or more job steps:
//DOIT
JOB
ACCT#,USERNAME
The EXEC statement requests the execution of a
program:
//STEP1 EXEC PGM=COMPILER
The DD statement associates a ddname with a
data set (the ddname is referenced inside the
program):
//SYSIN DD DSN=MY.SOURCE.PROGRAM
Operating Systems
Slide 43
43
A Typical MVS Job

//DOIT
//
JOB
EXEC
12345678,USERNAME
COB2UCLG
//COB2.SYSIN DD *
The COBOL program goes here
/*
//GO.OUT DD SYSOUT=*
//GO.IN DD DSN=MY.INPUT.DATA,DISP=SHR
Operating Systems
Slide 44
44
The UNIX fork System Call

The UNIX system call fork() duplicates the
process that executes it: memory contents,
open file handles, quotas, permissions, etc.
In the parent (creating) process, fork()
returns the unique process id (an integer) of
the newly created process.
In the child process, fork() returns 0.
Operating Systems
Slide 45
45
The UNIX execve System Call

The execve() system call replaces the core
image (memory contents) of the currently
executing process with that of another
program.
Shells begin the execution of a program
(specified on the command line) by first
executing fork, and then arranging for the
child process to exec the appropriate
program.
Operating Systems
Slide 46
46
The Windows NT CreateProcess

System Call
The CreateProcess system call combines
the effects of the UNIX fork and exec
system calls.
CreateProcess creates a new process
which begins executing a named
program with a specified set of
arguments.
Operating Systems
Slide 47
47
The MVS ATTACHX System Call

The ATTACHX system call is used in MVS to
create a new subtask (process) and have it
execute a named program.
MVS System calls are usually made from code
generated by assembler macros.
The ATTACHX macro places the address of a
parameter block in a register, then executes
the instruction SVC 42 which invokes the
operating system by causing a trap.
The parameter block includes the name of
the program to be executed by the new task.
Operating Systems
Slide 48
48
Passing Arguments to UNIX Processes

When a UNIX process begins execution, it
receives command line parameters in a
variable length array of pointers to character
strings.
In C, the main function uses two (or three)
arguments:
An integer giving the number of arguments
A pointer to an array of character strings which
contains the arguments
The third argument points to the environment
(which we will cover later).
Operating Systems
Slide 49
49
Sample Program Using Arguments

The program args.c illustrates a C program
that references the arguments provided on
the command line.
The program just prints the arguments.
If invoked as args one two three, the
program will print the following:
Number of arguments = 4
Argument 0: <args>
Argument 1: <one>
Argument 2: <two>
Argument 3: <three>
Operating Systems
Slide 50
50
UNIX program: args.c

/************************************/
/* Print the command line arguments */
/************************************/
#include <stdio.h>
main (int argc, char *argv[])
{
int i;
printf("Number of arguments = %d\n, argc);
for (i=0;i<argc;i++)
printf("
Argument %d: <%s>\n",i, argv[i]);
exit(0);
}
Operating Systems
Slide 51
51
Sample Program Using Fork/Exec

The program prun.c illustrates a C program
that creates a new process that then executes
a named program with arguments.
If invoked as prun pargs one two, the
program will create a new process (using
fork()) and terminate. The new process
will then execute the pargs program (using
execve()) which will print the expected
output.
Operating Systems
Slide 52
52
UNIX program: prun.c (part 1)

/*********************************************/
/* Create a new process to execute a program */
/*********************************************/
#include <stdio.h>
extern char **environ;
void main( int argc, char *argv[])
{
char *args[10];
int i;
/* Eliminate argv[0] prior to use by execve */
for (i=1; i<argc;i++) args[i-1] = argv[i];
args[i-1] = NULL;
if (argc < 2) {
/* error: too few arguments */
printf("Usage: prun <prog> <arg> ...\n" );
exit(1);
}
Operating Systems
Slide 53
53
Program: prun.c (part 2)

if (fork() == 0) { /* fork, test for error */
/* inside the new process, execute the prog */
execve(argv[1], args, environ);
perror("execve");
/* if execve had error */
exit(1);
}
printf( "prun complete.\n", i );
exit(0);
}
Operating Systems
Slide 54
54
Next
In the next module well examine the process
model in more detail.
We will examine the states in which
processes may exist, and the causes for
transitions between these states.
Threads will be considered as alternatives to
processes.
And interprocess communication (IPC) will be
introduced.
Operating Systems
Slide 55
55

Operating Systems

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Operating Systems

Uploaded by

Copyright:

Available Formats

Computer Science 4500

2008 Stanley A. Wileman, Jr.

Quizzes and Examinations

2008 Stanley A. Wileman, Jr.

The study of operating systems

We will do some of each of these in this

Operating System Functions