Operating systems: what they are, how they work, and their main components

General architecture of a modern operating system How operating systems coordinate hardware, applications, processes, memory, and security.

An operating system is the software layer that turns processors, memory, storage devices, buses, and peripherals into a usable computing platform. It manages resources, enforces protection boundaries, coordinates running work, and provides abstractions so applications do not have to understand the electrical and protocol details of every device.

Calling it “the most important software” may sound dramatic, but the underlying idea is sound: without a layer that coordinates hardware and exposes consistent services, a general-purpose computer would be far harder to program and use. One qualification matters, though: not every device with a processor runs a full operating system. Many microcontrollers execute bare-metal firmware, while others use a small RTOS or a general-purpose OS.

Operating systems appear in PCs, servers, phones, routers, televisions, watches, cars, industrial controllers, medical devices, and countless embedded systems. The implementation varies enormously, but the underlying problems—running code, managing memory, controlling devices, organizing files, networking, and enforcing security—are remarkably consistent.

What problem does an operating system solve?

Suppose an application wants to open a file, send data over the network, or draw a window. The application should not have to program an NVMe controller directly, reimplement TCP/IP, or understand the register-level interface of the GPU.

Instead, the operating system provides abstractions: files instead of raw disk sectors, sockets instead of raw Ethernet frames, processes and threads instead of CPU cycles, virtual memory instead of physical addresses, and windows or graphics surfaces instead of device registers.

This separation improves portability, security, and software development. An application can ask to open a file while the operating system decides which filesystem, cache, driver, and physical storage device are involved.

User mode and kernel mode

Modern processors provide different privilege levels. General-purpose operating systems commonly simplify those levels into two broad execution domains: user mode and kernel mode.

Ordinary applications run with restricted privileges in user mode. The kernel and selected privileged components can execute instructions and access resources that normal applications must not touch directly.

Microsoft explains this model directly in its documentation on user mode and kernel mode. Windows gives user applications private virtual address spaces, while core operating-system components run with kernel privileges.

One important correction to older explanations: entering kernel mode for a system call is a privilege transition, but it does not necessarily mean the scheduler switched to another process. A privilege transition and a full context switch are related concepts, not synonyms.

System calls: the boundary between applications and the kernel

When a program needs a privileged operating-system service, it eventually uses a system call or an API that leads to one.

The Linux kernel documents many of these boundaries in its user-space API guide. On Unix-like systems, operations such as opening files, creating processes, mapping memory, and establishing communication ultimately depend on kernel services.

Applications usually do not invoke raw syscall numbers themselves. Libraries and frameworks prepare arguments, enter the kernel through the appropriate mechanism, and return a result to the application.

POSIX standardizes a large part of the interface offered by Unix-style systems. The current POSIX.1-2024 specification defines system interfaces, shell behavior, and common utilities to improve source-level application portability.

The kernel is not the entire operating system

The kernel is the privileged core that manages fundamental resources, but a usable operating system contains much more.

Depending on the platform, the system may include:

  • boot loaders and early-boot components;
  • the kernel;
  • drivers and loadable modules;
  • system libraries;
  • services and daemons;
  • an init system or service manager;
  • command shells;
  • graphics and audio frameworks;
  • administration utilities;
  • package-management or software-update systems;
  • CLI, TUI, and GUI interfaces;
  • basic applications bundled with the platform.

This is why Linux by itself is not a GNU/Linux distribution. Linux is the kernel. Debian, Ubuntu, Fedora, and other distributions combine that kernel with libraries, utilities, services, installers, package managers, and project-specific policies.

Processes and threads: representing running programs

An executable file stored on disk is just code and data. When it runs, the operating system creates a dynamic object: a process.

A process typically has a virtual address space, open resources, credentials, execution state, and one or more threads. Threads are execution units that can share memory and resources inside the same process.

The scheduler decides which thread receives CPU time and for how long. On multicore processors, multiple threads can truly execute at the same time. When runnable work exceeds the available execution resources, the operating system interleaves tasks to maintain concurrency.

Modern multitasking is therefore more than “making it look like everything runs at once.” Multicore systems provide real parallel execution in addition to time-sharing.

CPU scheduling

The scheduler balances processor time according to priorities, policies, affinity, latency goals, and workload.

An interactive desktop needs fast response to input. A server may care more about throughput. A real-time system may need bounded response times. No single scheduling policy is optimal for every environment.

The operating system also coordinates interrupts, timers, and hardware events that may require immediate attention.

Physical memory and virtual memory

RAM is finite physical hardware. Modern operating systems build a much richer abstraction on top of it: virtual memory.

Each process can see an apparently independent address space. The kernel and the processor’s memory-management unit translate virtual addresses into physical pages, mapped files, and other regions.

