Download History of Operating Systems

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Copland (operating system) wikipedia , lookup

Spring (operating system) wikipedia , lookup

Distributed operating system wikipedia , lookup

VS/9 wikipedia , lookup

Library (computing) wikipedia , lookup

Booting wikipedia , lookup

Process management (computing) wikipedia , lookup

Burroughs MCP wikipedia , lookup

CP/M wikipedia , lookup

Paging wikipedia , lookup

Transcript
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
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
–
•
Authentication
–
•
How do we know
Authorization
–
•
Who are you
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 introduces 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
Generations 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
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%
– 10 labs at 5%
– Professionalism and comprehension 10%