Operating System Evolution

Computer software is roughly divided into two main categories - application software and operating system software. Applications are programs used by people to carry out various tasks, such as writing a letter, creating a financial spreadsheet, or querying a customer database. Operating systems, on the other hand, manage the computer system on which these applications run. Without an operating system, it would be impossible to run any of the application software we use every day, or even to boot up the computer.

The early computers of the late 1940s had no operating system. Human operators scheduled jobs for execution and supervised the use of the computer’s resources. Because these early computers were very expensive, the main purpose of an operating system in these early days was to make the hardware as efficient as possible. Now, computer hardware is relatively cheap by comparison with the cost of the personnel required to operate it, so the purpose of the operating system has evolved to encompass the task of making the user as efficient as possible.

An operating system functions in much the same way as other software. It is a collection of programs that are loaded into memory and executed by the processor. When the computer is powered down it exists only as a collection of files on a disk drive. The main difference is that, once it is running, it has a large measure of control over both the processor itself and other system resources. In fact, the operating system only relinquishes control to allow other programs to execute. An application program is frequently given control of the processors for short periods of time in order to carry out its allotted task, but control always reverts to the operating system, which can then either use the processor itself or allocate it to another program.

The operating system, then, controls the operation of the computer. This includes determining which programs may use the processor at any given time, managing system resources such as working memory and secondary storage, and controlling access to input and output devices. In addition to controlling the system itself, the operating must provide an interface between the system and the user which allows the user to interact with the system in an optimal manner.

Increasingly these days, the operating system provides sophisticated networking functionality, and is expected to be compatible with a growing range of communication devices and other peripherals. In recent years, the implementation of an application programming interface (API) has been a feature of most operating systems, making the process of writing application programs for those operating systems much easier, and creating a standardised application environment.


Batch systems

In the early days of computing, scheduling computing tasks was a problem because time on the computer had to be booked in advance, typically in half-hour blocks or multiples thereof. If the operator encountered problems and the program did not successfully run to completion in the allotted time, a new time slot had to be booked and the program would have to be run again from the beginning. Each program had to be loaded into memory and compiled before it could run, which could involve a significant amount of setup time. Gradually, the software tools that would automate some of the setup and troubleshooting tasks were evolved, including linkers, loaders, compilers, assemblers and debuggers.

In order to improve the utilisation of computing resources, the concept of a batch operating system was devised. Such an operating system was developed in the mid-1950s by General Motors for use on IBM mainframes, and was known as the monitor. The operator now batched individual jobs together sequentially and placed them on an input device. The monitor would load and run one job at a time. On completion, each job returned control to the monitor, which would then load the next job.

Control would also return to the monitor if an error was encountered. The results of each job were sent to an output device such as a printer. Because the monitor controlled the sequence of events, part of the program (the resident monitor) had to reside in memory. Other parts of the program were loaded as subroutines at the beginning of any job that required them.

The monitor created some additional system overhead because it occupied a portion of memory and used the resources of the processor. Despite this, it improved utilisation of computing resources, enabling jobs to be executed quickly, with little or no idle time and a greatly reduced setup time. One issue that came to the fore at this time was the need to protect the memory occupied by the monitor program from a running program. In addition, the execution of certain machine level instructions, such as I/O instructions, was deemed to be the preserve of the monitor. These "privileged" instructions could not be executed directly by a program. To perform an input or output task, for example, the program would have to send a request to the monitor asking it to carry out the required actions.


The monitor program was an early form of operating system

The monitor program was an early form of operating system



Multiprogramming and time sharing

Even with batch operating systems, the processor was often idle because I/0 devices were slow by comparison with the processor. The computer spent much of its time waiting for I/O operations to finish. At that time, the memory held the operating system and the currently executing user program. If it were possible for memory to hold a second program, then the processor could be used by the second program while the first program was waiting for I/O operations to finish, making more effective use of the processor. If enough memory was available, a number of programs could be accommodated allowing the processor to be utilised continuously. This multiprogramming or multitasking is a characteristic of modern operating systems.

