01 Introduction

The operating systems we use today did not appear fully formed. They are the product of more than seventy years of evolution, driven by changes in hardware cost, hardware capability, and the kinds of problems users wanted to solve. Understanding that history is not merely cultural: each generation solved a specific problem, and the solutions of earlier generations are still present in the systems you use.

The story is roughly this: the first computers had no operating system at all. Users physically wired programs into the machine. Then came batch processing to reduce idle time, time-sharing to give interactive access, personal computing to put a machine on every desk, networking to connect those machines, and finally distributed, mobile, and cloud systems. Each stage was enabled by a technological advance and each raised new design questions.

02 Learning objectives

This lesson contributes to U1.2 and course learning outcome CLO1.

03 Required reading

• Operating System Concepts — Chapter 1, Section 1.2, History of Operating Systems.
• OSTEP — Chapter 2, Introduction to Operating Systems (the discussion of virtualization sets up the historical framing).

04 Core content

4.1 Before operating systems (1940s–early 1950s)

The earliest electronic computers — ENIAC, EDVAC, and their contemporaries — had no operating system. A single program had exclusive use of the machine. The programmer prepared their work on plugboards or punched cards, loaded it into memory, started it manually, and watched the result. When the program finished, the next user took over.

Two features dominated this era: the machines were enormously expensive, and they were also enormously slow to set up. A significant fraction of the machine's available time was spent waiting for the human operator.

4.2 Batch processing (mid 1950s–1960s)

Batch processing was the first attempt to reduce idle time. Instead of running one program at a time with manual intervention between jobs, the operator collected a batch of jobs on punched cards and fed them to a small program — the resident monitor — that loaded and executed each in turn. When one job finished, the monitor automatically loaded the next.

The batch monitor is the direct ancestor of the modern kernel. It was the first program that stayed resident in memory and controlled the machine, and it introduced three ideas still central to operating systems:

• Job sequencing — deciding which job runs next.
• Memory protection — keeping the monitor safe from buggy user jobs.
• Interrupt handling — reacting to asynchronous events, such as the completion of I/O.

4.3 Multiprogramming and time-sharing (1960s–1970s)

Two related ideas transformed the field. Multiprogramming keeps several jobs in memory at once so that when one blocks on I/O, the CPU can switch to another. Time-sharing extends this by giving each interactive user a small slice of CPU time in rapid rotation, so each user has the illusion of a private machine.

Time-sharing is the conceptual foundation of essentially every general-purpose operating system in use today. It required several technologies that had to mature together:

• A hardware timer to interrupt a running program periodically.
• Memory protection to keep one user's program out of another's space.
• Reliable interrupt handling to make rapid switching feasible.

The landmark systems of this era — CTSS at MIT, Multics, and later UNIX at Bell Labs — established the model that the rest of the course builds on.

4.4 Personal computing and graphical interfaces (1970s–1990s)

The microprocessor changed the economics of computing completely. A machine that once cost millions now cost thousands, then hundreds. Instead of a large central machine shared by many users, every user could have a machine of their own.

Personal-computer operating systems — CP/M, MS-DOS, early versions of Mac OS and Windows — prioritised different goals than their predecessors. They emphasised responsiveness to a single user, friendly graphical interfaces, and support for a growing range of peripherals. Multi-user concerns were secondary.

UNIX, meanwhile, evolved in parallel and became the basis for high-performance workstations and — ultimately — for Linux. Its design philosophy of small composable tools, a uniform file interface, and a portable implementation proved remarkably durable.

4.5 Networking and distributed systems (1980s–2000s)

Once machines were connected, the operating system's scope expanded. It now had to provide protocols, sockets, remote file systems, and name resolution. The line between "the local machine" and "the network" began to blur.

Three consequences stand out:

• Network transparency. UNIX's socket API made network communication look almost like ordinary file I/O — the same read() and write() calls, plus a few new ones.
• Distributed file systems. NFS, AFS, and later SMB allowed files to live on remote servers while appearing local.
• Client–server architecture. Applications split across machines: a client on the user's desktop, a server on a shared host.

4.6 Mobile, cloud, and virtualization (2000s–present)

Three trends have shaped the most recent era. They are not independent.

Mobile operating systems

iOS and Android prioritise energy efficiency, touch interaction, strict application sandboxing, and a managed permission model. They are descendants of UNIX, but their design constraints are radically different from a server's.

Virtualization

A hypervisor runs multiple guest operating systems on a single physical host. This decouples the software from the hardware it runs on and makes efficient use of large servers.

Cloud computing

Compute, storage, and networking are provided as on-demand services. The "operating system" of a cloud data centre is not one kernel but a distributed management layer — schedulers, orchestrators, and network controllers working together.

Containers

Linux namespaces and control groups make it possible to run isolated user-space environments on a shared kernel. Containers are lighter than virtual machines and have become the standard packaging unit for cloud-native applications.

4.7 Technological drivers

Each transition was enabled by a specific hardware advance. The pattern is worth noting because it repeats.

4.8 Future trends

Several directions are actively shaping the next generation of operating systems. None is settled, but each is worth watching.

• Serverless and function-as-a-service platforms. The unit of deployment shrinks from a container to a function invocation. The operating system's role is increasingly mediated by a runtime scheduler running on behalf of the platform.
• Heterogeneous compute. GPUs, TPUs, and other accelerators are no longer optional. Managing them uniformly is an open problem.
• Persistent memory. Byte-addressable non-volatile memory blurs the line between memory and storage, forcing new file-system and memory-management designs.
• Confidential computing. Hardware enclaves and encrypted memory raise new questions about what the OS can and should see.
• Unikernels and library operating systems. Rather than a general-purpose kernel, a single-purpose application is compiled together with only the OS code it needs.

05 Worked example

Consider a small data-processing centre in 1965 and the same organisation in 2024. Compare what changed and why.

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• The earliest computers had no operating system; programs were loaded and started manually.
• Batch processing introduced the resident monitor to reduce idle time — the direct ancestor of the modern kernel.
• Multiprogramming and time-sharing introduced preemption, interactive access, and the abstractions still central to general-purpose operating systems.
• Personal computing and graphical interfaces prioritised a single user's experience and drove a wave of consumer operating systems.
• Networking expanded the OS's scope to include protocols, sockets, and remote file systems.
• Mobile, virtualization, and cloud systems represent the current era, each shaped by a specific hardware advance.
• The recurring pattern: a hardware advance creates a new capability; a design decision exposes it safely to many users; that design becomes the next abstraction.

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, Chapter 1.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, Chapter 1.
• Ritchie, D. M., & Thompson, K. The UNIX Time-Sharing System. Communications of the ACM, 1974.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapter 2.