Dr. Mark Humphrys

School of Computing. Dublin City University.

Home      Blog      Teaching      Research      Contact

Search:

CA216      CA249      CA318

CA400      CA651      CA668


History of Operating Systems




(1) In 1940s-50s, Program = Computer


At start, there were no Operating Systems.

Computers were like the abstract model of a machine,
running one program literally and nothing else.

	1 user at a time
	1 program at a time
	Programmer operates machine himself.

Manually load program, 
run until crashed (dump memory and registers)
or finished (print output), 
revise program, run again, or run next program.

Interactive (great if you're the lone programmer)
but CPU idle for long periods 
(e.g. while program being revised,
or when program halts/crashes when
programmer not watching).
Long wait to use machine for other programmers.



DRIVING FORCES FOR CHANGE:
 LOT MORE PROGRAMMERS WANTING TO USE MACHINE
 COMPUTERS EXPENSIVE (ANY CPU IDLE TIME BAD)



(2) In 1950s-60s, Operator hired to run computer.

	Programmers have to submit jobs, receive results later.

Operator schedules jobs.
Jobs still stored on sequential (tape) access
(no random access medium yet).
Sequential tapes of jobs are prepared by operator
for the CPU to run through once.

Resident monitor, always in memory (first OS).
Doesn't decide order of jobs,
but does co-ordinate their sequencing,
automatic starting and terminating.
Jobs come with control cards to say what they need
to run.

Downside for programmer: long queues, not interactive any more,
 if error in program may have to wait days to retry it.
 Have to think things through in advance!




DRIVING FORCE FOR CHANGE:
 RANDOM (DISK) ACCESS BECOMES AVAILABLE.


(3) Pool of jobs on disk, random access.

 OS can now implement the human operator's algorithms
 in deciding sequence of jobs to run.
 Scheduling of jobs now totally automated (true OS).




DRIVING FORCE FOR CHANGE:
 I/O DEVICE SPEED IS MUCH SLOWER THAN CPU SPEED,
 SO CPU STILL OFTEN IDLE WHILE I/O GOING ON.



(4) Some parallelisation of I/O and computation.

Device controller is a piece of hardware
that can work in parallel with the CPU.
Not a parallel computer 
- it is just a specialised device for data transfer,
not a general-purpose computer.

Spooling - Print device controller is 
still copying data from disk to printer 
while CPU has already begun working on next job.
Next job can begin while previous is still printing out.

CPU can store output on disk if printer full
and move on.




DRIVING FORCES FOR CHANGE:
 WAIT TIMES STILL TOO LONG.
 Long jobs delay everything else. Run short jobs first?
 But if we have a small job that must be run once a day,
 then we cannot EVER run a program that will take 1.1 days.

 Also, program might do I/O half-way through
 its execution (rather than only at start/end).
 When program stops to wait for this I/O, CPU is idle.
 Maybe only short time, but it all adds up.



(5) Multi-programming.

Multiple jobs in memory (and running) at the same time.
Each memory space protected from each other.
OS picks one, executes it for a while, stops
(e.g. when program waits for input, or else randomly),
picks other to run.

CPU busy, but still batch model, not interactive.

Scheduling:
Job scheduling (or long-term scheduling)
- which jobs get into memory at all
CPU scheduling (or short-term scheduling)
- which to run at each step (many may be ready)



DRIVING FORCES FOR CHANGE:
 INCREASING NUMBER OF -USERS- WHO WANT TO 
 INTERACT WITH PROGRAMS WHILE THEY ARE RUNNING.
 COMPUTERS CHEAPER - CHEAP DUMB TERMINALS AVAILABLE.
 HUMANS' TIME IS EXPENSIVE - DON'T WANT THEM TO WAIT.



(6) 1970s-80s. Interactive time-sharing on mainframes.

Multi-programming where the program may be waiting on a USER.
OS will in the meantime service another program,
which may be interacting with another user.
Result: Multiple users share the CPU.
If the time-slicing is quick enough, they all feel
as if they have their own dedicated machine!

Programmers delighted - CPU kept busy,
yet interactive again, just like in (1).

User interaction at run-time allows a whole world of programs
that were never possible before.

In practice shared systems can get overloaded and slow down.



DEC VT100 terminal (1978).
This kind of terminal would be used to run programs on a mainframe shared with other users.
Users can now interact with programs at run-time!


 

DRIVING FORCES FOR CHANGE:
REAL COMPUTERS GET VERY CHEAP




(7) 1980s. Standalone PCs.

To some extent a return to simplicity of (5) and earlier
- no traffic problems.

Internet still unimportant.
LANs beginning to be used to coordinate file sharing.




Solitaire, bundled with Windows from 1990.
- How office workers wasted time on PCs before the Internet.




DRIVING FORCES FOR CHANGE:
 INTERNET BECOMES USABLE AND USEFUL.
 STANDALONE MACHINE NOW SEEN AS TOO ISOLATED.





(8) 1990s. Internet.

Web is killer app for Internet 1993.
Much use of information on shared remote web servers. 
Shared file systems.
Shared email systems.
Return to some of the problems of (6) - traffic problems.




The shared mainframe returns:
The Web.


 

DRIVING FORCES FOR CHANGE:
 BROADBAND (AT HOME).
 THEN LATER: MOBILE BROADBAND.
 



(9) 2000s

  1. Multimedia - video, audio, photo.
    YouTube (2005) probably the defining application of 2000-10 period.

  2. Mobile - Internet on mobile devices.
    Proper OSes (with proper file systems) on mobile devices.
    iPhone (2007) probably the defining invention of 2000-10 period.




The decline of dialup, 2006-08 (in Ireland).



The mobile world before 2005:
No or limited Internet.
Image from here.


  


Feeds      w2mind.org

On Internet since 1987.