Tech Behind ThingsHow the ordinary machinery actually works

Software

The Line Between A Program And The Hardware

Applications cannot touch hardware directly and must ask the operating system for everything, which is the boundary that makes a crashed program survivable.

Vibrant and engaging code displayed on a computer screen, showcasing programming concepts.
Photograph by Seraphfim Gallery via Pexels
Editorial note. Independent reporting and analysis. Nothing here is sponsored or paid for. How we work.

A program that fails takes itself down and leaves the machine running. That containment is not politeness, it is enforced by the processor itself.

The processor has separate modes

Processors run in at least two privilege levels. In the more privileged one, instructions can access any memory and control hardware directly.

In the less privileged one, whole categories of instruction are forbidden and memory access is filtered. Applications run exclusively there.

An attempt to overstep does not simply fail. It raises an exception that transfers control to the operating system, which decides what happens next.

Every application sees a private memory map

Programs use addresses that are translated to physical locations by dedicated hardware, using tables the operating system maintains for each process.

Two programs using the same address are therefore reading entirely different memory. Neither can reach the other's data even by accident.

This is what makes a crash local. A program that writes to an invalid address is stopped at the translation step, before anything outside it is affected.

System calls are the only doorway

To read a file or send a packet, a program executes a special instruction that deliberately traps into the privileged level with a request number and arguments.

The operating system checks the arguments, performs the work if permitted, and returns. The application never touched the device.

The set of these calls is the true interface of an operating system. Libraries and frameworks are conveniences layered above a much smaller and slower-changing list.

The transition has a real cost

Crossing the boundary requires saving state, switching privilege and validating inputs. It is far more expensive than an ordinary function call.

Software therefore batches work to cross less often, which is why reading a file in large chunks vastly outperforms reading it a byte at a time.

Some interfaces avoid the crossing entirely by sharing a region of memory between application and system, using it as a queue that both sides poll.

Drivers sit on the privileged side

Hardware needs code that speaks its specific language, and that code runs with full privileges because it must touch the device directly.

A defective driver is therefore not contained the way an application is. It can corrupt anything, which is why driver faults take whole systems down.

Modern systems push drivers out into the unprivileged level wherever performance allows, trading a little speed for the containment that applications have always enjoyed.

Questions readers ask

Why does a copied folder show a different size?

Block allocation, compression and metadata differ between filesystems. The contents are identical while the space consumed is not.

Is defragmenting a solid state drive useful?

No. There is no seek penalty to remove, and rewriting every block consumes write endurance for no measurable benefit.

Softwarestoragesoftwareoperating systemsdata
Junko Ishida
Contributing writer, Tech Behind Things

Junko covers batteries, charging and energy density, and is unimpressed by most battery claims.

Also by Junko Ishida