A tower, not a single floor
In the earlier guides you saw what a computer really is — a stored-program machine that fetches and runs instructions one after another — and you saw the difference between code that is compiled ahead of time and code that is interpreted as it runs. Now we zoom out from that single processor and ask a bigger question: when your program asks to print a line or open a file, who actually does the work? The honest answer is that nobody does it alone. A modern computer is built as a tower of layers, and each layer leans on the one below it.
This tower has a name: the abstraction stack. Think of it like floors in a building. Each floor hides the messy plumbing of the floor beneath and offers the floor above a clean, simple set of services. The people on the top floor never see the concrete being poured in the basement — they just trust that the lights turn on. In the same way, your app trusts that 'write these bytes to the screen' will happen, without knowing one thing about how electrons move through the display.
The four floors
From the bottom up, the stack on a typical machine has four floors worth naming. At the very bottom is the hardware: the CPU that runs instructions, the memory that holds your data, and the I/O devices (disk, screen, keyboard, network card) that connect to the outside world. The hardware is fast, literal, and completely unprotected — it will gladly let any code overwrite any byte, which is exactly why we do not let your app touch it directly.
One floor up sits the kernel — the core of the operating system. The kernel is the one piece of software that is allowed to talk to the hardware directly, and its whole job is to share that hardware safely among every program running at once. It decides which program gets the CPU next, hands out memory, and guards the devices. It is the landlord of the building: it owns the real resources and rents them out under strict rules.
Above the kernel sit the system libraries, and the one you will meet first is the C standard library (often called libc). A library is a bundle of ready-made functions you can call instead of writing them yourself. The library wraps the kernel's raw, bare services in friendlier shapes — for example, the cozy printf() you will use in your first program is a library function, not the hardware. On the top floor is the application: the program a person actually wants to run, your code included.
+-------------------------------+ | Application (your code) | <- top floor +-------------------------------+ | Libraries (libc, ...) | <- friendlier functions +-------------------------------+ | Kernel (the OS core) | <- shares the hardware +===============================+ <- user / kernel boundary | Hardware (CPU, RAM, IO) | <- the metal +-------------------------------+
The one wall that really matters
Not all the floors are separated equally. The boundary between your app and the libraries is soft — calling printf() is just an ordinary function call, a jump to some code in the same process, no different in kind from calling a function you wrote. But the boundary between the libraries and the kernel is a real, hardware-enforced wall. This is the split between user space and kernel space, and crossing it is not a normal jump.
Your code runs in user mode, where the CPU refuses to let it touch hardware or other programs' memory directly. To get real work done — read a file, send a packet, ask for more memory — it must request the kernel to do it, through a system call. A system call is not just another function call: it deliberately traps into the CPU's privileged kernel mode, lets the kernel run the operation on your behalf, then drops back to user mode with the result. This is the key distinction in the whole guide.
Following 'hello, world' down and back
Let's make this concrete with the program you will run for real in the next guide: a hello-world program that prints one line. When you call printf("hello, world\n"), it looks like one tiny act, but that single line falls through every floor of the tower and climbs back up. Watching it travel is the best way to feel where the boundaries are.
- App floor: your code calls printf("hello, world\n") — an ordinary function call into the C library, still entirely in user space.
- Library floor: printf() formats the text, then hands the finished bytes to a lower library routine that asks the kernel to actually send them out.
- Crossing the wall: the library issues the write() system call, which traps into kernel mode — the one genuine boundary in this whole trip.
- Kernel floor: the kernel checks that you are allowed, then drives the terminal device to put the characters on screen, talking to the hardware directly.
- Climbing back: write() returns a count up to the library, printf() returns to your code, and execution carries on — back in user space where it started.
Every floor did exactly its own job and trusted the floor below. Your code never named a hardware register, never asked which kind of screen you have, never knew there was a kernel mode at all. That is the abstraction stack paying off: you wrote 'print this line' and four layers cooperated to make it true.
Why the layers are worth knowing
This map is not trivia — it is the orientation you will use for the whole ladder. When you later learn about the heap, you are asking one library and one kernel floor for memory. When you meet processes and threads, you are watching the kernel hand out CPU time. When a program dies with a segfault, the hardware caught it crossing a wall it was not allowed to cross, and the kernel killed it. Almost every advanced topic ahead is really a closer look at one floor, or at one boundary between two of them.
Two honest cautions before we move on. First, this four-floor picture is a clean simplification: real systems add device drivers, virtual machines, containers, and more layers between and inside these floors. The four names are the right starting frame, not the whole truth. Second, the layers are a tradeoff, not a free win — each one adds a little cost and hides a little detail, which is exactly why systems programmers, working close to the metal, sometimes peel a layer away to see what is really happening underneath.