What an operating system does

A1.3.1 described the OS's role: managing and sharing the hardware, and hiding its complexity. This section looks at the specific jobs, the functions, that make that happen. Most of them revolve around one idea: the process.

A program on disk is just a file of instructions. When you run it, the OS loads it into memory and creates a process: the program in action. Run two copies of the same app and you have two processes. For each process the OS keeps a record of its process ID, its state, the values in its registers when it last ran, its priority, and the memory and files it is using.

A process can be split into threads: separate sequences of instructions that share the process's memory and can run at the same time on different cores. A word processor might use one thread to respond to typing, one to check spelling and one to save in the background.

Every process moves through a set of states. Most of the time most processes are not running at all: they are ready and waiting for a turn, or blocked waiting for something slow, like a file or a key press.

When a program starts, the OS finds space for its code and data and records which memory belongs to which process. While it runs, the program can ask for more memory and give it back. The OS makes sure each process stays inside its own area: memory protection. A program with a bug can then only damage itself, not other programs or the OS.

Modern systems use paging. A process's memory is cut into fixed-size pages (often 4 KiB), RAM is cut into frames of the same size, and a page table records which frame each page is really in. The process sees one neat, continuous block of memory; the OS and a hardware unit in the CPU (the memory management unit) translate its addresses on the fly. Because pages can live anywhere, a page that has not been used for a while can be moved out to disk to free RAM, and brought back when needed. That is how virtual memory works.

The file system turns a storage device, which is really just a long row of numbered blocks, into named files inside folders inside folders: a hierarchy. The OS keeps track of which blocks belong to each file and which are free, enforces naming rules (no two files with the same name in one folder), records who owns each file and who may read, change or run it, and provides the operations: create, open, read, write, rename, move, copy and delete. Examples are NTFS on Windows, APFS on macOS and ext4 on Linux. A file's extension (.docx, .jpg, .exe) tells the OS which application opens it.

The OS also maintains the disk. As files are created, grown and deleted, a file on a hard disk ends up in pieces scattered across the platter (fragmentation), and the head must jump between them. Defragmentation moves the pieces back together so the file reads in one sweep. SSDs are not defragmented: with no moving head, scattered blocks cost nothing to read, and the extra writes would only wear the flash out (A1.1.7).

Every printer, graphics card and network adapter is controlled differently. A device driver is the software that translates the OS's general commands into that device's particular signals, and passes its data and interrupts back. With plug and play, the OS recognises a new device as it is connected and installs its driver automatically.

Devices are far slower than the CPU, so the OS smooths the difference:

• Buffering: data is collected in an area of memory so it can be passed on in efficient chunks, as when a video streams a few seconds ahead of what you watch.
• Caching: data read from a device recently is kept in RAM, so the next request for it does not go back to the slow device at all, as when a file opens instantly the second time.
• Spooling: jobs for a slow device that can only do one at a time, such as a printer, are queued on disk, so the program that sent them can carry on immediately.

When a device fails or stops responding, the OS handles the error rather than letting it crash every program using the device: it can reset the device, reload its driver, or report the problem to the user.

The scheduler decides which ready process gets the CPU and for how long. It has its own section, A1.3.3.

• Authentication: proving who you are before you get in: something you know (a password), something you are (a fingerprint), or something you have (a security token that holds a key or shows a one-time code).
• Access control: user and group accounts with permissions on every file and folder (for example read, write and execute for the owner, the group and everyone else), so a guest cannot open your documents and an ordinary user cannot change system settings. Access control lists (ACLs) allow finer rules, naming exactly which users or groups may do what to each file.
• Encryption of whole disks (BitLocker, FileVault) and of network traffic, so stolen data cannot be read.
• Firewalls and anti-malware, built into or working closely with the OS. A firewall checks network traffic packet by packet against rules and blocks what is not allowed. Anti-malware looks for malware: viruses (which attach themselves to other files), worms (which copy themselves across a network on their own) and trojans (which pretend to be useful software). It recognises known malware by its signature and new malware by suspicious behaviour, such as a program quietly changing system files.
• Sandboxing: running an app with access only to what it needs. A phone app cannot read another app's data or use the camera until you allow it.
• Updates (patches) that close security holes as they are discovered.

Together these protect the three things security is about, often called the CIA triad: confidentiality (only the right people can read the data), integrity (it cannot be changed without permission) and availability (it is there when it is needed).

The OS records how much CPU time, memory, storage and network each process and user consumes, and logs events (logins, errors, failed access attempts) with times and process IDs. Administrators use this to find bottlenecks, set limits (quotas) so no one user hogs a shared system, spot suspicious activity, and in cloud services to bill customers for what they use. Monitoring is the live view (Task Manager, Activity Monitor: what is using the CPU right now); logging is the permanent record (Event Viewer, the files in /var/log: what happened at 3 a.m. last Tuesday).

• Graphical user interface: windows, icons, menus and a pointer, plus task switching, notifications, file browsing and accessibility features such as screen readers, magnifiers and high-contrast themes. (Many systems also offer a command-line interface for precise or automated control.)
• Virtualisation: a hypervisor runs several virtual machines on one physical computer, each believing it has its own hardware and its own OS. They share the hardware efficiently but are kept isolated, so a fault in one does not affect the others. A VM can be saved as a snapshot and restored if something goes wrong, and moved to another physical machine while it runs (live migration), so hardware can be repaired without stopping the service. This is what makes cloud computing (A1.1.9) possible.
• Networking: the OS contains the network stack. It splits outgoing data into packets and reassembles incoming ones, implements the protocols (TCP/IP, and on top of it HTTP for the web, SMTP for email), drives the network card through its driver, and configures the connection, usually getting an IP address automatically by DHCP. It protects the traffic with the firewall, encryption (TLS) and VPNs, and provides tools for testing it: ping (can I reach that computer?), ipconfig/ifconfig (what is my address?), netstat (what is connected?) and traceroute (which way do my packets go?). A2 covers networks in full.

With hundreds of processes running, most of them background processes (services that run with no window and no user watching, such as the update checker, the indexer that powers search, and the antivirus scanner), the OS has to make sure the system keeps doing the right thing and nothing is changed that should not be. It uses everything above together:

• Isolation: every process in its own protected memory space.
• Kernel mode and user mode: only the core of the OS can touch the hardware directly; applications must ask through system calls, so a misbehaving app cannot take over a device or another program's memory.
• Least privilege: each user and each background service gets only the permissions it needs.
• Integrity checks: checksums and hashes reveal whether system files or data have been corrupted or tampered with; file-system checks repair damage after a crash.
• Logging, updates and rollback: problems are recorded, security fixes are installed, and a failed update can be undone back to the last working state.