History of Operating Systems 1950s Why review the history of OSs? Seeing how OSs developed shows the link between the capabilities of hardware and the design of OSs. It explains why OSs are as they are now.

History seems to repeat.

UNIVAC 1

This figure and some others in the slides are from an earlier version of the prescribed text Operating Systems Concepts (8th edition) by Silberschatz, Galvin and Gagne.

Operating Systems Lecture 02 page 1 Operating Systems Lecture 02 page 2

Total Control COMPSCI 101 1950’s style

Circa 1950s • clear storage were very expensive. • ready the compiler paper tape • ready the tape for the compiled output Users (they were all programmers) booked the • put the source code cards in the card reader whole machine. They had to: • set the switches to load the compiler • start the compiler • prepare their program and data cards • if errors - work out what they are and try again • do all the setup and loading required • clear computer storage • control the computer through console switches • ready the compiled object tape (still needs linking) • debug using console lights and switches • ready the i/o subroutines tape and • ready the tape for the output runnable program This required a large amount of knowledge • load and run the linker about the computer and peripherals. • ready the or output tape • clear computer storage Inefficient use of the machine. • ready the runnable program tape • put the data cards in the card reader Computers could execute 10s of thousands of • load and run the program instructions per second. • if errors – work out what they are and try again But they were idle almost all the time.

Operating Systems Lecture 02 page 3 Operating Systems Lecture 02 page 4 What did the OS look like? Computer Operators & Off-lining

Most of the OS at this stage was comprised of the decisions and actions of the user.

There were rudimentary components such as standard IO routines which were the forerunner of device drivers and system calls. Several speed-ups • experience • multiple operators (early multiprogramming?) • No memory management – every address was • batching similar jobs together (sometimes called phasing) reachable. • keeping the programmer away from the computer • No file system – the user loads the correct tapes. • Security – the door could be locked. Changes • IO was polled for - no need for anything faster No real changes from the hardware or OS perspective. • Some standard IO routines – useful code to read and But procedures were more formal. write to tape and printers. The first UIs were instruction sheets to the operators. • Only one program at a time. The next step was to automate some of these procedures. • No problems with synchronization. • Programs communicate through paper tapes. • was almost the bare machine. Off-lining • Accounting maintained independently of the system. The arrival of magnetic tape substantially improved IO. Small cheap computers did the slow IO from paper tape to mag tape. And from mag tape to the printer. The big expensive computer used the mag tapes for IO. Several programs submitted to the BEC on one tape. The first parallelism in computer systems.

Operating Systems Lecture 02 page 5 Operating Systems Lecture 02 page 6

Resident monitors Control programs

The computer operators had formal procedures. The resident monitor needed instructions.

Get the computer to help. Special cards that tell the resident monitor which programs to run What it needs $JOB A program always in memory (hence the “resident”). $FTN A control language - commands had to be given to the resident $RUN monitor. $DATA The starting point of OSs. $END

Resident monitor could Special characters distinguish control cards clear memory used by the last program (but not itself ☺) from data or program cards: load the next program $ in column 1 find the data for the program // in column 1 and 2 jump to the start address of the new program, returning to the 709 in column 1 resident monitor when finished it also maintained the standard IO routines in memory The first Job Control Languages (JCLs). What was missing?

Operating Systems Lecture 02 page 7 Operating Systems Lecture 02 page 8 What had changed? Change in the hardware

• No memory management – every address was still reachable. Disk drives • Still no real file system, but there is a distinction Disks provided substantially faster access to large amounts of between data and programs. storage. • Security – maintained by the operators. • IO still polled for. Interruptible processors • Programmers now basically forced to use the standard Devices raising interrupts and processors responding to them IO routines. substantially changed the way IO was performed. • Only one program at a time. But two programs in Development from single location return addresses to the use memory. of a stack. • Still no problems with synchronization. • Problems with bad programs – system needed resetting when something bad happened. I/O devices and the CPU can execute • Depending on the types of devices the output of one concurrently. program could automatically become the input of another. I/O is from the device to local buffer of • User interface was the JCL. controller. • Accounting still maintained independently of the system. CPU moves data to main memory from local buffer of controller.

Device controller informs CPU that it has finished its operation by causing an interrupt.

Operating Systems Lecture 02 page 9 Operating Systems Lecture 02 page 10

SPOOLing Multiprogramming Simultaneous Peripheral Operation On-Line Time waiting for IO can be used. No longer need the small cheap computers for IO.

We are doing things simultaneously. processing a program reading cards for another program printing data for another program

The next step is obvious. Memory now holds Have several programs in memory at once. • a running program • interrupt driven card reader control program What do we need? • interrupt driven printer control program a lot more memory • disk control software a scheduler • buffers for data being transferred between the a way of keeping track of which program is where in memory computer and devices and where its data is, on card, disk etc • a program loader better ways of handling errors • a JCL interpreter a way to preserve the memory of each program • a rudimentary file system – some data stays “permanently” on the disk

Operating Systems Lecture 02 page 11 Operating Systems Lecture 02 page 12 Memory protection Why do we need both?

Can be provided by software. What is an example? A system that keeps programmers completely away from direct access to memory addresses. If we had modes and privileged instructions Alternatively, a check of every address by an instruction filter. but full memory access Obviously no memory protection But far more efficiently and safely done by but also no protection of the privileged instructions - put any code you want in the system areas of memory hardware. If we could limit memory accesses but there Two requirements were no modes and privileged instructions Operating modes and privileged instructions Instructions are used to set up the memory management Limited address range registers. If these are not privileged a user can change the area of Provide hardware support to differentiate memory available. between at least two modes of operation. 1. User mode – execution done on behalf of a user. 2. Kernel mode (also monitor mode, supervisor mode, privileged mode or system mode) – execution done on behalf of the .

Operating Systems Lecture 02 page 13 Operating Systems Lecture 02 page 14

Processor modes Memory protection

Each process gets allocated an area of memory Mode bit which it can access. Added to the hardware processor status register (or similar) to All accesses outside that memory cause an indicate which mode the processor is operating in. exception (or fault). Interrupts, faults, system calls cause the processor to change !fixed size partitions mode and … processes were designed to load in a particular jump to a particular location. partition Privileged instructions cannot be executed in user mode. !base-limit registers !memory pages

Devices can be protected using memory protection or privileged instructions Interrupt/fault/system call kernel user

set user mode

Operating Systems Lecture 02 page 15 Operating Systems Lecture 02 page 16 Batch systems Batch system innovations With memory protection and processor modes Each job had its own protected memory. we can safely have multiple programs in memory. Disks with file systems. Files were associated with owners. from Scheduling was automated. The aim was to effectively utilise all of the expensive hardware. Computer operators now too slow. to Individual jobs could be suspended or killed, allowing other jobs to progress.

Computer operators had consoles. Maybe even VDUs.

Accounting could now be done automatically.

But from the programmer’s point of view nothing much had changed.

Operating Systems Lecture 02 page 17 Operating Systems Lecture 02 page 18

Before the next lecture

Read textbook sections

1.3 Computer-System Architecture 1.11 Computing Environments 2.7.5 Hybrid Systems

Operating Systems Lecture 02 page 19