§ — — Operating Systems
An operating system sits between you — and every app you run — and the raw hardware of a computer. Every time you open a program, save a file, or plug in a USB drive, the OS is the thing translating that action into something the hardware can actually execute. This module covers what an OS is and does, how operating systems evolved across decades of computing history, the different categories of OS depending on what kind of machine they're built for, and the internal components that make an OS work.
At its core, an operating system is the software that manages everything else on a computer — the hardware (CPU, memory, storage, input/output devices) and the other software running on top of it. It's the layer that turns a collection of electronic components into something a person can actually use.
Two things make this possible:
Without an OS, a computer is just inert hardware. None of the software you depend on — browsers, office apps, games — could run, because nothing would load them into memory, give them CPU time, or let them talk to the screen, keyboard, or storage.
An OS is constantly juggling multiple programs, deciding what runs when, and making sure everything gets a fair (and safe) share of the machine's resources. Its responsibilities break down roughly like this:
The OS keeps a running record of which parts of memory are in use and which are free. When a program starts, the OS finds it space; when the program ends — or pauses to wait on I/O — that space is reclaimed. In systems running several programs at once, the OS also decides the order in which processes get memory access and for how long.
A useful comparison here is primary memory (RAM) versus secondary storage:
| RAM (Primary Memory) | Secondary Storage | |
|---|---|---|
| Persistence | Temporary — cleared on power-off | Permanent |
| Typical capacity | Measured in MB–GB | Measured in GB–TB |
| Volatility | Volatile | Non-volatile |
| Speed | Fast | Slower |
| Role | Holds actively running programs and data | Long-term files, installed programs, the OS itself |
Deciding which process gets the CPU, when, and for how long is called process scheduling. This involves keeping track of each process's status, handing the CPU to a process when its turn comes, and reclaiming the CPU once that turn ends or the process finishes.
The OS talks to hardware devices through drivers — software written specifically for each device. For every connected device, the OS tracks its status, decides which process gets to use it and for how long, allocates it efficiently, and frees it once it's no longer needed.
Files live inside directories, which can themselves be nested inside other directories. The OS tracks where every file is, what it contains, who's allowed to access it, and its current status, while handling the allocation and release of storage space as files are created, edited, or deleted.
Because your data shares a machine with other processes — and sometimes other users — the OS enforces who's allowed to read, write, or delete what, typically through accounts, passwords, and permission systems, to prevent unauthorized access or tampering.
The OS keeps track of how long it takes between a request being made and the system responding, which helps surface slowdowns or bottlenecks.
On systems shared by multiple users — university labs, cloud servers — the OS records how much CPU time, memory, or storage each job or user consumes, which is useful for billing, auditing, or simply understanding usage patterns.
When something goes wrong, the OS captures the diagnostic information needed to track down the problem later — error messages, memory dumps, execution traces.
On systems with many users and many development tools (compilers, interpreters, assemblers), the OS manages how those tools are assigned and shared.
Everything above ultimately serves two overarching goals:
These two goals can pull in opposite directions, and different operating systems have historically leaned one way or the other. Windows has traditionally prioritized convenience — a smooth, approachable experience — even at some cost to efficiency. Unix-family systems, having grown up in multi-user, shared-machine environments, have traditionally leaned toward squeezing the most out of available hardware.
Before there were operating systems, there was barely "computing" as we'd recognize it. English mathematician Charles Babbage designed a mechanical computing device known as the Analytical Engine in the 1800s — slow and unreliable by modern standards, and never fully built in his lifetime, but often pointed to as the conceptual ancestor of the modern computer. From there, OS history is usually told in four generations, tracking alongside the hardware of each era.
The earliest electronic computers ran on vacuum tubes and had no operating system at all. Programming was done directly in machine language — sometimes by physically rewiring plugboards to configure the machine for a specific task. Because these machines were built for straightforward numeric calculations performed one at a time, there was no real need for an OS to coordinate multiple programs or users.
Transistors replaced vacuum tubes, making computers smaller, more reliable, and more powerful. This era saw some of the earliest operating-system-like software appear — General Motors built one of the first (commonly referred to as GMOS) for IBM mainframes, and the FORTRAN Monitor System emerged around the same time.
This generation is best known for batch processing: programs were written on paper, punched onto cards, and handed to an operator. Jobs with similar requirements were grouped into "batches" and run one after another with minimal human intervention — a single-stream batch processing system. High-level languages like FORTRAN and COBOL appeared toward the end of this era, and processing speed jumped from the millisecond range into microseconds.
Integrated circuits — many transistors on a single chip — defined this generation, pushing computers to be faster, smaller, and more reliable still.
The major OS breakthrough here was multiprogramming: keeping several programs in memory simultaneously and switching the CPU between them, so it's rarely sitting idle while one program waits on I/O. This was a huge efficiency gain.
This era also saw affordable minicomputers — DEC's PDP line being the most famous — bring computing power within reach of smaller organizations for the first time. And in 1969, the first version of UNIX appeared. Written in C, it was portable across different hardware in a way earlier systems weren't, which helped it spread quickly.
This is the generation most people recognize. Personal computers became affordable enough for individuals — not just institutions — to own. IBM partnered with Microsoft to put DOS, later MS-DOS, on its PCs, and it quickly dominated the early PC market, though it was entirely text-based.
The graphical user interface (GUI) — icons, windows, menus, a mouse — originated from research at Xerox PARC, was popularized commercially by Apple's Macintosh, and was later adopted by Microsoft for Windows. From the mid-1980s onward, network and distributed operating systems also became increasingly common as machines were connected together rather than operating in isolation.
Not every OS is built the same way — the right design depends heavily on what the machine is for.
There's no real-time interaction between user and computer. An operator collects jobs with similar requirements, groups them into "batches," and runs them sequentially without further input — payroll runs and bank statement generation are classic examples.
Also called a multitasking system. Each task gets a small, fixed slice of CPU time — a quantum — before control passes to the next task. Because these slices are so short, it feels like everything is running at once, even on a single CPU. Tasks can come from one user or be spread across many. Unix and Multics are classic examples.
Several independent computers — each with its own CPU and memory — are connected over a network and can communicate, share files, and access each other's resources. Because each machine can largely run on its own, these are described as loosely coupled systems. LOCUS is a classic example.
A server manages users, data, applications, and shared resources (files, printers, etc.) for a small private network of client machines. Because everyone on the network needs to be aware of everyone else's configuration for things to run smoothly, these are described as tightly coupled systems. Examples include Windows Server, and general-purpose systems like UNIX, Linux, or macOS configured to serve a network.
Built for systems where the gap between receiving an input and producing the right response — the response time — is critical. Air traffic control, networked multimedia, and industrial command-and-control systems are typical examples. RTOS come in two flavors:
| Hard Real-Time | Soft Real-Time | |
|---|---|---|
| Response time | Mandatory | Best-effort |
| Performance under peak load | Predictable | May degrade |
| What sets the pace | The environment | The computer itself |
| Safety implications | Often critical | Usually non-critical |
| Typical data file size | Small to medium | Large |
| Error recovery | Mostly automatic | May need user input |
| Data integrity window | Short-term | Long-term |
Built to run on devices with limited processing power, memory, and battery life — phones, PDAs, and similar gadgets. Palm OS, Symbian, and mobile builds of Linux or Windows are typical examples.
Beyond its responsibilities, an OS is made up of distinct internal components, each handling a specific slice of the system:
The user-facing layer — literally the "outer shell" wrapping the OS core — comes in two main styles:
Tracks which portions of RAM are allocated and which are free, allocates memory to processes that request it after verifying the request is valid, and reclaims that memory once it's no longer needed. It also protects memory so processes can't overwrite memory belonging to something else.
Handles process scheduling — deciding which process gets the CPU next — and keeps track of every process's status. It manages how processes share information, protects each process's resources from interference by others, and coordinates synchronization between processes. It operates at two levels: managing jobs as they enter the system, and managing the individual processes within those jobs.
Protects the system from unauthorized processes, applications, or users trying to access things they shouldn't.
Manages data that lives outside RAM — on disks or other persistent storage — that can be read, written, and manipulated as needed.
Controls how the OS interacts with peripherals like the mouse, monitor, and printers. When you save a file or print a document, this is the component instructing the right device driver to carry it out. It also handles allocating and freeing devices as processes need them.
Responsible for everything you do with files — creating, renaming, copying, moving, deleting — plus backup and recovery, along with allocating and freeing the storage space those files occupy.
For each item below, identify which generation of computing (First, Second, Third, or Fourth) it belongs to:
Free Sample
That was 1 of 3 reviewers with answer keys in Operating Systems. Unlock all of them for the semester.
Unlock all reviewers →ProReviewer — locked
Drills, code labs, and full solutions.
ProReviewer — locked
Drills, code labs, and full solutions.
Done with this module? Track it — your progress shows on the subject list.
You've finished this subject