Program vs. Process: A Distinction That Matters
One of the most important conceptual distinctions in operating systems is one that is easy to overlook: the difference between a program and a process.
A program is a static artifact — a set of instructions stored
somewhere, waiting. When you look at an application icon on your desktop, or a
.exe file in a folder, or a Python script sitting in a directory, you are
looking at a program. It is inert. Nothing is happening. It is just data on a disk,
no different in principle from a text document or a photo.
A process is what happens when a program is brought to life. When you double-click that application icon, the OS loads the program's instructions into RAM, allocates memory for the program's data, assigns it CPU time, and begins executing its instructions. At that moment, a process exists. The process is dynamic — it has a current position, current values in registers, a current state. It is an activity in progress, not a static document.
A program is like a piece of sheet music sitting on a shelf — a precise, static set of instructions. A process is a musician performing that piece right now — a dynamic, evolving activity whose state changes with every note.
This distinction matters more than it might initially seem. Here is why: the same program can give rise to multiple processes simultaneously. If you open your word processor twice, two separate processes are running — each with its own memory, its own position in the program, its own data. They are both running the same program (the same sheet music), but they are independent performances. What happens in one does not affect the other.
Conversely, a process is not just a program. It includes everything the OS is tracking about that program's current execution: where it is in the instruction sequence, what values are in the CPU registers, what memory has been allocated to it, what files it has open, what peripheral devices it is using. Strip all of that away and you have the program again — the static instructions — but not the process.
A concrete example: Microsoft Word is a program. When you launch it, a process is created. When you open a second Word window, a second process may be created (or the same process may spawn a new document window, depending on the OS and application design). The program on disk has not changed. The processes running in RAM are new, active, and independent.
Process State: The Snapshot
Every running process has a process state — a complete snapshot of everything the OS needs to know about that process at a particular moment. The process state includes:
- The current value of the program counter (which instruction the process is about to execute next)
- The current values in all CPU registers (the working data the process is operating on)
- The memory area assigned to the process
- The priority of the process (how urgently it needs CPU time)
- Whether the process is currently ready or waiting
A process is ready if it can continue executing — it has everything it needs and is simply waiting for CPU time. A process is waiting if it cannot currently make progress because it is blocked on some external event: a file read that hasn't completed, a keystroke that hasn't arrived, a message from another process that hasn't been sent.
The ready/waiting distinction is critical for efficiency. A process that is waiting for a disk read to complete has nothing useful to do with the CPU — giving it CPU time would be pure waste. The OS should give that CPU time to a process that is ready and can actually use it.
Analogy: Imagine a restaurant kitchen with multiple orders in progress. Some dishes are actively being cooked (ready — they need the chef's attention now). Others are waiting for the oven to preheat or for an ingredient to finish marinating (waiting — they cannot progress until an external event completes). A good chef does not stand and watch the oven. They work on ready dishes while waiting dishes sort themselves out. The OS dispatcher works the same way.
The Process Table
A modern computer runs many processes simultaneously — often dozens or hundreds. To keep track of all of them, the OS maintains a data structure in RAM called the process table.
The process table is essentially a list of all currently active processes, with one entry per process. Each entry contains the process's state information: the program counter value, register values, memory allocation, priority, and ready/waiting status. Think of it as the OS's master scheduling ledger — the complete accounting of every performance currently in progress.
When you launch an application, the OS creates a new entry in the process table for that process. When the application closes, the entry is removed. If the process spawns sub-processes (as many applications do), each sub-process gets its own entry.
See it yourself: On a Windows machine, pressing Ctrl + Alt + Delete and opening Task Manager gives you a live view of the process table. On a Mac, opening Activity Monitor shows the same information. The list of running processes, their CPU usage, and their memory consumption is exactly what the OS's process table tracks — displayed in a human-readable form.
What Comes Next
Now that we know what a process is and how the OS keeps track of them, the next question is: how does the OS actually manage all these processes? With dozens of processes competing for a single CPU, something has to decide who runs when — and how to switch between them so quickly that it feels instantaneous to the user. Reading 2 covers the scheduler, the dispatcher, and the interrupt mechanism that makes it all work.