1. Copyright © 2005 - Curt Hill The Evolution of Operating Systems Pre-OS to Modern

2. Copyright © 2005 - Curt Hill Evolution of OS The picture before an OS: The hardware usually consisted of CPU, card reader/punch and a tape drive The environment was definitely batch and uni-tasking The only real system program was a loader that took the machine language off of a card reader, loaded it into memory and executed it

3. Copyright © 2005 - Curt Hill Pre-OS Each program that used the tape drive wrote their own access routines –There really was not a file system –Programs did not share files very much – one program or suite of programs used one tape After a while of this it became clear that somebody’s tape access routines were best –Lots of card deck copies

4. Copyright © 2005 - Curt Hill Pre-OS These copied decks would eventually be loaded into a common library If everybody is accessing tape, then load those access routines into some part of memory and let them stay there permanently This is the root of an OS - part of the first kernel

5. Copyright © 2005 - Curt Hill Batch Systems A batch system is like a doctor’s office MD’s office –Patients are placed in one of several rooms –Support personnel do all the auxiliary things –Dr. bounces from room to room performing service –Dr. is kept busy, but patients wait The goal is to maximize the utilization of a resource –The Dr. or the CPU

6. Copyright © 2005 - Curt Hill Early batch systems As the hardware became faster and memory larger, people realized that the most expensive component of the system, the CPU was largely idle In the time it took to read a tape or card reader the CPU did nothing and it has always been the case that CPUs are faster than peripherals Two solutions emerged: blocking and multitasking

7. Copyright © 2005 - Curt Hill Tape Drives A tape drive of the 70s could read at 90 inches of tape per second with densities of 1600 bits per inch It could go from full speed to dead stop in only a ¼ inch of tape Thus there is a ½ inch inter record gap A card image (80 bytes) only take 1/20 of an inch of tape

8. Copyright © 2005 - Curt Hill Blocking A physical record is what is written to a tape A logical record is what program uses Generally not the same because of blocking The system makes each physical record to contain many logical records –A large block can be read/written in much less time than many smaller individual blocks The operating system then becomes a buffer to the hardware –It accepts the records, one a time from the program –Writes the block only when it is full –This helps tape utilization as well

9. Copyright © 2005 - Curt Hill Buffering An active channel can access memory without the CPUs involvement – Direct Memory Access This enables double, triple or larger buffering In double buffering: –The channel is working on block 1 while the CPU is working on block 2 –The CPU has to wait only when it has finished a block but the next one is not ready yet

10. Copyright © 2005 - Curt Hill Multi-Tasking Multi-Tasking become common in the late 50s and 60s –By this time even buffering could not improve I/O delays enough –It was also the case that memory was cheaper and CPUs faster Here the object is to run several programs at once

11. Copyright © 2005 - Curt Hill Multi-Tasking Assume four programs are in memory at once A program would get control and keep going until it had to wait for an I/O request Instead of the CPU being idle it just then moved on to the next program Cons –The programs ran slower –They took longer amount of wall clock time Pros –CPU was better utilized –Throughput increased

12. Copyright © 2005 - Curt Hill Multi-Tasking Enhanced The problem: –A program that was very CPU intensive could delay other programs –These others be done in a short time had they reasonable access to the CPU Two solutions, both of which became common –Priorities –Time slices

13. Copyright © 2005 - Curt Hill Task Priorities Each task is given a priority When the dispatcher is looking for a task to execute it looks for the highest priority first and oldest second Make the high I/O programs to have a higher priority and the CPU intensive lower When an I/O request is satisfied an interrupt is generated and the high priority task is re-started

14. Copyright © 2005 - Curt Hill Time Slice Every fixed amount of time a clock timer interrupt occurred The current program was suspended and the next program started The interrupt could be on a fixed basis or the timer started when the program restarted With a time slice, every program was guaranteed that it would get a least a little CPU in each second –Hence all programs make progress towards completion

15. Copyright © 2005 - Curt Hill Later batch programs Running multiple jobs at once greatly increased CPU utilization and efficiency but it also introduced other problems These problems were solved in various ways The first problem is resource allocation

16. Copyright © 2005 - Curt Hill Resource allocation No longer could a program assume that it had the whole machine Certain resources cannot be shared: –Tape drives –Printers –Memory –Communication lines When a job was being prepared to start it must not be run until the resources it needed were available –These resources need to be announced

17. Copyright © 2005 - Curt Hill Disks Disks can often be shared since they are random access devices Two programs can both write to the same disk at the same time –Provided the operating system controls head positioning, among other things –Provided the disk does not run out of space –This can be handled by allocating the space ahead of time If the job needs a disk pack that is not mounted –It must be waited until all the jobs using one of the packs are done –A demount and mount operation lets the job continue

18. Copyright © 2005 - Curt Hill Memory Memory can be shared but it takes cooperating programs to do so –Presumably there is enough to go around –However, if I want 512K and only 256K is currently available then I wait Before Virtual Memory systems had either fixed or variable memory partitions –A fixed memory system divided memory into fixed sizes where each program had to fit in one of the sizes –Two adjacent partitions could be collapsed into one for larger programs

19. Copyright © 2005 - Curt Hill Printers Printers cannot be shared Worse yet card devices and printers are excessively slow, even compared to disk or tape, let alone CPU These problems caused the systems programmers to develop job entry subsystems

20. Copyright © 2005 - Curt Hill Spooling The next major step was spooling Most programs deal with their printer as a write only device –They need no feedback from it to do the job, although such feedback is available So instead of having an online printer, save the print output to tape or disk –This is a print queue When the printer becomes free –Print the next job in the queue Of course there were many queues, based upon the printer chain, form type etc

21. Copyright © 2005 - Curt Hill Job Entry Subsystem Print spooling is the back end –Spool the cards on the front end as well Read in the jobs from cards and save them on temporary disks Scan through them and figure out resource requests When a job terminates –Then there are free resources –Find the next job whose resource demands are a subset of whats free –Run that job

22. Copyright © 2005 - Curt Hill Later Improvements Remote Job Entry –Put at a distant site: card reader and printer and transmit the data to the central CPU location –Did not matter much whether the distant site was in a different part of the building or in a different state, except in how it communicated Library updates –Instead of having the entire job, such as the program source on the card deck, have the program stored in a library –The run of the job now becomes updating the library, compile and run –This greatly minimizes the amount of data that has to be transmitted and reduces the risk that the program (in card form) could be damaged

23. Copyright © 2005 - Curt Hill Change Somewhere in the 1960s something changes Hardware is declining in price Cheaper hardware makes for larger demands for software People time becomes a resource to be reckoned with This leads to Time Sharing

24. Copyright © 2005 - Curt Hill Time Sharing Make the CPU not the doctor, that is rationed, but the butler who is on call –People are the master Do commands on demand –Develop online editors This only works because of the way people work on programs

25. Copyright © 2005 - Curt Hill People Habits Compared to computers people are abysmally slow Furthermore they spend most of their time on tasks that are not CPU intensive –Browsing listings –Modifications with an editor –Data entry Thus with an average of 100 users, only one to five is doing anything computationally expensive

26. Copyright © 2005 - Curt Hill Time Sharing Each user is given a time slice Most of them do not use it because of the light tasks they are in This gives more power to those who are doing the compile that consumes a lot of CPU Time sharing is first common in the 1960s and becomes the interface on which UNIX is designed