III-I IT

OPERATING SYSTEM (OS)

SUBJECT CODE : A35EB

A.SWAMY GOUD,
ASSISTANT PROFESSOR,
BVRIT, NSP

A.SWAMY GOUD,
ASSISTANT PROFESSOR,
BVRIT, NSP
 UNIT - I
INTRODUCTION
 OS Syllabus - Unit I
Operating Systems Objectives and Functions
Computer System Architecture
Generations of Operating Systems
Operating Systems Services
User OS Interface
System Calls
Types of System Calls
System Programs
OS Design and Implementation
OS Structure - Layered, Monolithic, Microkernel,
Concept of Virtual Machines.
Case Studies: Linux, Windows.
 Operating System
An Operating System (OS) is a program that acts as
an intermediary between a user of a computer and
the computer hardware
An Operating System (OS) is the program that, after
being initially loaded into the computer by a boot
program, manages all other programs in computer.
Operating System goals:
Execute user programs and
make solving user problems
easier
Make the computer system
convenient to use
Use the computer hardware
in an efficient manner
 Computer System Structure

Computer system can be divided into four components:

Hardware – provides basic computing resources
CPU, memory, I/O devices
Operating system - Controls and coordinates use of
hardware among various applications and users
Application programs – define the ways in which the
system resources are used to solve the computing problems
of the users
Word processors, compilers, web browsers, database
systems, video games
Users - People, machines, other computers
Components of a Computer
System
 What Operating Systems Do
Depends on the point of view
Users want convenience, ease of use and good
performance
Don’t care about resource utilization
But shared computer such as mainframe or
minicomputer must keep all users happy
Users of dedicate systems such as workstations have
dedicated resources but frequently use shared resources
from servers
Handheld computers are resource poor, optimized for
usability and battery life
Some computers have little or no user interface, such as
embedded computers in devices and automobiles
 Operating System Definition

OS is a resource allocator
Manages all resources
Decides between conflicting requests for efficient
and fair resource use
OS is a control program
Controls execution of programs to prevent errors
and improper use of the computer
 Operating System Definition

No universally accepted definition

“Everything a vendor ships when you order an
operating system” is a good approximation
But varies wildly
“The one program running at all times on the
computer” is the kernel.
Everything else is either
a system program (ships with the operating system) ,
or
an application program.
 Computer System
Organization
Computer-system operation
One or more CPUs, device controllers connect through
common bus providing access to shared memory
Concurrent execution of CPUs and devices competing
for memory cycles
 Computer-System Operation

I/O devices and the CPU can execute concurrently

Each device controller is in charge of a particular
device type
Each device controller has a local buffer
CPU moves data from/to main memory to/from local
buffers
I/O is from the device to local buffer of controller
Device controller informs CPU that it has finished its
operation by causing an interrupt
 Common Functions of
Interrupts
Interrupt transfers control to the interrupt service
routine generally, through the interrupt vector, which
contains the addresses of all the service routines
Interrupt architecture must save the address of the
interrupted instruction
A trap or exception is a software-generated interrupt
caused either by an error or a user request
An operating system is interrupt driven
 Interrupt Handling
The operating system preserves the state of the
CPU by storing registers and the program counter
Determines which type of interrupt has occurred:
Polling
Vectored interrupt system
Separate segments of code determine what action
should be taken for each type of interrupt
Interrupt Timeline
 Evolution of Operating
Systems
Must adapt to hardware upgrades and new types
of hardware. Examples:
Character vs. graphic terminals
Introduction of paging hardware
Must offer new services, e.g., internet support.
The need to change the OS on regular basis place
requirements on it’s design:
modular construction with clean interfaces.
object oriented methodology.
 Evolution of Operating
Systems
Early Systems (1950)
Simple Batch Systems (1960)
Multiprogrammed Batch Systems (1970)
Time-Sharing and Real-Time Systems (1970)
Personal/Desktop Computers (1980)
Parallel/Multiprocessor Systems (1980)
Networked/Distributed Systems (1980)
Web-based Systems (1990)
 Early Systems

Structure
Single user system.
Programmer/User as operator (Open Shop).
Large machines run from console.
Paper Tape or Punched cards.
 Characteristics of Early
Systems
Early software: Assemblers, Libraries of common
subroutines (I/O, Floating-point), Device Drivers,
Compilers, Linkers.
Need significant amount of setup time.
Extremely slow I/O devices.
Very low CPU utilization.
But computer was very secure.
 Simple Batch Systems
