How an Operating System Actually Runs Software

The Machine That Knows Nothing

If you open the Task Manager on your laptop or run top in a Linux terminal, you will see something astonishing:

• 250 background processes running.
• 3,000 active threads.
• A web browser rendering 40 tabs.
• A media player streaming music.
• An antivirus scanner inspecting disk sectors.

Yet beneath this bustling metropolis of software sits a physical microprocessor that has zero concept of any of these things.

As we discovered in How a CPU Executes an Instruction, a CPU is not an intelligent coordinator. It is a clocked assembly line of logic gates. It has a Program Counter register pointing to an address in RAM, an instruction decoder, and an ALU. It fetches 32 or 64 bits of machine code, executes them, increments the counter, and fetches the next.

A bare CPU has no idea what a "process" is. It does not know what a "file" is. It does not know who the "user" is.

If a buggy game enters an infinite loop:

while (1) {
    // Do nothing forever
}

the CPU will happily execute that infinite loop until the sun burns out. Left to itself, a CPU running that loop would freeze the entire computer. The mouse would stop moving, audio would cut out, and no other program on Earth could ever execute another instruction.

Even worse: if two different programs are running on the same machine, what stops Program A from writing random numbers into the memory of Program B, stealing your banking password, or commanding the monitor to go black?

The answer is the Operating System (OS).

The OS is not merely another application. It is the invisible government of the machine. It creates the illusion that every application has its own dedicated computer, while ruthlessly enforcing boundaries between them using physical mechanisms built directly into the silicon.

Mechanism 1: The Two Realities (Ring 0 vs. Ring 3)

The cornerstone of modern computer security is a simple physical fact: The CPU hardware itself refuses to obey certain instructions unless it is in a special hardware state.

Microprocessors implement Hardware Privilege Levels, historically known on x86 architectures as Protection Rings:

                  THE CPU HARDWARE PROTECTION RINGS

                 ┌─────────────────────────────────────┐
                 │               RING 3                │
                 │   User Applications (Untrusted)     │
                 │   • Chrome, Spotify, Word, Games    │
                 │   • CANNOT touch physical hardware  │
                 │   • CANNOT execute privileged ops   │
                 │   ┌─────────────────────────────┐   │
                 │   │           RING 0            │   │
                 │   │      OS Kernel (Trusted)    │   │
                 │   │   • Full hardware control   │   │
                 │   │   • Manages page tables     │   │
                 │   │   • Intercepts interrupts   │   │
                 │   └─────────────────────────────┘   │
                 └─────────────────────────────────────┘

The diagram below maps the privilege rings and structural isolation boundaries of an operating system:

Inside the CPU is a special internal register called the Processor Status Register (or EFLAGS/RFLAGS on x86). Within this register are two tiny bits known as the Current Privilege Level (CPL):

• CPL = 00 (Ring 0 / Kernel Mode): The processor is in supervisor mode. The CPU will execute every machine instruction in its repertoire, including commands to directly access device hardware, modify memory mapping registers, or halt the machine.
• CPL = 11 (Ring 3 / User Mode): The processor is in user mode. All normal applications (your browser, Python scripts, Spotify) run here.

The Forbidden Instructions

When the CPU is in Ring 3, the silicon decoder locks down. If a program in Ring 3 attempts to execute a privileged instruction—such as:

• cli (Clear Interrupt Flag—trying to turn off hardware interrupts)
• mov cr3, rax (Trying to rewrite the memory management table)
• in / out (Directly sending electrical signals to physical I/O ports)
• hlt (Telling the CPU to power down into sleep mode)

the instruction decoder detects that CPL == 3.