Virtual memory supports:

  • process isolation;
  • controlled memory sharing;
  • memory-mapped files;
  • read/write/execute protection;
  • paging and, when needed, secondary-storage backing.

Virtual memory does not simply mean “using disk as extra RAM.” Swap or paging files are only one possible mechanism. The core idea is a protected, managed address-space abstraction.

Files, directories, and filesystems

Operating systems turn raw storage blocks into more useful structures: files, directories, metadata, permissions, and links.

A single operating system may support many filesystems. Windows commonly uses NTFS and other formats. GNU/Linux supports ext4, XFS, Btrfs, and many others. macOS uses APFS. FreeBSD provides strong integration with UFS and OpenZFS.

The kernel coordinates caching, permissions, mounts, reads, writes, and concurrent access so applications do not need to implement a filesystem driver every time they open a file.

Drivers: reaching the hardware

Hardware drivers implement communication between the operating system and devices. Some run in kernel mode; other architectures move part of the logic into user space.

A driver is not the same thing as firmware running inside the device. Our hardware drivers guide covers that boundary in more detail.

The abstraction lets applications work through higher-level APIs while the driver handles registers, DMA, interrupts, queues, and device-specific protocols.

Input/output and storage

An operating system coordinates I/O paths with wildly different latency and throughput characteristics: CPU, RAM, SSDs, network links, keyboards, displays, and USB devices.

It uses queues, buffers, caches, interrupts, DMA, and asynchronous operations to keep those devices working efficiently. A substantial part of real-world operating-system performance depends on how effectively these I/O paths are coordinated.

Interprocess communication

Processes often need to cooperate. Operating systems therefore provide IPC mechanisms such as pipes, local sockets, shared memory, message queues, signals, events, and synchronization primitives.

The challenge is to enable communication without destroying isolation. Many modern system services are deliberately split into separate processes that communicate through IPC rather than sharing one large address space.

Networking

The network stack is one of the core services of a modern OS. It manages interfaces, addresses, routes, sockets, protocols, and filtering policies.

An application can open a TCP or UDP socket without implementing Ethernet, Wi-Fi, ARP, IPv4/IPv6, or the details of a particular network adapter. The operating system and drivers handle those layers.

Users, permissions, and security

A modern operating system does more than distribute resources. It establishes trust boundaries.

Common mechanisms include:

  • users, groups, and credentials;
  • permissions and access-control lists;
  • user/kernel separation;
  • process isolation;
  • code and driver signing;
  • Secure Boot;
  • disk encryption;
  • sandboxing;
  • mandatory access control;
  • logging and auditing;
  • memory protections and exploit mitigations.

Modern platforms increasingly combine software and hardware to reinforce that chain. Apple’s Platform Security documentation, for example, describes secure boot, operating-system integrity, and protections backed by Apple-designed silicon.

Boot: from firmware to user space

Before the desktop appears, a complex chain has already run:

  1. UEFI or BIOS firmware initializes the machine;
  2. a boot target and boot loader are selected and, when supported, verified;
  3. the boot loader loads the kernel and early components;
  4. the kernel configures memory, interrupts, CPUs, and devices;
  5. the root filesystem becomes available;
  6. the first user-space process or service manager starts;
  7. system services are launched;
  8. the user session and its chosen presentation environment become available.

The exact path differs by platform. GNU/Linux may use GRUB, systemd-boot, or other boot loaders. Windows uses Windows Boot Manager. Apple devices implement a hardware-linked chain of trust.

CLI, TUI, and GUI do not define the operating system

The same operating system can expose several presentation modes.

CLI is a command-line interface. TUI is an interactive text interface inside a terminal. GUI provides windows, icons, controls, and other graphical elements.

These interfaces sit on top of the operating system’s services. A Linux server remains the same operating system without a graphical desktop. Windows likewise combines graphical administration with PowerShell, Command Prompt, APIs, and remote-management interfaces.

Kernel architecture: useful categories, not perfect boxes

Textbooks commonly describe monolithic kernels, microkernels, hybrid kernels, and exokernels. These categories are useful for understanding design tradeoffs, but real systems often mix ideas and evolve over time.

Modular monolithic kernels

Most core services execute in privileged kernel space. Linux is the best-known modern example, but “monolithic” does not mean one static, unstructured binary. Linux supports loadable modules and contains highly modular internal subsystems.

Microkernels

A microkernel tries to keep the privileged core relatively small, commonly limiting it to low-level scheduling, memory-management primitives, and IPC while moving more services into separate processes.

QNX and MINIX 3 are well-known examples. The model can improve isolation and service separation, although it introduces other tradeoffs, including more communication between components.

