There are two reasons why we start this course with a history of operating systems.
1. Getting an overview of the material
A byproduct of this is that we also see the motivation for making OSs what they are today.
2. A reminder to you of things you may not have thought much about.
It is interesting that our story starts off almost where it ends. The first users of computers had total control over the machine. Not only did they write machine code programs, they also had the responsibility of loading the programs into the computer, resetting the computer and telling it where to start executing.
Of course this required a large amount of knowledge of the computer system the person was working with. The principle advantage of such a system was that at least some people got to work with computers. And those people that did have access to the computer could use it exactly as they wanted (more or less).
Unfortunately this wasn't as many people as wanted to work with computers. Money was at fault (or rather the lack of it). Computers were incredibly expensive machines. The first digital electronic computer in New Zealand was an IBM machine (surprise, surprise) purchased in 1960 by the Department of Inland Revenue.
So we need to concentrate on money. If we want more people to have access to computers we need to examine how to make them cheaper. Since this is going to take time (at least a few years to make computers substantially cheaper in the 1950's) we must look at other ways of getting more work into and out of the computer. The trouble is the way they are used.
Imagine a computer capable of performing hundreds of thousands of instructions/second (incredibly slow by the standards of today). Almost all of the time every day, this computer is performing no instructions. Why?
Here is a sequence of steps to run a program on some data.
By the way these subroutines, particularly the input/output ones are the first pieces of code which are going to lead to operating systems as we know them. There was a progression from just loading the subroutines while compiling and letting the compiler sort out references to using loader programs which could load subroutines at different addresses and adjust references at load time.
This is if everything went according to plan. Normally something went wrong, and the user might interactively debug the program by examining locations in memory.
However by the 1960s computers were getting easier to use. The list of instructions for the IBM 1620 (the remains of which are in our musuem on the second floor) were simple, understandable (to someone with only a little technical knowledge) and repetititive. So to increase the amount of work done we can employ people who become experts at following the instructions and moving the work through the computer. The arrival of the computer operators.
Operators sped the work up via several ways. Because of their experience they could perform the same tasks faster than programmers who only had access to the machine a few times a week. It was possible to have one operator loading the next tape whilst another operator gathered output.
A big time saver was that under the previous system, if something went wrong, say the program did not compile, programmers would attempt to fix the problem and get the program running in their allotted time at the machine. Effectively the computing time of the machine was being wasted even more.
By inventing the operator, the programmer was isolated from the machine. If a program refused to run or compile properly, the programmer was just presented with a core dump on the printer showing the failed results and the computer was immediately put to work again, processing someone else's job.
Further savings were made as work was submitted in large quantities to the operators. They could then make high level decisions as to the order in which the material was processed. e.g. All FORTRAN programs could be compiled in batches. This avoided the step of repeatedly having to load the FORTRAN compiler. This is the first time we mention "batch" in this course, unfortunately it is soon to have a different meaning. In fact this meaning of "batching" is sometimes referred to as "phasing".
In order to use computer operators we need to make some changes. The programmers need a way of telling the operators what to do. This could be as simple as a list of instructions scribbled on a bit of paper but it quickly became a series of formal requests. Run Job X with data tape Y, print the results on printer Z. At one level this can be seen as an improvement in the user interface. Previously the programmer had to know exactly how to control the machine. The programmer no longer needs to know lots of the detail, e.g. how to reset the computer. It is also the beginning of a formal language to control the workings of the computer, it will eventually progress into job control languages and shell languages.
Another new thing with the introduction of computer operators is that information for different users needs to be kept carefully separated. This means that users have to be identified to the system (the computer operators in this case). Along with this change came the possibility of different privileges for different users. In some ways this applied before computer operators but now since the programmer doesn't actually touch the machine the rules can be enforced.
Similarly tapes or cards were now identified with particular users or groups of users. The fledgling start of file systems.
The only downside is from the programmers' point of view. They no longer have direct access to the machine. Of course the larger number of people who could now use the machine never had that access in the first place.
At the moment even if we can keep the computer continuously supplied with data, in other words there is always information attached to the computer in the form of paper tape, punched cards or magnetic tape, we still have a vastly under-used system. Why is this?
All input and output is very slow, even compared to the speed of machines in the early 60's. If a computer has only one program to work on at a time it is frequently stopped, waiting for the latest input or output operation to complete.
It obviously must wait for input, otherwise it doesn't know what to perform the calculations on. It is not quite so obvious that it must wait for output. However if a printer has only a fixed size buffer to hold characters before they are printed, then when the buffer is full, any other characters sent to the printer will be lost.
One thing we can do is to speed up the devices which provide and receive the data. In particular if we can load and store our data from fast devices, such as magnetic tape drives, rather than from slow devices such as paper tape and printers we are reducing this wait time.
How do we do this if the only way we can get data onto a magnetic tape is via a computer?
Buy a cheaper computer. If the cheap computer (or computers) can do all the slow work, leaving the big, expensive computer to retrieve and store data to and from tape drives and do the calculating then we might come out on top. This was known as off-lining.
The simple idea is to keep the big expensive computer working as hard as possible.
Another improvement has been signalled by collecting similar programs together to reduce the set up time between different jobs, e.g. leaving the compiler in memory whilst compiling several different programs.
If possible this leaving of a program in memory significantly speeds up processor usage.
As the cost of memory decreased, it became feasible to allocate some of it outside the currently running program to provide services which all programs could use. This lead to the immediate forerunner to modern operating systems, the "resident monitor system".
Somethings are common between all programs (between means in the gap between one program running and the next). Under the original system the memory had to be cleared, the next program had to be loaded, the data had to be attached to the computer. The computer had to be pointed at the correct starting point of the program.
Since these steps are easily automated the obvious thing to do was to do just that.
All we have to do is to have some programs which hang around in memory (or on disk) to handle these bits between user programs. Here we have a further progression in thinking of programs in two fundamentally different ways.
These programs became known as the "resident monitor system". Unfortunately the word "monitor" is used in several different ways in computing (including a completely different meaning in the field of operating systems).