Download History of Operating Systems

COMP091 – Operating Systems 1
My Name: Prof. Baker
Web Page:
http://fleming0.flemingc.on.ca/~chbaker
Lecture notes and assignments will be posted to
the web page
Email: [email protected]
Or: [email protected]
Assignments are to be submitted as email
attachments
Marking Scheme and Course Outline
• Lectures and lab assignments posted at
– http://fleming0.flemingc.on.ca/~chbaker/
• Marking scheme as follows:
– Two tests weeks 7 and 15 @ 15%
– Lab test 10% Week 14
– 10 labs at 5%
– Professionalism and comprehension 10%
Lab Reports
• It is expected that students will help each other with lab
assignments – it's how things happen in the real world
(sometimes) and is more rewarding and effective
• But it is required that each student ultimately complete
the lab independently, and prepare their own lab report
• Guidelines for writing lab reports are posted here:
http://fleming0.flemingc.on.ca/~chbaker/LabReports.d
oc
• Submit reports as email attachments, PDF format
preferred
COMP091 – Operating Systems 1
History of Operating Systems
Generations
•
First Generation
–
•
•
•
No OS as we know it
Second Generation
–
Batch processing
–
One job at a time
Third Generation
–
Multi-programming
–
Spooling
Fourth Generation (now)
–
Massive interactivity
–
GUI
–
Programming by system calls
In the very early days:
von Neumann Architecture
• John Louis von Neumann, Hungarian
mathematician 28 December 1903 - 8 February
1957
• Proposed the stored program concept
• Program instructions stored in memory along
with data
– Rather than being wired on plug boards
• Circuitry decodes instructions
• Just have to get code into memory
In the very early days:
Programming
• Computers had rows of switches representing
bits
– Address row contained address in binary
– Data row contained content in binary
• Load button caused data to be loaded into
address in memory
• Programming meant setting the address
switches, then the data switches, then pressing
"load"
• Repeat for each instruction and data address
In the very early days:
Operating
• After loading all the instructions and data,
program had to be started
• Computer had a "Run" button
• "Run" button set next instruction counter to first
memory location and started execution of
instructions there
• "Run" button was the entire operating system
• But it introduced the modern operating system
concept of Boot Loaders
Boot Loaders
• Does not mean boot as in kick as in kick start
• Refers to old expression "Pull yourself up by
your boot straps"
– Of course that can't be done because who has
straps on their boots
• But the idea of a program that gets loaded
without the help of some other program is
reminiscent of this
• Hence the bootstrap program, or boot loader
• The "run" button was the first boot loader
In the very early days:
Automatic Programming
• Programming by switches very tedious and error prone
• Eventually programs were coded onto paper tape using a
paper tape machine with a keyboard
• "load" button could read entire program from paper tape
into memory ready to run
• This was referred to as automatic programming
– Some though it would spell the end for programmers
• Introduced first modern OS component:
– device drivers
Device Drivers
• First device drivers were necessary to control the devices
that contained the programs
• These were supplied by the computer manufacturer and at
first were hard wired
• Programmers wrote their own drivers to interact with
hardware at run time, after booting was finished
– Manufacturers drivers were just for booting
• Eventually this duplication of effort led to another modern
concept
– Runtime Library
Runtime Libraries
• Early run time libraries were essentially open
source creations
• Programmers shared common code among
themselves
• Later, manufacturers began distributing runtime
libraries with their computers
– Made machine more usable
– Maybe ensured efficient use
• Library routines were linked to programs by
“link editor” after compiling or assembling
I/O Control Systems
• On early systems programs directly controlled I/O
devices using custom code (maybe shared in a library)
• Eventually manufacturers made their I/O libraries
available at run time as an I/O Control System
• Part of main memory was set aside for the IOCS, the
rest of memory was for users
• This was the first development to resemble on O/S
• It introduced the idea of Memory Management
• And made OS functions available at run time
In the very early days:
Computer Operators
• "Automatic programming" also introduced the
idea of the Computer Operator
• Programmers would fill out a form specifying
their run time requirements
• Run request form, along with paper tape, card
deck or magnetic tape(s) would be handed to
operator to run when computer became
available
• Programmer didn't need to be there at run time
to set switches
Computer Operators
Scheduling
• Computer operators scheduled jobs into
computers one at a time
• Early job queues consisted of stacks of Job
Request forms, maybe clipped to a clothes line
• Users were charged for use of computer time,
and for use of peripherals
• Operators would keep track of this info on the
Job Request Form, but a more efficient method
was desirable
– Especially from the accountants' point of view
Second Generation -- Monitors
• The IOCS was in memory and active at run time
• And was involved in I/O operations as well as
starting and stopping jobs
• So accounting was added to the IOCS to allow
accurate billing for machine time and I/O
utilization
• These systems now came to be called monitors
and signaled the start of the second generation
of operating systems
• And introduced the OS concept of Accounting
Accounting
• Accounting is still present in modern multi-user operating
systems as part of the Security System
• Security systems are concerned with identity and that means:
• Identification
– Who are you
• Authentication
– How do we know
• Authorization
– What can you do
• Accounting
– How much of it did you do
Better Scheduling
• With operators manually scheduling jobs, there
would be idle time between jobs while the
operators set up the next job
• This wasn't a problem if jobs ran for a long time
• The idle time was small relative to the
productive time
• With faster computers, jobs ran faster and the
idle time became significant
• The solutions was another modern operating
system concept: The job queue
Batch Operating Systems
• With the addition of a job queue to the monitor,
more efficient scheduling became possible
• Jobs would be read into a job queue when they
were submitted
• The monitor would start the next job as soon as
the last job finished
• Jobs' resource needs would be described by Job
Control Language statements stored on the
queue with the job
• These batch OS systems were the first real OS's
Some Examples
• Monitors
– FORTRAN Monitor System, General Motors
Operating System, Input Output System
• Batch Systems
– Note that these OS were almost all supplied by
the computer manufacturer
– GECOS, SCOPE (Supervisory Control of
Program Execution - CDC), EXEC (Univac) ,
MCP (Burroughs), IBM 1410/1710 OS
nd
2
Generation Problem
• In 2nd generation OS only one program could
run at a time
• If that program was waiting for I/O the entire
machine would be idle
• But if the monitor could hand the machine to
another job while the first one waited the idle
time wouldn't be wasted
• This introduced another modern concept
– Multiprogramming
– More than one job loaded and ready to run
Another Problem
• Multiprogramming OS's switched jobs when
one became idle
• But on-line users didn't want to wait long times
for all other users to go idle
• Interactive users required time slices on a
regular basis
• A time sharing OS would stop jobs after a short
period of time to give some time to other users
• Everyone had the illusion of a computer
available for their exclusive use
Third Generation
Multiprogramming
• The third generation of Operating Systems was
characterized by multiprogramming capabilities
• Multiple jobs loaded in memory and ready to
run
• OS passes control to another job when one goes
idle
• Timesharing systems allocate regular time slices
to interactive jobs so none will be inactive for
unacceptable periods of time
Third Generation
Memory Partitions
• Multiprogramming required that many jobs be
in memory at once
• This required the modern OS capability of
memory partitioning
• OS divides memory into partitions
• Allocates a partition to each job
• Memory Maps map relative addresses into
partitions' real addresses so jobs don't need to
know where they are actually loaded
• Originally fairly static mapping
Third Generation
Virtual Memory
• With multiprogramming there could be many
jobs loaded in memory at once, and the more
there were the more efficiently the machine
resources could be deployed
• Soon memory just wasn't large enough to hold
enough jobs to keep the increasingly faster
CPU's supplied with work
• Virtual memory solved this by temporarily
moving idle jobs from memory to disk until it
was time to reactivate them
Third Generation
Thrashing
• Moving jobs (or portions called pages) from real
to virtual memory came to be called paging
• It allowed more jobs to be available to use the
CPU resources
• But it also consumed resources
• If the resources used by paging was too much
resource nothing would get done
• This condition is called thrashing
• Efficient paging algorithms seek to prevent
thrashing
Thrashing Example
• In the 1970's IBM sold an operating system
called System 370
• It was a multiprogramming virtual memory
batch OS
• They also sold VM, (Virtual Machine) which
allowed customers to run more than one IBM
OS at the same time
• In one case a thrashing S370 system was
resolved by running the S370 OS under VM
• VM had a more efficient paging algorithm
Third Generation
Spooling
• Another problem introduced by multiprogramming is that
you can't time share a printer
– Jobs would be intermixed on the paper
• 2nd generation OS gave jobs exclusive control of I/O
devices like printers
• 3rd generation had to introduce spooling
– Printed output intercepted by OS and stored in a disk
file called a spool, or print queue
– Tanenbaum says SPOOL = Simultaneous Peripheral
Output On Line
• Complete print jobs are sent to printer (or other device)
when the generating job is finished
Third Generation
File Systems
• Early disk drives had removable "disk packs" and tape
drives
• Users handled them in whatever way they wished,
addressing the hardware in hardware terms
• With larger disks, and the use of disk space by the OS for
spooling, job queues, page files etc, it became desirable for
disks to have a common format
• Users would use space on these permanently mounted
system disks, facilitating scheduling
• The now familiar hierarchical file systems were introduced
to enable sharing of space on system disks
Third Generation
Processes
• Originally the granularity of multiprogramming
was at the level of a complete job
• With virtual memory it became more efficient to
swap pages rather than jobs
• Also, jobs spent a lot of time using system calls
to accomplish objectives and that involved
processes running in the memory space of the
OS
• It became necessary to start and stop processes
rather than jobs leading to the modern OS
concept of processes
Third Generation
Threads
• Jobs running in a modern OS can start processes
that run in the memory of the OS, using drivers
or other functions available through system calls
• Each process shares the memory where the code
resides, but is allocated separate memory for
data, including state information
• Each of these processes represents a “process
thread” through the memory of the shared code
• The shared code is multi-threaded
Third Generation
Scheduler
• Scheduler: Adds new processes to the process
table and removes completed processes from the
process table
• Process table contains
–
–
–
–
Memory area assigned to the process
Priority of the process
State of the process (ready or waiting)
...
Third Generation
Dispatcher
• Dispatcher: Controls the allocation of CPU (of
time slices) to the processes in the process table
• The end of a time slice is signaled by an
interrupt.
• Each process is allowed to execute for one time
slice
• It performs "process switch" - procedure to
change from one process to another
• ProcessA -> Dispatcher -> ProcessB
Other
rd
3
Generation Issues
• Deadlock
– If process A waits on process B while process B
waits on process A neither will ever complete
– This is called deadlock
– 3rd generation OS had to learn to detect and
prevent deadlock
• Security
– With so many processes on the same machine OS
had to learn how to keep them separated
4th Generation
• Generally considered to be the OS's that operate
modern desktop computers
• Windows, Linux, Android, and a few others
• Massive reliance on OS system calls
• Ubiquitous networking
• Essentially Interactive
Resources
• http://www.personal.kent.edu/~rmuhamma/OpS
ystems/Myos/osHistory.htm
• http://en.wikipedia.org/wiki/History_of_operati
ng_systems
• http://www.osdata.com/kind/history.htm