Use of high-level languages, magnetic tapes.
Jobs are batched together by type of languages.
An operator was hired to perform the repetitive tasks of
loading jobs, starting the computer, and collecting the output
(Operator-driven Shop).
It was not feasible for users to inspect memory or patch
programs directly.
 Operation of Simple Batch
Systems
The user submits a job (written on cards or tape) to a computer operator.
The computer operator place a batch of several jobs on an input device.
A special program, the monitor, manages the execution of each program
in the batch.
Monitor utilities are loaded when needed.
“Resident monitor” is always in main memory and available for execution.

Idea of Simple Batch Systems

Reduce setup time by batching similar jobs.
Alternate execution between user program and the monitor program.
Rely on available hardware to effectively alternate execution from various
parts of memory.
Use Automatic Job Sequencing – automatically transfer control from one
job when it finishes to another one.
 Uniprogramming

I/O operations are exceedingly slow

(compared to instruction execution).
A program containing even a very small
number of I/O operations, will spend
most of its time waiting for them.
Hence: poor CPU usage when only one
program is present in memory.
 Multiprogrammed Batch
Systems
Several jobs are kept in main memory at the same time, and the
CPU is multiplexed among them.
Spooling provides an important data structure: a job pool.
Spooling will generally result in several jobs that have already
been read waiting on disk, ready to run.
A pool of jobs on disk allows the operating system to select
which job to run next, to increase CPU utilization.
When jobs come in directly on cards or even on magnetic tape, it
is not possible to run jobs in a different order. Jobs must be run
sequentially, on a first-come, first-served basis.
However, when several jobs are on a direct-access device, such as
a disk, job scheduling becomes possible.
The operating system keeps several
jobs in memory at a time
This set of jobs is a subset of the jobs
kept in the job pool.
The operating system picks and begins
to execute one of the jobs in the
memory.
Eventually, the job may have to wait for
some task, such as a tape to be
mounted, or an I/O operation to
complete.
The operating system simply switches Memory Layout for
Batch
to and executes another job. Multiprogramming
Multiprogramming
Multiprogramming
 Time-Sharing Systems
Multiprogrammed batched systems provide an environment
where the various system resources (for example, CPU,
memory, peripheral devices) are utilized effectively.
There are some difficulties with a batch system from the
point of view of the user, however.
Since the user cannot interact with the job when it is
executing, the user must set up the control cards to handle
all possible outcomes.
In a multistep job, subsequent steps may depend on the
result of earlier ones. The running of a program, for
example, may depend on successful compilation.
It can be difficult to define completely what to do in all cases.
 Time-Sharing Systems
Time sharing, or multitasking, is a logical extension of
multiprogramming.
Multiple jobs are executed by the CPU switching between
them, but the switches occur so frequently that the users
may interact with each program while it is running.
An interactive, or hands-on, computer system provides on-
line communication between the user and the system.
The user gives instructions to the operating system or to a
program directly, and receives an immediate response.
The user can easily experiment, and can see results
immediately.
 Time-Sharing Systems
Batch systems are appropriate for executing large jobs that
need little interaction.
The user can submit jobs and return later for the results; it is
not necessary for the user to wait while the job is processed.
Interactive jobs tend to be composed of many short actions,
where the results of the next command may be
unpredictable.
The user submits the command and then waits for the
results.
Accordingly, the response time should be short—on the
order of seconds at most.
An interactive system is used when a short response time is
required.
 Personal-Computer Systems
Personal computers appeared in the 1970s.
As hardware costs have decreased, it has once again become
feasible to have a computer system dedicated to a single user.
They are microcomputers that are considerably smaller and less
expensive than mainframe systems.
These types of computer systems are usually referred to as
personal computers (PCs).
The I/O devices have certainly changed, with panels of switches
and card readers replaced with type writer like keyboards and
mouse.
Line printers and card punches have succumbed to display
screens and to small, fast printers.
During their first decade, the CPUs in PCs lacked the features
needed to protect an operating system from user programs.
PC operating systems therefore were neither multiuser nor
multitasking.
 Parallel / Multiprocessor