The CPU does not execute the instruction. Instead, the hardware instantly aborts the pipeline, generates a General Protection Fault (Exception #13), forcibly strips privilege back to Ring 0, and hands execution over to the OS kernel.

The kernel inspects the offender, terminates the application, and prints the familiar message:

Segmentation fault (core dumped)

A user application cannot bypass this boundary because the boundary is enforced by microscopic copper wires and logic gates inside the silicon chip itself.

Mechanism 2: Preemptive Multitasking and the Timer Interrupt

If a user program in Ring 3 cannot execute privileged instructions, how does the OS regain control if that user program enters an infinite loop?

In the early days of personal computing (Windows 3.1 and classic Mac OS), computers relied on Cooperative Multitasking. The operating system politely asked applications: "When you finish your work, please yield control back to me."

If an application froze, had a bug, or refused to yield, the entire computer locked up solid.

Modern operating systems use Preemptive Multitasking. The OS does not ask for permission. It takes control by force.

How? Through a physical electronic clock called the Hardware Timer Interrupt.

                  THE PREEMPTIVE TIMER INTERRUPT CYCLE

       Time ────────────────────────────────────────────────────────►
       
       [ User App: Game / Code ] ──────► ⚡ TIMER INTERRUPT FIRES! ⚡
                                                 │
                                                 ▼ (Hardware forces jump)
                                         [ OS KERNEL: Ring 0 ]
                                         • Did app exceed time slice?
                                         • YES: Save app registers
                                         • Pick next app from queue
                                         • Restore next app registers
                                                 │
                                                 ▼ (Hardware drops to Ring 3)
       [ Next App: Web Browser ] ◄───────────────┘

On your motherboard, an independent electronic circuit—such as the APIC Timer (Advanced Programmable Interrupt Controller)—ticks relentlessly.

Before the kernel starts running a user application, it programs this timer: "Fire a hardware electrical pulse in exactly 10 milliseconds."

The kernel then drops to Ring 3 and lets the user application run.

Ten milliseconds later, the timer circuit reaches zero and sends an electrical pulse directly down an interrupt pin into the CPU.

When an interrupt arrives, the CPU hardware does something extraordinary:

1. It freezes the user program midway through whatever instruction it is executing.
2. It pushes the program’s current state (its Program Counter, Stack Pointer, and Register values) onto a private memory stack.
3. It automatically flips the privilege level from Ring 3 back to Ring 0.
4. It forces the Program Counter to jump directly to a predefined memory address where the Operating System Scheduler lives: the Interrupt Service Routine (ISR).

The user program has no say in the matter. It cannot disable the interrupt (because cli is forbidden in Ring 3). It cannot block the timer.

The operating system woke up.

Mechanism 3: The Context Switch

Once the timer interrupt wakes the kernel, the OS scheduler asks: "Has this application consumed its allotted time slice (quantum)?"

If yes, the OS performs a Context Switch:

                ANATOMY OF A HARDWARE CONTEXT SWITCH

       Application A (Ring 3)                 Application B (Ring 3)
             │                                      ▲
             ▼ (Interrupt)                          │ (iret)
    ┌─────────────────┐                    ┌─────────────────┐
    │ Save Registers: │                    │ Load Registers: │
    │ RAX, RBX, RCX...│                    │ RAX, RBX, RCX...│
    │ RIP, RSP, RFLAGS│                    │ RIP, RSP, RFLAGS│
    └────────┬────────┘                    └────────▲────────┘
             │                                      │
             ▼                                      │
    ┌─────────────────┐   OS Scheduler     ┌────────┴────────┐
    │ Store into A's  │ ─────────────────► │ Read from B's   │
    │ Process Control │    (Select B)      │ Process Control │
    │ Block (PCB)     │                    │ Block (PCB)     │
    └─────────────────┘                    └─────────────────┘
             │                                      ▲
             ▼                                      │
    ┌───────────────────────────────────────────────┴────────┐
    │ Swap Memory Mapping Register: mov cr3, B_page_table    │
    └────────────────────────────────────────────────────────┘

The steps of a context switch take less than a microsecond:

1. Save State A: The kernel reads all physical CPU registers—RAX, RBX, RCX, RSI, RDI, the Stack Pointer (RSP), and the Instruction Pointer (RIP)—and writes them into a struct in RAM called the Process Control Block (PCB) for Application A.
2. Select Next Process: The scheduler picks Application B from the queue of runnable processes.
3. Swap Memory Space: The kernel points the CPU's memory management register (CR3) to Application B’s page table (explained below).
4. Restore State B: The kernel loads Application B’s saved register values from its PCB back into the physical silicon registers.
5. Resume: The kernel executes the iret (Interrupt Return) instruction. The CPU drops privilege back to Ring 3 and resumes Application B at the exact microscopic clock cycle where it was paused 10 milliseconds ago.

By swapping between applications 100 to 1,000 times every second, a single CPU core creates the seamless illusion that dozens of programs are running at the exact same instant.

Mechanism 4: Virtual Memory and the MMU

The most powerful illusion created by the operating system is Virtual Memory.

When you compile a program in C or Rust and inspect the memory address of a pointer:

printf("Address of variable: %p\n", &x);
// Output: 0x00007ffeefbfc6b8

That number is a lie.

It is not a physical location in a RAM chip. It is a Virtual Address.

If you launch ten separate instances of the same program simultaneously, every single one of them will print the exact same pointer address: 0x00007ffeefbfc6b8. Yet none of them overwrite each other!

Every application running in Ring 3 lives inside its own private, isolated universe. As far as the program knows, it owns the entire 64-bit address space ($18\text{ quintillion bytes}$ of memory) all to itself.

              VIRTUAL MEMORY TRANSLATION VIA HARDWARE MMU

    Program A (Virtual Space)                     Program B (Virtual Space)
    Address: 0x00400000                           Address: 0x00400000
             │                                             │
             ▼                                             ▼
    ┌─────────────────┐                           ┌─────────────────┐
    │ Page Table A    │                           │ Page Table B    │
    │ (CR3 points here│                           │ (CR3 points here│
    │  when A runs)   │                           │  when B runs)   │
    └────────┬────────┘                           └────────┬────────┘
             │                                             │
             ▼                                             ▼
    Maps to Physical:                             Maps to Physical:
    Frame #10,432                                 Frame #89,201
             │                                             │
             └──────────────────────┬──────────────────────┘
                                    │
                                    ▼
                     PHYSICAL RAM (DRAM HARDWARE)
                     ┌───────────────────────────┐
                     │ Physical Frame #10,432    │ ◄── Program A Data
                     ├───────────────────────────┤
                     │ Physical Frame #89,201    │ ◄── Program B Data
                     └───────────────────────────┘

The Translation Engine: The MMU and Page Tables

Between the CPU core and the physical RAM bus sits a dedicated hardware computer: the Memory Management Unit (MMU).

The operating system cuts physical RAM into standardized blocks called Pages (typically $4\text{ Kilobytes}$ each).

For every running process, the kernel constructs a Page Table in memory: a multi-tier dictionary mapping Virtual Page Numbers to Physical Frame Numbers:

• Program A says: "Read address 0x00400000."
• The MMU intercepts the address, looks up Page Table A, and sees that virtual 0x00400000 corresponds to physical DRAM chip location 0x1A2B3000.
• The MMU sends 0x1A2B3000 out across the memory bus wires.

When the OS switches to Program B, it changes the address stored in CPU register CR3 (the Page Directory Base Register).

Now when Program B says: "Read address 0x00400000", the MMU looks up Page Table B and translates it to physical DRAM location 0x8F9E0000.

Why Virtual Memory Prevents Hacking and Crashes

1. Absolute Process Isolation: Program A cannot read or write Program B’s memory, because Program A’s page table physically does not contain any pointer to Program B’s physical frames. Program A could write random numbers across its entire address space without touching a single byte of Program B.
2. Kernel Protection: The page table has permission bits on every entry:
   • R/W bit: Is this memory read-only (like compiled code) or writable (like variables)?
   • U/S bit: Is this page User-accessible (Ring 3) or Supervisor-only (Ring 0)?
   • NX bit: No-Execute. If a hacker injects malicious code into a data buffer, the MMU refuses to execute it as code.

If a user program tries to write to a read-only page or access a Ring 0 page, the MMU hardware triggers a Page Fault Exception (#14), dropping immediately to the OS kernel to kill the process.

How Applications Talk to Hardware: The System Call

If user applications in Ring 3 cannot touch physical hardware—cannot write to disk, cannot draw pixels on the screen, cannot send packets across the network—how does anything actually happen?

Applications must ask the operating system to do it on their behalf through a System Call (syscall).

Think of user space as a bank customer standing in front of bulletproof glass. The customer cannot walk into the vault and take cash. They must fill out a deposit slip, hand it through a secure slot to the teller (the kernel), and let the teller access the vault.

                    THE SYSTEM CALL ARCHITECTURE

       USER SPACE (Ring 3)                       KERNEL SPACE (Ring 0)
       
       1. Program calls printf()
       2. Standard C Library (libc)
          prepares parameters:
          • File descriptor: 1 (stdout)
          • Buffer: "Hello, World!"
          • Length: 13
          • Syscall Number: 1 (sys_write)
       3. Executes instruction:
          ───► SYSCALL / SYSENTER ───►  4. Hardware switches to Ring 0!
                                        5. Jumps to Kernel Syscall Table
                                        6. Kernel verifies buffer bounds
                                        7. Kernel instructs graphics/serial
                                           driver to emit pixels
                                        8. SYSRET drops back to Ring 3

When you write open(), read(), write(), or socket() in your code:

1. The language runtime places the system call number and parameters into designated CPU registers (such as RAX, RDI, RSI).
2. The runtime executes the syscall instruction (on x86-64) or svc (on ARM).
3. The CPU atomically transitions from Ring 3 to Ring 0, changes the stack pointer to a secure kernel stack, and jumps to the kernel's system call dispatch table.
4. The kernel validates every pointer argument to ensure the user program is not tricking the kernel into overwriting private memory.
5. The kernel communicates with the device driver, performs the physical I/O, and returns the result.
6. The sysret instruction restores Ring 3 privilege and returns control to the user application.

On a typical modern computer, your web browser executes thousands of system calls every second just to display webpages, poll for mouse clicks, and receive network packets.

Summary: The Grand Conductor

An operating system is not a program in the traditional sense. It is an intricate architectural partnership between software algorithms and silicon physics:

Without this invisible supervisor running in Ring 0, every crash of a single browser tab would shut down your computer, every background script could steal your cryptographic keys, and the miracle of concurrent modern computing would dissolve into chaotic electrical noise.