Learning Question
If a program’s instructions run on the CPU, what is the operating system doing while the program runs?
A program does not run as an isolated sequence of instructions floating above the machine.
It runs inside a process context managed by the operating system.
The CPU executes instructions, but the operating system provides the controlled environment in which those instructions can safely use memory, files, devices, CPU time, network connections, and other processes.
The first mental model is:
The CPU executes the program’s instructions. The operating system manages the protected runtime context and shared machine resources around those instructions.
Direct Execution Versus OS Support
Ordinary user-space instructions can execute directly on the CPU.
For example, arithmetic, register moves, branches, and many memory accesses do not require a system call each time they happen.
But a program cannot directly do everything it may want to do.
It cannot simply take over the disk, receive arbitrary network packets, read another process’s memory, choose permanent ownership of a CPU core, or rewrite the kernel’s memory mappings.
Those operations cross protection boundaries.
They require operating-system support because the machine is shared and because one program must not be allowed to corrupt the whole system.
The Process Context
The operating system represents a running program as a process.
A process gives the program:
- an identity, such as a process ID
- a virtual address space
- CPU execution state
- open files and other resource references
- permissions and ownership
- parent-child relationships
- scheduling state
- exit state when it finishes
The process is not just memory.
It is the OS-managed container that makes a running instance visible, controllable, schedulable, and isolatable.
Shared Resources Need an Owner
Most interesting program behavior uses resources that outlive a single instruction.
Examples include:
- memory regions
- open files
- terminal sessions
- sockets
- pipes
- child processes
- timers
- locks or wait queues
The operating system tracks these resources and connects them to processes.
That tracking is why a process can open a file, keep using it through a file descriptor, pass it to a child process, block while reading from it, and eventually release it.
The program sees a small handle.
The operating system manages the larger resource behind that handle.
Protection Is Part of Execution
Protection is not an optional security layer added after execution.
It is part of how running programs work.
When a program accesses memory, the address must be valid for that process.
When it opens a file, permissions matter.
When it waits for input, the kernel decides whether the process should keep running or block.
When it exits, the operating system records status so a parent process can observe the result.
These behaviors are not separate from “real execution.”
They are the runtime contract between programs and the OS.
The OS Is Not Always Running the Program
It is common to say that the OS runs programs.
That phrase is useful but imprecise.
The OS does not interpret every instruction of a normal native program.
Most of the time, the CPU executes the program’s user-space instructions directly.
The OS becomes involved when:
- a system call requests kernel work
- an interrupt or timer event occurs
- a page fault or protection fault happens
- I/O completes
- scheduling must switch the CPU to another execution context
- the process blocks, exits, or receives a signal
This distinction prevents a common confusion:
The operating system supports, isolates, and coordinates program execution. It does not usually execute every user instruction on the program’s behalf.
What This Collection Follows
This collection follows the support layer around a running program.
The path is:
- the program exists as a running process
- the process gets a virtual address space
- memory is mapped and protected in pages
- privileged work crosses into the kernel through system calls
- files, devices, sockets, and pipes appear as OS-managed resources
- scheduling shares CPU time between runnable work
- threads, waits, and synchronization coordinate overlapping execution
- process lifetime, permissions, and diagnostics make runtime behavior observable
Each chapter keeps one boundary clear:
What belongs to the program’s own execution, and what is managed by the operating system?
Core Mental Model
A running program is CPU execution inside an OS-managed process context.
The program owns its logic.
The operating system owns the protected environment that lets that logic use the shared machine without breaking other programs or the system itself.
When reasoning about runtime behavior, ask:
Is this ordinary user-space execution, or is the program relying on the operating system to manage a resource, boundary, or event?
Final Summary
The operating system supports running programs by turning raw machine resources into controlled process-level abstractions.
It manages memory, CPU time, files, devices, communication, permissions, and lifetime so that many programs can run on one machine without directly controlling or corrupting each other.