The Development of Operating Systems

{ A Sketch }

 

Introduction

 

     For those who grew up having an entire computer sitting at their finger tips waiting at their beck and call to carry out every command it is hard to imagine punching a program into punch cards, submitting it over a Dutch door and then waiting at least 24 hours to get a printout of the run.  Or, even worse, driving 30 miles and waiting one week between program submission and receipt of the printout.  But, to understand how today’s operating systems came to be what they are, we need to go back “to those days of yesteryear,” as the saying goes.

 

The chief function of an operating system, we said, is to manage the resources of a complex computer system.  It has been said that necessity is the mother of invention.  The development of operating systems to their present day form is a good illustration of that.  At each stage in this development, bottlenecks were found which prevented using the computer resources to their fullest capacity.  The need to eliminate those bottlenecks gave impetus to inventiveness leading to the next step in the history of operating systems.

Stages of Development

 

PreHistory

 

The earliest computers did not have software.  Their functionality was hardwired.  To reprogram the machine required rewiring.  These machines, of course, did not have an operating system.

 

User SetUp and Breakdown

 

With the advent of the stored program machine the day of the von Neumann architecture machines began.  But the early machines were costly behemoths, available only to clients with deep pockets.

 

When it was not uncommon to pay $1 million for a computer, those who used these machines for business or research were willing to go to great lengths just to get their “moment in the sun,” so to speak.  Computers were scheduled around the clock and users had to come in at their scheduled time.  In addition to loading their programs, the users had to load (and link, if necessary) any system software, such as compilers and device drivers, needed for their run.  And additional work was required to make the machine available for the next user.

 

Operator Controlled Machines

 

Very soon it became clear that during the rather lengthy setup and breakdown time the very expensive computer was not doing useful work.  This waste of resources had to be remedied.  A computer operator was put in charge of the machine.  Users submitted their programs on punch cards.  The operator scheduled job execution, loaded the programs, collected the output and performed any required setup operations.  By running jobs with similar system requirements in the same time frame, the setup and breakdown  process was streamlined.  Jobs could also be arranged by priority, run time and other criteria.

 

Simple Batch Systems

 

To further reduce slack time, the amount of time during which the computer did no useful work, the scheduling and loading functions were turned over to a program called the monitor (called a resident monitor, if it stayed in memory at all times).  Users submitted short instructions in a cryptic language called JCL (job control language) to aid the monitor in its task.  Jobs were grouped together and run in batches.  Often a separate computer was used to handle the I/O operations.  Debugging for this and other early systems was accomplished by interpreting a core dump, a hexadecimal snapshot of the contents of memory and all registers at the time of program error.  Hardware features such as memory protection, timers, privileged instructions and interrupts were added to machines during this stage of development.

 

Multiprogrammed Batch Systems

 

An I/O operation is orders of magnitude slower than instruction execution.  For this reason the processor would sit idle a large proportion of the time, despite the efficiency improvements brought about by batch systems.  Instead of doing useful work, the processor would wait for an I/O operation to complete.  The observation was made that more than one job could be read into memory, allowing the processor to switch back and forth between jobs (or processes, as they came to be known).  While one process was involved in I/O, another could be running - i.e., making use of the processor.  The introduction of multiprogramming or multitasking laid the foundation for many features found in today’s operating systems.

 

Implementation of multitasking required a more sophisticated form of scheduling, as well as software to manage the placement of jobs into memory.  Thus, schedulers and memory management modules were added to the software repertoire of an operating system.

 

Interactive Multiprogramming

{Time Sharing Systems}

 

As the price of machines came down and wages went up, the programmers’ and users’ time became an important commodity.  The importance of good response time and short turnaround time were factored into the OS design process.  The major step taken was the advent of time shared systems.  Instead of just submitting jobs, the user was given interactive access to the machine via a command line interface.  Since the processor speed was many orders of magnitude faster than the actions taken by the user, under ideal conditions the user could work as if she had sole access to the machine.

 

Single User Multiprogramming

 

The wedding of the personal computer to multiprogramming resulted in extremely useful computer systems.  The could the user run several processes at one time, doing useful work with one program while waiting for another program to complete its task.  In addition, he could perform operations which require two programs to run simultaneously, e.g., copy text from a web page and paste it into a word processing document.

 

To clear up confusion:

Since the terms task and process are often used interchangeably, it may seem that multitasking and multiprocessing would be also.  This is not the case.  From page 64 of Stalling, we see that multiprogramming and multitasking are synonymous.  But on page 198 we read these definitions:

            Multiprogramming: The management of multiple processes within a uniprocessor system.

            Multiprocessing: The management of multiple processes within a multiprocessor.

We see, then, that the term multiprocessing comes from multiprocessor, whereas the term multitasking comes from task.  Since a process (or task) is a program in execution, we can see that the concept “the management of multiple processes” is not far from “the management of multiple programs.”  It is unfortunate that the development of OS terminology created this source of confusion.

 

Closing Note: A good sketch of OS history can be found at:

          http://www.cs.uregina.ca/~hamilton/courses/330/notes/history.html