Hybrid designs

The term is commonly used in operating-systems literature for designs that adopt microkernel ideas while keeping more services in privileged mode for performance or compatibility. Windows NT and Apple’s XNU are often discussed in this category, although each architecture is more nuanced than the label suggests.

Exokernels and research designs

Exokernel research explored extremely small privileged kernels that protect and multiplex resources while moving higher-level policies into user-space libraries. The model has been influential academically even though it is not the dominant commercial design today.

“Layered architecture” and processor privilege rings are not mutually exclusive kernel categories. A monolithic or hybrid kernel can still organize internal subsystems in layers and use hardware privilege levels.

Windows, GNU/Linux, BSD, and macOS are packaged differently

Microsoft Windows

Modern Windows belongs to the Windows NT family. It combines kernel-mode components, the Executive, drivers, services, system libraries, and multiple APIs. Continue with our introduction to Microsoft Windows.

GNU/Linux

GNU/Linux systems combine the Linux kernel with distribution-specific libraries, utilities, services, installers, package managers, and policies. Debian, Ubuntu, Fedora, Arch, and others share many common projects while differing substantially in packaging, release cadence, defaults, and support models. See our introduction to GNU/Linux.

BSD

FreeBSD, OpenBSD, and NetBSD are complete operating-system projects rather than “distributions of a BSD kernel” in the same sense as GNU/Linux distributions.

The FreeBSD Handbook documents kernel, networking, security, storage, jails, and administration as parts of an integrated base system.

macOS

macOS is built on Darwin and the XNU kernel, combining Mach, BSD, and Apple-specific components. Above that base sit proprietary frameworks, services, and the macOS graphical environment.

Android is not simply “Linux with a mobile interface”

Android uses the Linux kernel, but its platform architecture differs substantially from a conventional GNU/Linux desktop distribution.

The Android Open Source Project documents a stack consisting of the kernel, hardware abstraction layer, native libraries and daemons, Android Runtime (ART), system services, the application framework, and apps.

This architecture helps separate generic platform components from device-vendor implementations.

iOS, iPadOS, watchOS, tvOS, and visionOS

Apple’s operating systems share many technologies and are deeply integrated with Apple-designed hardware. Sandboxing, code signing, Secure Boot, and data-protection mechanisms are part of the platform architecture rather than optional add-ons.

Apple Platform Security documents how hardware security, system security, application security, and data protection work together across Apple’s platforms.

General-purpose, embedded, and real-time operating systems

Not every operating system is designed to run a web browser, office suite, and dozens of user applications.

An embedded operating system may be optimized for one class of device, very limited memory, or low power consumption.

An RTOS emphasizes predictable timing. “Real time” does not simply mean “very fast”; it means certain responses must occur within defined timing bounds.

FreeRTOS describes RTOSes as small, deterministic systems commonly used in embedded devices, automotive ECUs, medical equipment, and other environments where timing constraints matter.

Distributed systems, clusters, and cloud computing

A distributed system coordinates resources and computation across multiple machines. But not every cluster is a “distributed operating system.” Kubernetes, for example, orchestrates workloads across nodes while each node still runs its own operating system.

Operating systems provide the primitives—processes, networking, isolation, storage—on top of which higher-level distributed and cloud platforms are built.

Virtualization and containers

Virtualization introduces another layer. A hypervisor can present virtual CPUs, memory, disks, and devices to a guest operating system, which then behaves as though it controls a complete machine.

Containers work differently. They normally share the host kernel and isolate processes using operating-system mechanisms rather than booting a separate guest kernel.

Our virtualization guide goes deeper into virtual machines, hypervisors, containers, and isolation.

What does a modern operating system actually manage?

Its responsibilities can be grouped into a few major areas:

  • boot and system initialization;
  • CPU scheduling, processes, and threads;
  • physical and virtual memory;
  • I/O and device drivers;
  • files, directories, and storage;
  • networking and communications;
  • IPC and synchronization;
  • users, permissions, and security;
  • services and background processes;
  • logging, auditing, and diagnostics;
  • power management;
  • updates and maintenance;
  • interfaces for applications and users.

The operating system matters because it coordinates all of those responsibilities as one coherent, protected platform.

The operating system as an abstraction platform

From a developer’s perspective, one of the operating system’s greatest contributions is allowing software to focus on user problems instead of directly controlling every device.

Developers work with files, sockets, processes, windows, memory, and APIs. The operating system translates those abstractions into physical memory mappings, storage queues, network packets, GPU commands, and device operations.

That contract between applications, the operating system, and hardware is one of the foundations that allows the modern software ecosystem to scale without every application reinventing the computer.

Official sources and documentation

Skip to content