Systems
Most systems to date are single-processor systems; that is,
they have only one main CPU.
However, there is a trend toward multiprocessor systems.
Such Systems have more than one processor in close
communication, sharing the computer bus, the clock, and
sometimes memory and peripheral devices.
These systems are referred to as tightly coupled systems.
There are several reasons for building such systems. One
advantage is increased throughput. By increasing the
number of processors, we hope to get more work done in a
shorter period of time.
Multiprocessors can also save money compared to multiple
single systems because the processors can share
peripherals, cabinets, and power supplies.
 Parallel / Multiprocessor
Systems
Another reason for multiprocessor systems is that they
increase reliability.
If functions can be distributed properly among several
processors then the failure of one processor will not halt the
system, but rather will only slow it down.
Continued operation in the presence of failures requires a
mechanism to allow the failure to be detected, diagnosed,
and corrected.
The most common multiple-processor systems use the
symmetric-multiprocessing model, in which each processor
runs, an identical copy of the operating system, and these
copies communicate with one another as needed.
Some systems use asymmetric multiprocessing, in which
each processor is assigned a specific task.
 Networked / Distributed
Systems
A recent trend in computer systems is to distribute
computation among several processors.
In contrast to the tightly coupled systems, the processors do
not share memory or a clock.
Instead, each processor has its own local memory.
The processors communicate with one another through
various communication lines, such as high-speed buses or
telephone lines.
These systems are usually referred to as loosely coupled
systems, or distributed systems.
 Networked / Distributed
Systems
The processors in a distributed system may vary in size and
function.
They may include small microprocessors, workstations,
minicomputers, and large general-purpose computer
systems.
These processors are referred to by a number of different
names, such as sites, nodes, computers, and so on,
depending on the context in which they are mentioned.
There is a variety of reasons for building distributed systems,
the major ones being these: Resource sharing,
Computation speedup, Reliability, Communication
Networked / Distributed
Systems
 Real-Time Systems
Another form of a special-purpose operating system is the
Real-Time Systems.
A real-time system is used when there are rigid time
requirements on the operation of a processor on the flow of
data, and thus is often used as a control device in a dedicated
application.
Typical examples of real-time systems include Air Traffic
Control Systems, Networked Multimedia Systems, Command
Control Systems etc.
Systems that control scientific experiments, medical imaging
systems, industrial control systems, and some display systems
are real-time systems.
Also included are some automobile-engine fuel-injection
systems, home-appliance controllers, and weapon systems.
 Real-Time Systems
A real-time operating system (RTOS) is an operating
system (OS) intended to serve real-time applications that
process data as it comes in, typically without buffer delays.
Processing time requirements (including any OS delay) are
measured in tenths of seconds or shorter increments
of time.
Processing must be done within the defined
constraints, or the system will fail.
Few real-time operating system (RTOS) are eCos, LynxOS,
QNX, RTAI, RTLinux, Symbian OS, VxWorks, Windows CE,
MontaVista Linux, TRON
Operating System Services
 Operating System Services

Operating systems provide an environment for execution of

programs and services to programs and users
One set of operating-system services provides functions that
are helpful to the user:
User interface - Almost all operating systems have a user
interface (UI). Some provides Command-Line (CLI),
Graphics User Interface (GUI), Batch
Program execution - The system must be able to load a
program into memory and to run that program, end
execution, either normally or abnormally (indicating error)
I/O operations - A running program may require I/O, which
may involve a file or an I/O device.
 Operating System Services
File-system manipulation - The file system is of particular
interest. Programs need to read and write files and directories,
create and delete them, search them, list file Information,
permission management
Communications – Processes may exchange information, on
the same computer or between computers over a network.
Communications may be via shared memory or through message
passing (packets moved by the OS)
Error detection – OS needs to be constantly aware of possible
errors
May occur in the CPU and memory hardware, in I/O devices,
in user program
For each type of error, OS should take the appropriate action
to ensure correct and consistent computing
Debugging facilities can greatly enhance the user’s and
programmer’s abilities to efficiently use the system
 Operating System Services
Another set of OS functions exists for ensuring the efficient
operation of the system itself via resource sharing
Resource allocation - When multiple users or multiple
jobs running concurrently, resources must be allocated to
each of them
Many types of resources - Some (such as CPU cycles,
main memory, and file storage) may have special
allocation code, others (such as I/O devices) may have
general request and release code
Accounting - To keep track of which users use how
much and what kinds of computer resources
 Operating System Services