In a multiprogramming system, a running application can request an I/O operation by sending a system call to the operating system. The operating system will issue the necessary commands to the I/O device controller, and then initiate or continue the execution of another program. Multiprogramming systems rely on the generation of interrupts, which are basically signals sent by a hardware device to inform the processor that it has completed a task (or has encountered an error). On receipt of an interrupt, the processor passes control back to the operating system, which executes the necessary interrupt-handling routine. Multiprogramming operating systems require a high degree of sophistication, since they are responsible for managing memory usage for, and scheduling the execution of, multiple programs.

In order for the processor's time to be divided fairly between the programs competing for its use, the operating system interleaves the execution of each program in short time slots. This process is known as time-sharing, and it prevents one program from hogging the processor to the detriment of other programs. In a multiprogramming system there is inevitably the possibility that, due to a programming error for example, one program’s code will attempt to access or overwrite memory that is being used by another program. In addition to its other duties, therefore, the operating system must also ensure that programs do not interfere with each other (for example by modifying each other’s program code or data).


Personal computer systems

In the early days of commercial computing, the cost of both computer hardware and software greatly outweighed the cost of employing the data entry personnel who operated the computers. Programmers therefore wrote programs with a view to creating the most efficient code, and little consideration was given to the convenience of the operator, or to the suitability of the human-computer interface. Operators had therefore to learn a number of obscure commands in order to be able to carry out their data entry duties. Despite a steady decline in the cost of hardware and software, this situation persisted, even though the economic factors that had created it no longer applied.

As early as the 1960s and 1970s, researchers were working on the idea of a personal computer. One in particular, Alan Kay, was working for IBM when he first began to consider how computing would change once personal computers became more affordable. Kay formulated the idea of a graphical user interface (or GUI). The interface he envisaged had all of the features we can now see in a modern desktop environment, including a separate window for each application, a menu-driven application environment, and many other features now in common use.

Kay left IBM to work at the Xerox Palo Alto Research Center (PARC), where he continued his research for another decade until it came to the attention of Steve Jobs of Apple Computers. Apple purchased the rights to the concept, and subsequently produced the Lisa, which was the first commercially available personal computer to incorporate a graphical user interface, complete with a mouse.

When Lisa failed to make an impression on the marketplace because it was too expensive, Apple developed the Macintosh, which was far cheaper and consequently more successful. For the first time, an operating system had been created that reflected the economic reality that the operator was now a far greater cost factor than the computer hardware or software. The computer was adapted to suit the operator rather than the other way round. Almost all operating systems now offer a sophisticated, event-driven, graphical desktop environment designed primarily for ease of use.


Parallel, real time and distributed Systems

Parallel operating systems are designed to make efficient use of computers with multiple processors, and many operating systems currently on the market can take full advantage of multiple processors if present, providing the application programs they are running have been written using a programming language that supports multi-threading. The general idea is that different threads of the program can be executed simultaneously, speeding up the execution of the program as a whole. Programs written for single-processor computers can often run on a multi-processor system, but can only execute on one processor at a time.

A real-time operating system is one in which processing activity is triggered by one or more random external events, each of which will initiate the execution of a predetermined set of procedures that must be completed within rigid time constraints. Real-time systems are often dedicated to highly specialised applications, such as flying an aircraft or controlling an industrial process, where an input event must result in an immediate response. In the early 1980s, real-time systems were used almost exclusively for applications such as process control. A process control system typically accepts analogue or digital sensor input, analyses the data, and takes the appropriate action.

A distributed system is one in which various user resources reside in separate computer systems connected by a network. The computer systems involved may have diverse hardware and software platforms, but the user is presented with a uniform computing environment thanks to a distributed system architecture that provides a standard communications interface. This intermediate layer of software hides the complexity created by the intercommunication of such diverse technologies.

Microsoft's common object model (COM) was an architecture developed to handle inter-process communication between applications running on the same computer. Their distributed common object model (DCOM) architecture is an extension of COM that enables inter-process communication to take place between applications running on different computers on a network.