The OS Explained

September 10, 2026 • 9 min read

Table of contents

What the OS is for
Kernel mode and user mode: the two levels of trust
Kernel and user space: the two halves of the machine
Syscalls: the boundary you program against
What the OS manages
How the OS stays in control while barely running
The big picture

Part of the series:Operating Systems Explained

Everything you do on a computer runs through software you never see. You open a file or press play, and something quietly decides which program gets the processor, how much memory it can use, and whether it’s allowed to touch the disk. That invisible layer is the operating system¹, the manager of the machine’s physical resources. It is the software sitting on top of everything covered in the Computers Explained series.

This post is the panoramic view of that job: what the OS is for, why the machine has two levels of trust and two separate halves, how programs ask for help, the four core resources it manages, and how it stays in complete control of a machine it is barely running.

What the OS is for

An operating system does two things, and every feature it offers serves one of them.

The first is making the hardware usable. The disk knows nothing about files or folders; the processor knows nothing about documents or windows. A program should not have to know which disk sectors hold its data or how to make the controller read them. The OS takes care of that part: the program asks to open a file, read some bytes, or write them back, and the OS works out the machine steps. You ask for the result instead of the machinery.

The second is sharing the machine. There is one processor, one block of memory, one disk, but many programs that all want them at once. The OS decides who runs next, who gets how much memory, and what happens when two programs want the same thing. Sharing fairly between competing programs is the harder of the two jobs, and it is what most of this series is about.

Both jobs have standard names: the OS as an extended machine, the hardware hidden behind cleaner interfaces, and as a resource manager, the one doing the sharing. Same thing seen from two sides.

Kernel mode and user mode: the two levels of trust

Not all programs can be trusted equally, so the processor itself draws a line. Every modern processor runs in one of two modes²:

Kernel mode, also called supervisor mode: nothing is forbidden. The program can touch any memory, change any setting, and command any device.
User mode: restricted. The processor refuses instructions that would affect the machine as a whole, and refuses memory that does not belong to the program asking.

That rule lives in the hardware, not in the OS. No program, however buggy or malicious, can talk its way past it. A user program that reaches for something forbidden does not fail politely: the processor halts it on the spot, and whatever it was doing stops with it.

Kernel and user space: the two halves of the machine

Someone has to run in kernel mode, or nothing would get decided. That someone is the kernel³, the part of the OS that sits there. Everything else, your browser, your editor, your games, runs in user space⁴.

The split exists so that mistakes stay small. A music player with a bug should stop the music, not the whole machine. Because a user-mode program is stopped by the hardware whenever it reaches for something that is not its own, a crash stays inside that program.

user mode                      kernel mode
─────────                      ───────────
browser, editor, games    →    kernel: processes, memory,
shell, compiler                  files, devices, network

   │ restricted: cannot touch  │ privileged: full access to
   │ the hardware directly      │ the hardware, enforces the line
   └───────── asks through ─────┘
              syscalls

Anything a user program cannot do on its own, it asks the kernel to do. That request is the only channel between the two halves.

There are different ways to place that channel inside the OS. A monolithic kernel⁵, like Linux, keeps most services in kernel mode, where they are fast. A microkernel⁶ keeps the kernel small and moves drivers and filesystems into ordinary user-mode programs, where a failure is easier to contain. The tradeoff is the familiar one: a single large piece is fast, but one bug takes down everything, while many small pieces isolate failures better and cost more work crossing between them.

Syscalls: the boundary you program against

A system call⁷ is the only bridge between user space and the kernel. An ordinary program has no permission to touch the hardware directly, neither the disk nor the screen, so it has to make a formal request to the kernel and wait.

In practice, this synchronous dialogue happens in three steps.

The request: The program needs to save a file or display some text, so it makes a system call, pauses its own execution, and hands control to the kernel, which takes over in kernel mode.
The check: The kernel takes the command, verifies the program is allowed to perform that action, and does the work with full privileges.
The return: The kernel sends the answer back, and the program wakes up exactly where it stopped, with the result in hand.

All of that back and forth happens millions of times per second, keeping the machine safe without you ever noticing a hitch.

What the OS manages

Four kinds of resource take up nearly all of an OS’s attention.

Process

A process⁸ is a running program along with the metadata the OS must maintain: its compiled code, memory allocations, open file descriptors, and its current execution pointer. The OS manages the lifecycle of each process, starting, pausing, resuming, and cleaning them up, in order to give each program exclusive virtual access to the hardware.

Memory

The OS implements virtual memory⁹ to give each program a private, isolated address space, even though the underlying physical RAM is shared. It translates virtual addresses to physical locations on the fly to prevent programs from colliding or accessing each other’s data, and transparently pages data between RAM and secondary storage as needed.

Storage

The OS provides a file system¹⁰ to bridge the gap between raw hardware blocks and human concepts. It abstracts unnamed, unorganized blocks of bytes into structured files and folders, manages access permissions, tracks metadata, and ensures data integrity during write operations and power failures.

Devices

The OS uses Device drivers¹¹ to standardize communication with heterogeneous hardware, such as keyboards, displays, disks, and network cards. It translates uniform system requests into device-specific commands and manages input/output queues to optimize throughput and minimize processor idle time.

How the OS stays in control while barely running

Here is the puzzle: most of the time the OS is not running. Your editor is. So if the OS is in charge, who actually is?

The answer is that the machine keeps handing control back on its own. Three events can pull the OS in, whether the running program likes it or not:

The program asks for something, through a system call. This one is voluntary.
A device needs attention, because a key was pressed, a disk finished reading, or a network packet arrived. The hardware raises an interrupt¹² by itself.
A timer runs out, many times per second. Nothing on the machine can prevent it.

The third is what holds everything together. When the timer fires, the OS takes the processor back, decides which program should run next, and hands it over for a short slice. That happens whether the program being interrupted agrees or not, so the OS does not need to be running to stay in charge. It only needs to be woken up often enough.

program A runs … timer fires … OS decides … program B runs …
              ↑              ↑                 ↑
          interrupt      saves A, picks     A waits, B
            (forced)       who runs next     starts fresh

Early systems asked programs to be polite: yield the processor when you finish, and everyone else gets a turn. This is called cooperative¹³ sharing, and it fails in an obvious way. One program that forgets to yield, or crashes while holding the processor, freezes every other program on the machine. Modern systems are preemptive¹⁴: the OS takes the processor back on its own schedule and gives it to someone else. Which program that is, for how long, and at what priority is the subject of scheduling, which gets its own post.

The big picture

An operating system is software that manages the machine’s hardware on behalf of every program on it. It keeps the hardware details to itself and answers simple requests instead. It splits the machine into a trusted half, where the kernel may do anything, and a restricted half, where everything else runs and can only ask. Behind that single door it manages processes, memory, files, and devices. And a timer that nobody can ignore brings it back into control over and over, no matter what any program would prefer.

What is actually inside a running program, how one gets started, and what it takes to keep a hundred of them believing they are alone on the machine: that is the next post, where we pop the hood on a single process and read the OS’s bookkeeping for it line by line.

/tags

/sponsor

Enjoyed this post? You can sponsor me and this site.

/Related