GENERATION 0 — NO OPERATING SYSTEM (1940s–early 1950s) · the programmer WAS the operator: load the program by switches or plugboard, run it, read the lights · one user at a time, exclusive use of the machine · SETUP TIME dominated: mounting tapes, loading the compiler, loading the program, could take longer than the run PROBLEM: the CPU sat idle between jobs. GENERATION 1 — BATCH SYSTEMS (mid 1950s) · a human operator collects jobs onto a tape, the machine runs them one after another without intervention · the RESIDENT MONITOR is the first thing resembling an OS: a small program that stays in memory and loads the next job · job control language (JCL) describes what to run PROBLEM: still one job at a time, so the CPU idles during every I/O operation. GENERATION 2 — MULTIPROGRAMMED BATCH (1960s) · several jobs held in memory at once · when the running job blocks on I/O, the CPU switches to another job · REQUIRES: memory protection (one job must not corrupt another) and CPU scheduling This is the first true operating system in the modern sense. PROBLEM: no interactivity — you still submit and wait. GENERATION 3 — TIME SHARING (1960s–70s) · the CPU is switched between users so rapidly that each believes they have the machine · needs a TIMER INTERRUPT to force switches, so no process can monopolise the CPU · brings the terminal, the interactive shell, file systems with per-user permissions · CTSS, Multics, then UNIX (1969) PROBLEM: response time degrades as users are added. GENERATION 4 — PERSONAL COMPUTERS (1980s) · one user, one machine — so the early PC OSes DROPPED protection and multitasking as unnecessary · MS-DOS had no memory protection at all; any program could overwrite the OS · the GUI (Xerox PARC → Macintosh → Windows) becomes the interface Note the regression: DOS was in some ways less advanced than 1960s mainframe OSes. Capability returned in the 1990s (Windows NT, Linux) once PCs were powerful enough. GENERATION 5 — DISTRIBUTED, MOBILE, VIRTUALISED (1990s–now) · networked systems: NFS, client-server, then the web · REAL-TIME systems for control applications · MOBILE: iOS/Android, where battery and background limits are first-class concerns · VIRTUALISATION: a hypervisor runs many OSes on one machine · CONTAINERS: many isolated userlands on one kernel · CLOUD/SERVERLESS: the machine becomes invisible THE RECURRING PATTERN: each generation added a layer of INDIRECTION to solve a resource problem — batch → indirection between user and machine multiprogramming → indirection between job and CPU virtual memory → indirection between program and RAM virtualisation → indirection between OS and hardware containers → indirection between app and OS

Every generation optimised a different measure, and the shift in what was being measured is the clearest way to see why the designs changed. BATCH maximise THROUGHPUT (jobs per hour) nobody is waiting, so response time is irrelevant MULTIPROGRAMMING maximise CPU UTILISATION keep the expensive CPU busy during I/O TIME SHARING minimise RESPONSE TIME a human is waiting at a terminal REAL TIME guarantee a DEADLINE being late is being wrong MOBILE minimise ENERGY per task the battery is the scarce resource CLOUD minimise COST per request hardware is rented by the second CPU UTILISATION WITH MULTIPROGRAMMING — the calculation that justified the whole generation. If a process spends fraction p of its time waiting for I/O, and n processes are in memory, then the probability that ALL n are waiting simultaneously is pⁿ. So CPU utilisation = 1 − pⁿ With p = 0.8 (a typical I/O-bound job): n = 1 → 1 − 0.8 = 20% n = 2 → 1 − 0.64 = 36% n = 3 → 1 − 0.512 = 49% n = 4 → 1 − 0.410 = 59% n = 5 → 1 − 0.328 = 67% n = 10 → 1 − 0.107 = 89% Going from 1 to 4 processes triples utilisation. That is the entire economic argument for multiprogramming, and on a machine costing millions of dollars it was decisive. DIMINISHING RETURNS: from n=5 to n=10 gains only 22 more points, and each extra process costs memory. The model also assumes independence, which is optimistic — real processes contend for the same disk.

Two complementary definitions, and exams ask for both. AS A RESOURCE MANAGER the OS arbitrates access to hardware among competing processes: CPU time, memory, disk, network, devices. It decides who gets what, when, and for how long. AS AN EXTENDED MACHINE (abstraction provider) the OS hides ugly hardware behind clean abstractions: raw disk sectors → files and directories physical RAM → virtual address spaces one CPU → many processes a network card → sockets interrupt handlers → signals and events Nobody writes disk-sector arithmetic to save a document. The abstraction IS the product. WHERE THE OS SITS: ┌────────────────────────────────┐ │ applications (user mode) │ ├────────────────────────────────┤ │ system call interface │ ← the boundary ├────────────────────────────────┤ │ operating system (kernel mode)│ ├────────────────────────────────┤ │ hardware │ └────────────────────────────────┘ DUAL-MODE OPERATION is what makes protection possible: USER MODE restricted; privileged instructions trap KERNEL MODE full access to hardware A mode bit in the CPU records which one is active. A system call switches to kernel mode through a controlled entry point, so an application can request a privileged operation without being able to perform one directly. Without dual mode there is no protection — which is exactly why MS-DOS had none, and why any DOS program could crash the whole machine.