4.6.1.4 - Operating-system responsibilities

Hiding hardware complexity

An application that saves a file should not have to know the electrical signals or physical layout of every drive that might be attached to the computer.

The operating system provides an abstraction: a simpler interface that hides the details needed to control hardware. An application requests a service such as reading a named file. The OS handles file-system operations and works with an appropriate device driver, software that provides device-specific control. The same broad request can therefore be supported on different suitable hardware through different drivers.

A user can choose Print in an application instead of sending a printer's low-level commands. The OS and print software arrange the job, while a driver translates device-specific operations. Hiding detail does not mean the hardware disappears or the OS can use any device without support; a compatible interface and driver are still needed.

An OS also offers a user interface, for example a graphical interface with windows and menus or a command-line interface accepting typed commands. These let people request operations without manipulating processor instructions directly. The user interface is one OS facility, not its entire role: resource management continues even when the user does not interact with a window.

Sharing processor time between processes

Several applications can be active even when there are fewer processor cores than tasks that want to execute.

A process is a program in execution, with its current state and resources. The OS manages competing processes and decides which ready process receives processor time. A scheduler selects work to run. On a single core, rapidly switching between processes gives the impression of simultaneous activity; only one process's instruction stream runs on that core at a particular instant. Several cores can execute different work in parallel.

When a process is switched out, the OS preserves the state needed to resume it, such as register values and its position in the instruction sequence. It later restores the selected process's state. This context switch lets a document editor continue where it stopped rather than start again. Switching has an overhead, so the purpose is a responsive and fair use of resources, not unlimited processing capacity.

A process waiting for a file read need not occupy the processor while the device works. It can be blocked, leaving a ready process to run. Once the operation completes, an interrupt can notify the system and the waiting process can become ready again. Ready does not mean it executes immediately: the scheduler still chooses among competing ready processes.

For example, a music player needs regular processing to avoid gaps while a large document exports. The OS can allocate time to both, guided by its scheduling policy. It cannot make an overloaded system infinitely fast, but it prevents one ordinary process from assuming it owns every processor resource.

Managing memory, files and input/output

Sharing the processor is only useful if each running process also has controlled access to the memory and devices it needs.

The OS tracks available main memory, allocates memory to processes and reclaims it when no longer needed. It protects processes' memory so one ordinary process cannot simply overwrite another's working data. If virtual memory is used, the OS maps the memory addresses presented to a process onto physical storage and may transfer pages between RAM and backing storage. Backing storage is much slower than RAM, so heavy transfers can reduce responsiveness; virtual memory does not physically enlarge RAM.

The OS manages backing-store files through a file system: names and directories, locations, available space and access permissions. Saving a file and allocating a region of RAM are related resource operations, but a stored file is not the same as a process's temporary working memory.

For input/output, the OS coordinates access to devices. If two processes want to print, jobs can be queued rather than their bytes being mixed into one unreadable output. Spooling stores pending output, typically on backing storage, so an application can hand over its print job before the printer finishes. A buffer temporarily holds data to accommodate different transfer rates, such as incoming device data waiting to be processed.

Devices can signal events using interrupts. For example, a storage controller reports that a transfer has completed, allowing the OS to respond and update the waiting process. The details of processor interrupt handling belong to computer architecture; here the important role is coordinating I/O and allocating resources among processes.

Suppose a video editor and a browser are open while two files print. The OS allocates their memory, selects ready processes for processor time and coordinates the printer queue and device completion events. These responsibilities form a connected resource-management system, rather than three isolated definitions.