Hard to define precisely, because operating systems arose historically as people needed to solve problems associated with using computers.

Much of operating system history driven by relative cost factors of hardware and people. Hardware started out fantastically expensive relative to people and the relative cost has been decreasing ever since. Relative costs drive the goals of the operating system.

• In the beginning: Expensive Hardware, Cheap People Goal: maximize hardware utilization.
• Now: Cheap Hardware, Expensive People Goal: make it easy for people to use computer.

In the early days of computer use, computers were huge machines that are expensive to buy, run and maintain. Computer used in single user, interactive mode. Programmers interact with the machine at a very low level - flick console switches, dump cards into card reader, etc. The interface is basically the raw hardware.

• Problem: Code to manipulate external I/O devices. Is very complex, and is a major source of programming difficulty.
• Solution: Build a subroutine library (device drivers) to manage the interaction with the I/O devices. The library is loaded into the top of memory and stays there. This is the first example of something that would grow into an operating system.

Because the machine is so expensive, it is important to keep it busy.

• Problem: computer idles while programmer sets things up. Poor utilization of huge investment.
• Solution: Hire a specialized person to do setup. Faster than programmer, but still a lot slower than the machine.
• Solution: Build a batch monitor. Store jobs on a disk (spooling), have computer read them in one at a time and execute them. Big change in computer usage: debugging now done offline from print outs and memory dumps. No more instant feedback.
• Problem: At any given time, job is actively using either the CPU or an I/O device, and the rest of the machine is idle and therefore unutilized.
• Solution: Allow the job to overlap computation and I/O. Buffering and interrupt handling added to subroutine library.
• Problem: one job can’t keep both CPU and I/O devices busy. (Have compute-bound jobs that tend to use only the CPU and I/O-bound jobs that tend to use only the I/O devices.) Get poor utilization either of CPU or I/O devices.
• Solution: multiprogramming - several jobs share system. Dynamically switch from one job to another when the running job does I/O. Big issue: protection. Don’t want one job to affect the results of another. Memory protection and relocation added to hardware, OS must manage new hardware functionality. OS starts to become a significant software system. OS also starts to take up significant resources on its own.