These two words get used almost interchangeably in casual conversation, and honestly, I used to conflate them myself before really digging into operating systems. But “program” and “process” describe genuinely different things, and understanding the distinction unlocks a much clearer picture of how computers actually run software. Let me walk through the difference carefully, with concrete examples.
What Is a Program?
A program is a passive entity — a set of instructions stored as a file on disk, typically in an executable format (like .exe on Windows, ELF binaries on Linux, or Mach-O binaries on macOS/iOS). It’s static. It sits there on your storage device, not doing anything, not consuming CPU time, not occupying working memory beyond the disk space it takes up. A program contains code, potentially along with associated resources like static data, string constants, or embedded assets.
Think of a program like a recipe written in a cookbook. The recipe exists, fully detailed, on the page — but until someone actually starts cooking, following those instructions step by step, nothing is happening. The recipe itself doesn’t consume any ingredients or take up stove space just by existing on the shelf.
What Is a Process?
A process is an active entity — a program that has been loaded into memory and is being executed by the CPU, with the operating system actively managing its execution state, resources, and lifecycle. The moment you double-click an application icon or run a command in a terminal, the OS takes that static program file and transforms it into a living, running process: allocating memory, setting up a process control block, assigning it a unique process ID, and eventually scheduling it for CPU time.
Going back to the cookbook analogy: a process is the actual act of cooking that recipe — ingredients are out, the stove is on, steps are actively being followed, and the state changes as you progress (chopping, sautéing, plating). It’s dynamic, consuming real resources (time, counter space, actual ingredients) while it’s happening.
Key Differences at a Glance
| Aspect | Program | Process |
|---|---|---|
| Nature | Passive, static | Active, dynamic |
| Location | Stored on disk (secondary storage) | Loaded into main memory (RAM) |
| State | Doesn’t change while unexecuted | Continuously changes (running, waiting, ready) |
| Resource usage | None while dormant | CPU time, memory, file handles, etc. |
| Lifespan | Persists indefinitely until deleted | Exists only during execution, from creation to termination |
| Identity | Identified by filename/path | Identified by a unique Process ID (PID) |
| Quantity relationship | One program can spawn multiple processes | Each process originates from exactly one program (at creation) |
One Program, Multiple Processes
An important and often underappreciated detail: a single program can be the source of multiple, simultaneously running, independent processes. If you open three separate windows of the same text editor application, you might be running three distinct processes (depending on the specific application’s architecture), each with its own PID, its own memory space, its own execution state — yet all three originated from the exact same program file on disk.
A great everyday example: open your web browser and check your system’s process list (Task Manager on Windows, Activity Monitor on macOS, ps aux or htop on Linux). You’ll often see many separate browser-related processes listed, even though you only “opened the browser” once — modern browsers like Chrome and Firefox deliberately use a multi-process architecture, spawning separate processes for the main browser UI, each tab (or group of tabs), extensions, and the GPU rendering component, specifically for stability (a crashing tab doesn’t take down the whole browser) and security (process-level sandboxing/isolation between components).
What Happens When a Program Becomes a Process
- The OS loads the program’s executable file from disk into memory.
- It allocates a fresh address space for this new process — memory regions for code (text segment), global/static data, the heap (dynamic memory allocation), and the stack (function call frames, local variables).
- It creates a Process Control Block (PCB), a kernel data structure that tracks this process’s state, program counter, registers, scheduling info, and resource ownership (open files, etc.).
- It assigns a unique Process ID (PID).
- The process enters the “New” state and then transitions toward “Ready,” eventually getting scheduled for actual CPU execution, at which point it becomes genuinely active and begins executing instructions.
From this point forward, the process has its own life — it can change its own data, allocate and free memory dynamically, open and close files, spawn child processes, and eventually terminate, none of which affects the original program file sitting untouched on disk (barring the process specifically writing back to that file, which is a distinct, deliberate action).
Processes vs. Threads — A Related but Distinct Distinction
While we’re clarifying terminology, it’s worth briefly distinguishing processes from threads too, since they’re often discussed together. A process has its own independent memory address space; a thread is a unit of execution within a process, sharing that process’s memory space with any other threads of the same process. A single process can contain multiple threads, all working concurrently within the same shared memory, which is more lightweight than spawning entirely separate processes when true memory isolation isn’t required.
Real-World Examples Across Operating Systems
Linux: You can clearly see this distinction using standard tools. ls -l /usr/bin/firefox shows you the static program file. Running ps aux | grep firefox after launching it shows you the actual running process(es), each with a distinct PID, memory usage, and CPU time — all sourced from that one program file.
Windows: Similarly, firefox.exe sitting in Program Files is the program; opening Task Manager’s Details tab while Firefox is running shows you the actual process(es) with their PIDs and resource consumption.
Android: Each installed app corresponds to a program (an APK package containing compiled code and resources), but when launched, it becomes one or more actual running processes, managed by the Android runtime and Activity Manager, complete with Android-specific process states (foreground, background, etc.) layered on top of the underlying Linux process model.
iOS: Similarly, an app bundle on disk is the program; launching it creates a process managed by the OS, subject to iOS’s specific app lifecycle states (Active, Background, Suspended) and strict resource management given the platform’s mobile constraints.
Diagram: From Program to Process
[ Program on Disk ]
(static, e.g., app.exe)
|
user launches it
|
v
+----------------------------+
| OS loads into memory |
| - allocates address space |
| - creates PCB |
| - assigns PID |
+----------------------------+
|
v
[ Running Process ]
(dynamic, active, has state,
consumes CPU/memory/resources)
Troubleshooting-Style Clarifications
A few common points of confusion worth addressing directly:
- “Why does my program keep running even after I close the window?” — Because closing a visible window doesn’t always terminate the underlying process; some applications intentionally keep a background process alive (common with system tray apps, background sync services, or browsers with a “keep running in background” setting).
- “Why do I see multiple entries for the same app in Task Manager?” — Because that single program has spawned multiple processes (or the app is a multi-process architecture by design, like modern browsers), or you genuinely have multiple independent instances running.
- “I deleted the program file, but the process is still running — why?” — On UNIX-like systems especially, a running process holds an open reference to its executable file’s data even if the filename is unlinked/deleted from the directory; the process continues running using the memory image already loaded, though you generally can’t relaunch it until a fresh copy of the program file exists again.
Best Practices
- When diagnosing performance issues, always check actual running processes (Task Manager,
ps, Activity Monitor) rather than assuming resource usage based on which programs you’ve “opened” — a program can spawn several processes, or continue running invisibly in the background. - Understand your target platform’s process model when developing software — whether it’s beneficial to use a multi-process architecture (like browsers do, for stability/security) versus a multithreaded single-process approach depends heavily on your specific isolation and resource-sharing needs.
- Clean up (properly terminate) processes you spawn programmatically to avoid leaving orphaned or zombie processes consuming system resources unnecessarily.
Summary
A program is a static, passive file of instructions sitting on disk; a process is the dynamic, active instance of that program actually executing, complete with its own memory, resources, and lifecycle managed by the operating system. A single program can give rise to multiple independent processes, each tracked separately by the OS with its own unique identity and state. This distinction is foundational to understanding virtually everything else about how operating systems manage multitasking, memory, and resources.
FAQs
Q: Can a process exist without a program? No — every process originates from a program’s executable instructions; a process is fundamentally that program in a state of execution.
Q: Can one program create multiple processes? Yes — launching the same application multiple times, or applications deliberately designed with multi-process architectures (like modern web browsers), routinely create multiple distinct processes from a single program file.
Q: Does modifying a program file affect processes already running from it? Generally no — once a process is loaded into memory, it typically continues running from that in-memory copy, unaffected by subsequent changes to the on-disk file (though this can vary based on OS specifics and whether the file is memory-mapped in certain modes).
Q: What uniquely identifies a process versus a program? A process is identified by a unique Process ID (PID) assigned by the OS at creation; a program is identified by its filename/path on disk.
Q: Is an app on my phone a program or a process? The installed app package is the program; once you launch it and it’s actually running, it becomes a process (or several processes, in more complex cases).
References
- Silberschatz, Galvin, Gagne — Operating System Concepts, Chapter on Processes
- Linux man-pages — proc(5) — https://man7.org/linux/man-pages/man5/proc.5.html
- Microsoft Docs — Processes and Threads — https://learn.microsoft.com/en-us/windows/win32/procthread/processes-and-threads
- Chromium Project — Multi-Process Architecture — https://www.chromium.org/developers/design-documents/multi-process-architecture/