Operating systems

An operating system organizes a computer’s work: running programs, allocating memory, storing files, and handling devices. Its history reflects changing needs, from expensive shared machines to personal computers, network servers, and phones. Modern systems preserve many earlier ideas while implementing them differently.

Follow the problems behind the family names

The deeper chapters connect a historical design problem to a decision you can still encounter today:

• Time-sharing and the invention of boundaries: several people need responsive computing without unrestricted access to one another’s work.
• Unix, portability, and open source: useful software should travel, but compatible interfaces do not guarantee identical code or maintainers.
• From personal PCs to Windows NT: stronger separation must coexist with applications written around earlier permission assumptions.
• Mobile sandboxes and the update promise: one person’s phone holds code from many publishers, so application separation and ongoing repairs matter together.

A family tree answers where ideas or code came from. It does not by itself tell you which application can read a file, whether an update has arrived, or when a permission change takes effect. The history below supplies context; the detailed chapters turn that context into practical questions about present systems.

Sharing made protection a design problem

Time-sharing let several users work with one computer. Scheduling decided whose work ran; protection limited whose work could affect another’s resources. Multics explored structured protection and multiuser operation in the 1960s. These ideas influenced later designs, but a historical influence is not the same as inherited code.

A Process gives a program an execution context. Its resources may include memory mappings, open files, and credentials. Processes can deliberately share memory and other objects. Separation therefore needs rules for both private resources and permitted sharing.

Unix ideas spread through several paths

Unix began at Bell Labs in 1969 and was substantially rewritten in C during the early 1970s. Its processes, file interfaces, pipes, and portable programming approach influenced many systems. BSD and System V became important branches.

Linux, begun in 1991, is an independently developed Unix-like kernel rather than a direct continuation of the original Unix codebase. A Linux distribution combines that kernel with libraries, utilities, and other software. Similar interfaces do not mean every system has the same security model or implementation.

Windows and Mac histories include architectural changes

CP/M and DOS helped shape personal-computer software conventions. Early Windows and the Windows 9x family relied on DOS-related foundations. Windows NT, first released in 1993, was a distinct architecture developed alongside that line, not simply a graphical shell gradually renamed.

Modern Windows inherits the NT family and uses mechanisms including access tokens, security identifiers, and access-control lists. These interact; “administrator” is not a complete description of every process’s authority.

Classic Mac OS and Mac OS X also represent an architectural transition. Mac OS X, released in 2001, used Darwin foundations including XNU, Mach-derived components, and BSD elements. macOS and Linux share familiar interfaces without using the same kernel.

Requests cross a defined interface

A System call lets a program request an operation from the Kernel. Some requests require checking credentials and object permissions; others concern operations such as obtaining information about the process. Higher-level libraries may perform work without entering the kernel on every call.

Kernel software and drivers can have extensive authority, but the precise boundary depends on the system. Hypervisors add another layer. Administrative control inside a guest does not automatically grant authority over its host or other guests.

Mobile isolation builds on these ideas

Android uses the Linux kernel with additional application and platform controls. Apple’s mobile systems share Darwin-related foundations with a different application platform. Sandboxing, signing, permissions, and managed interfaces constrain how applications interact.

Isolation is implemented through mechanisms and policy, not guaranteed by a product label. A permitted action can still be harmful, and defects or excessive grants can weaken separation. Compare the actual credentials, accessible resources, and enforcement points. The Linux and Windows lessons make that comparison concrete.