Three jobs in one program
From the instant you press the power button to the moment you shut down, one program is quietly in charge of everything: the operating system. It is easy to think the OS is the wallpaper, the Start menu, or the app store, but those are just programs that ship with it. The real operating system is the layer sitting between your apps and the bare machine, and it is doing three jobs at the same time.
First, it is a resource manager. A computer has only so much to go around — a few CPU cores, a fixed amount of memory, one disk, one screen — yet you run dozens of programs that each behave as if they own the machine. Like a single shared kitchen full of cooks, it would be chaos without a manager deciding who gets the stove, and for how long. Second, it is an abstraction layer: instead of forcing every app to know your exact disk's electrical commands, it offers clean, uniform ideas like "open a file" or "send these bytes". Third, it is a control program: it watches running programs, stops a faulty one from crashing the whole machine, and enforces who is allowed to do what.
Almost every device has one, even when you never see it: your phone, your laptop, the servers behind a website, even the chip in a microwave. Everything else in this whole subject — processes, scheduling, paging, files — is really just a closer look at one of these three jobs the OS is quietly doing for you.
The layered machine: hardware, OS, apps
The clearest way to picture a computer is as a stack of layers, like floors of a building, each resting on the one below and offering services to the one above. At the very bottom is the hardware — the CPU, memory, disks, devices — a machine that can only execute raw instructions. At the very top are you and your applications. The OS is the crucial floor in the middle, and almost everything you do flows down through it and back up.
It also helps to split software into two families. System software exists to run and support the computer itself — the OS, its drivers, the linker and loader that prepare programs to run. Application software exists to do a task you actually care about — a browser, a game, a spreadsheet. The rough test: if a program mainly serves the machine or other programs, it is system software; if it mainly serves your goal, it is an application. Applications lean on the OS for everything low-level, asking it to open files and draw on screen rather than touching hardware themselves.
The kernel and the great divide
At the heart of the OS is the kernel — the innermost, most trusted part, the program that is always running and has full power over the hardware. Strip away the menus, the windowing system, and the bundled apps, and the kernel is what remains. If the OS is the hotel staff, the kernel is the building manager with the master key: it can enter any room and operate any machine, and everyone else must go through it.
This is where the single most important boundary in all of computing appears. The CPU runs in one of two modes, and the hardware itself enforces the rule — this is dual-mode operation. In user mode, an ordinary program may do its own arithmetic and access only the memory it was granted, but if it tries a dangerous privileged instruction — directly commanding a device, rewriting the memory map, disabling interrupts — the hardware refuses and traps to the OS. In kernel mode, every instruction is allowed; this is where the kernel runs. A single hardware flag, the mode bit, records which mode the CPU is in right now, and the hardware checks it on every privileged action. Crucially, a user program cannot just set that bit to kernel — if it could, the whole protection scheme would collapse.
Why fuss over this one line? Because it is the whole system's stability and security boundary. A bug in an ordinary app crashes that app and nothing else; a bug in the kernel, trusted with full hardware power, can crash or compromise the entire machine. That is exactly why operating systems work so hard to keep the kernel small, careful, and hard to fool.
The doorway: a system call
If a user-mode program cannot touch hardware itself, how does it ever read a file or send a packet? It asks. A system call is the one controlled doorway from user mode into the kernel — the official, guarded passage. Imagine a bank: you cannot walk into the vault and grab cash, but you can step to the teller window, fill out a slip, and request a withdrawal. The teller (the kernel), trusted and behind the counter, checks your request and does the privileged work for you.
Concretely, when your code calls something like "read(fd, buf, n)", a special trap instruction switches the mode bit to kernel and jumps to a fixed handler the OS chose in advance. Here is the trip, step by step.
- Your program sets up the request (which call, with which arguments — the file descriptor, the buffer, how many bytes) and executes the trap instruction.
- The hardware atomically flips the mode bit to kernel and jumps into the OS's trap handler — control is now inside the kernel.
- The kernel checks the request: are you allowed to read this file? Are the arguments valid? If not, it refuses and returns an error.
- If allowed, the kernel does the privileged work — it asks the disk for the bytes and copies them into your buffer.
- The kernel flips the mode bit back to user and returns, and your program resumes exactly where it left off, now with its data.
Many programs at once — and how it all starts
Early computers ran one job at a time, top to bottom, and the moment that job paused to read from disk, the expensive CPU sat idle. Multiprogramming fixed this: keep several programs in memory at once, and whenever the running one waits for I/O, hand the CPU to another. Push the same idea to its friendly extreme and you get time-sharing — switch between programs so quickly, dozens of times a second, that each user feels like they have the machine to themselves. This rapid switching is why your music keeps playing while a download runs and a chat window sits open: the OS is slicing the one CPU into tiny turns.
But how does the OS get loaded in the first place, before any OS exists to load it? That bootstrapping puzzle is solved by the boot process: a tiny program baked into firmware runs first at power-on, finds the kernel on disk, loads it into memory, and hands over control. From that first instruction onward, the kernel is in charge. And there is a real design choice in how that kernel is built — its structure. A monolithic kernel puts almost everything (scheduling, memory, drivers, file systems) in one big privileged program: fast, because parts call each other directly, but a bug anywhere can sink the whole thing. A microkernel keeps only the bare minimum in kernel mode and pushes the rest out to user-mode services that talk by messages: more robust and easier to isolate, but it pays a real cost in message-passing overhead. A hybrid kernel splits the difference. None is automatically "better" — it is a trade-off, and the next guides in this rung open each of these doors.