Protection and Security - The owners of information
stored in a multiuser or networked computer system may
want to control use of that information, concurrent
processes should not interfere with each other
Protection involves ensuring that all access to system
resources is controlled
Security of the system from outsiders requires user
authentication, extends to defending external I/O
devices from invalid access attempts
 User Operating System
Interface - CLI
Command Line Interface (CLI) or Command Interpreter allows direct
command entry
Some operating systems include the command interpreter in the
kernel. Others, such as Windows XP and UNIX, treat the
command interpreter as a special program 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.
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.
An alternative approach - used by UNIX, among other
operating systems - implements most commands through
system programs.
 User Operating System
Interface - GUI
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.
Usually mouse, keyboard, and monitor.
Icons represent files, programs, actions, etc.
Various mouse buttons over objects in the interface cause
various actions (provide information, options, execute function,
open directory (known as a Folder)
Invented at Xerox PARC in the early 1970s.
The first GUI appeared on the Xerox Alto computer in 1973.
Graphical interfaces became more widespread with the advent of
Apple Macintosh computers in the 1980s.
Many systems now include both CLI and GUI interfaces
Traditionally, UNIX systems have been dominated by command-
line interfaces. Various GUl interfaces are available including the
Common Desktop Environment (CDE) and X-Windows systems on
commercial version of UNIX.
Microsoft Windows is GUI with CLI “command” shell
Apple Mac OS X as “Aqua” GUI interface with UNIX kernel
underneath and shells available
Solaris is CLI with optional GUI interfaces (Java Desktop, KDE).
The choice of whether to use a command-line or GUI interface is
mostly one of personal preference.
As a very general rule, many UNIX users prefer command-line
interfaces, as they often provide powerful shell interfaces.
In contrast, most Windows users are pleased to use the Windows
GUI environment and almost never use the MS-DOS shell
interface.
 System Calls
System calls provide an interface to the services made
available by an operating system.
Typically written in a high-level language (C or C++)
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.
Mostly accessed by programs via a high-level Application
Program Interface (API) rather than direct system call use
Three most common APIs are Win32 API for Windows,
POSIX API for POSIX-based systems (including virtually all
versions of UNIX, Linux, and Mac OS X), and Java API for
the Java Virtual Machine (JVM).
 Example of System Calls
 System call sequence to copy the contents of one file to
another file
 System Calls
Why use APIs rather than system calls?
There are several reasons for doing so.
One benefit of programming according to an API concerns
program portability: An application programmer designing a
program using an API can expect their program to compile
and run on any system that supports the same API.
Furthermore/ actual system calls can often be more detailed
and difficult to work with than the API available to an
application programmer.
Regardless/ there often exists a strong correlation between
a function in the API and its associated system call within
the kernel.
 Example of Standard API
Consider the ReadFile() function in the Win32 API — a function for
reading from a file

A description of the parameters passed to ReadFile()

HANDLE file — the file to be read
LPVOID buffer — a buffer where the data will be read into and
written from
DWORD bytesToRead — the number of bytes to be read into the
buffer
LPDWORD bytesRead — the number of bytes read during the last
read
LPOVERLAPPED ovl — indicates if overlapped I/O is being used
 System Call Implementation
Typically, a number associated with each system call
System-call interface maintains a table indexed according to
these numbers
The system call interface invokes intended system call in OS
kernel and returns status of the system call and any return values
The caller need know nothing about how the system call is
implemented
Just needs to obey API and understand what OS will do as a
result call
Most details of OS interface hidden from programmer by API
Managed by run-time support library (set of functions built into
libraries included with compiler)
API – System Call – OS
Relationship
 Standard C Library Example
C program invoking printf() library call, which calls write()
system call

STDIO.H
 System Call Parameter
Passing
System calls occur in different ways, depending on the computer
in use.
Often, more information is required than simply the identity of the
desired system call.
The exact type and amount of information vary according to the
particular operating system and call.
Three general methods used to pass parameters to the OS
 Simplest: pass the parameters in registers. In some cases, may
be more parameters than registers.
 Parameters stored in a block, or table, in memory, and address of
block passed as a parameter in a register. This approach taken by
Linux and Solaris
 Parameters placed, or pushed, onto the stack by the program and
popped off the stack by the operating system
 Block and stack methods do not limit the number or length of
parameters being passed
Parameter Passing via Table
 Types of System Calls
System calls can be grouped six major categories: Process
Control, File Manipulation, Device Manipulation,
Information Maintenance, Communication and Protection.

Process Control
 end, abort File Management
 load, execute  create file, delete file
 create process, terminate  open, close file
process  read, write, reposition
 get process attributes, set  get and set file attributes
process attributes
 wait for time
 wait event, signal event
 allocate and free memory
 Types of System Calls

Device Management Information Maintenance

 request device, release  get time or date, set time or
device date
 read, write, reposition  get system data, set
 get device attributes, set system data
device attributes  get and set process, file, or
 logically attach or detach device attributes
devices
 Types of System Calls

Communication Protection
 create, delete  set permission and get
communication permission
connection
 allow user and deny user
 send, receive messages
 transfer status
information
 attach and detach
remote devices
 System Programs
Another aspect of a modern system is the collection of system
programs.
System programs, also known as system utilities, provide a
convenient environment for program development and execution.
Some of them are simply user interfaces to system calls; others
are considerably more complex.
They can be divided into:
 File manipulation  Program loading and execution
 Status information  Communications
 File modification  Application programs
 Programming language support
Most users’ view of the operation system is defined by system
programs, not the actual system calls
 System Programs
 File management – These programs Create, delete,
copy, rename, print, dump, list, and generally manipulate
files and directories

 Status information
 Some ask the system for info - date, time, amount of
available memory, disk space, number of users
 Others provide detailed performance, logging, and
debugging information
 Typically, these programs format and print the output to
the terminal or other output devices
 Some systems implement a registry - used to store and
retrieve configuration information
 System Programs

 File modification - Text editors to create and modify files

Special commands to search contents of files or perform
transformations of the text

 Programming-language support - Compilers,

assemblers, debuggers and interpreters sometimes provided

 Program loading and execution- Absolute loaders,

relocatable loaders, linkage editors, and overlay-loaders,
debugging systems for higher-level and machine language
 System Programs
 Communications - Provide the mechanism for creating
virtual connections among processes, users, and computer
systems
They allow users to send messages to one another’s
screens, browse web pages, send electronic-mail
messages, log in remotely, transfer files from one machine
to another
 Application Programs - In addition to systems programs,
most operating systems are supplied with programs that are
useful in solving common problems or performing common
operations called Application Programs.
 Such application programs include Web browsers, word
processors and text formatters, spread sheets, database
systems, compilers, plotting and statistical-analysis
packages, games.
 Operating System Design
and Implementation
 There are many problems in designing and implementing
an operating system.
 Design and Implementation of OS not “solvable”, but some
approaches have proven successful

Design Goals
 Internal structure of different Operating Systems can vary
widely
 Start by defining goals and specifications
 At the highest level, the design of the system will be
affected by the choice of hardware and the type of system
like batch, time shared, single user, multiuser, distributed,
real time, or general purpose.
 User goals and System goals
 User goals – operating system should be convenient to
use, easy to learn, reliable, safe, and fast
 System goals – operating system should be easy to
design, implement, and maintain, as well as flexible,
reliable, error-free, and efficient

 There is no unique solution to the problem of defining the

requirements for an operating system.
 The wide range of systems in existence shows that different
requirements can result in a large variety of solutions for
different environments.
 Operating System Structure
A system as large and complex as a modern operating system must
be engineered carefully if it is to function properly and be modified
easily.
A common approach is to partition the task into small components
rather than have one monolithic system.
Each of these modules should be a well-defined portion of the
system, with carefully defined inputs, outputs, and functions.
 Simple Structure – MS DOS
Many commercial operating systems do not have well-
defined structures.
Frequently, such systems started as small, simple, and
limited systems and then grew beyond their original scope.
MS-DOS is an example of such a system - It was originally
designed and implemented by a few people who had no idea
that it would become so popular.
It was written to provide the most functionality in the least
space, so it was not divided into modules carefully.
In MS-DOS, the interfaces and levels of functionality are not
well separated.
Application programs are able to access the basic I/O
routines to write directly to the display and disk drives.
 MS-DOS Layer Structure
 The operating system is
divided into a number of
layers (levels), each built on
top of lower layers.
 The bottom layer (layer 0),
is the hardware; the highest
(layer N) is the user
interface.
 With modularity, layers are
selected such that each
uses functions (operations)
and services of only lower-
level layers.
 UNIX

Like MS-DOS, UNIX was limited by hardware functionality,

the original UNIX operating system had limited structuring.
The UNIX OS consists of two separable parts
Systems programs
Kernel - The kernel is further separated into a series of
interfaces and device drivers, which have been added and
expanded over the years as UNIX has evolved.
Consists of everything below the system-call interface
and above the physical hardware
Provides the file system, CPU scheduling, memory
management, and other operating-system functions; a
large number of functions for one level.
This structure was difficult to implement and maintain.
Traditional UNIX System
Structure
 Layered Operating System

 With proper hardware support, operating systems can be

divided into pieces that are smaller and more appropriate
than those allowed by original MS-DOS and UNIX systems.
 Under a top-down approach, the overall functionality and
features are determined & separated into components.
 Information hiding is also important, because it leaves
programmers free to implement the low-level routines as
they see fit, provided that the external interface of the
routine stays unchanged and that the routine itself performs
the advertised task.
 In the layered approach, the operating system is broken into
number of layers – The bottom (layer 0) is the hardware and
highest (layer N) is the user interface.
Layered Operating System
 Layered Operating System
 The main advantage of the layered approach is simplicity of
construction and debugging.
 The layers are selected so that each uses functions (operations)
and services of only lower-level layers.
 This approach simplifies debugging and system verification.
 The design and implementation of the system are simplified.
 A layer does not need to know how these operations are
implemented; it needs to know only what these operations do.
 The major difficulty with the layered approach involves
appropriately defining the various layers.
 Because a layer can use only lower-level layers, careful
planning is necessary.
 Another problem with layered implementations is that they tend
to be less efficient than other types.
 Microkernel System Structure
 In the mid-1980s, researchers at Carnegie Mellon University
developed an operating system called Mach that modularized
the kernel using the Microkernel approach.
 This method structures the OS by removing all non essential
components from kernel to user level programs.
 Communication takes place between user modules using
message passing
 Benefits:
 Easier to extend a microkernel
 Easier to port the operating system to new architectures
 More reliable (less code is running in kernel mode)
 More secure
 Detriment : Performance overhead of user space to kernel
space communication
Mac OS X Structure
 Modules
 Perhaps the best current methodology for operating-system
design involves using object-oriented programming
techniques to create a modular kernel.
 Most modern operating systems implement kernel modules
 Here, the kernel has a set of core components and links in
additional services either during boot time or during run
time.
 Each core component is separate
 Each talks to the others over known interfaces
 Each is loadable as needed within the kernel
 Overall, similar to layers but with more flexible
Solaris Modular Approach
 Virtual Machines
The fundamental idea behind a Virtual Machine is to
abstract the hardware of a single computer (the CPU,
memory, disk drives, network interface cards, and so forth)
into several different execution environments, thereby
creating the illusion that each separate execution
environment is running its own private computer.
A virtual machine provides an interface identical to the
underlying bare hardware.
The operating system host creates the illusion that a
process has its own processor and (virtual memory).
Each guest provided with a (virtual) copy of underlying
computer.
The guest process is in fact an operating system - A single
physical machine can run multiple operating systems
concurrently, each in its own virtual machine.
 Virtual Machines
(a) Non-virtual machine (b) virtual machine
 Virtual Machines
First appeared commercially in IBM mainframes in 1972
Fundamentally, multiple execution environments (different
operating systems) can share the same hardware
Host machine & Virtual machine protected from each other.
Some sharing of file can be permitted in controlled manner.
Commutate with each other, other physical systems via
virtual networking
Useful for development, testing – Normally difficult to change
OS each time.
“Open Virtual Machine Format”, standard format of virtual
machines, allows a VM to run within many different virtual
machine (host) platforms.
 Para-virtualization
Presents guest with system similar but not identical to
hardware
Guest must be modified to run on paravirtualized hardware
Guest can be an OS, or in the case of Solaris 10 applications
running in containers

Virtualization Implementation
Difficult to implement – must provide an exact duplicate of
underlying machine
Typically runs in user mode, creates virtual user mode and
virtual kernel mode
Timing can be an issue – slower than real machine
Hardware support needed
More support-> better virtualization
i.e. AMD provides “host” and “guest” modes
Solaris 10 with Two Containers
VMware Architecture
The Java Virtual Machine