Start here

A program is static (bytes and metadata on disk). A process is dynamic (registers, stacks, kernel structures). Confusing them causes wrong answers about exec, fork, and memory sharing.

Program vs process (definitions)

The program is the executable image: ELF segments, dynamic linker metadata, maybe an interpreter path. Nothing here “runs” until the loader maps pages and the CPU fetches the entry point.

The process adds execution state: program counter, stack pointer, heap arenas grown via brk/mmap, file descriptor table, and signal masks. Two processes can map the same binary read-only and still havedifferent address spaces and lifetimes.

By the end of this page you should be able to

Explain how the same file on disk can back multiple concurrent processes.
Describe what changes across `execve` while PID may stay the same.
Name two things that live only in the process, not in the program file.

CoW (copy-on-write) after fork lets parent and child share physical frames for read-only text until one writes, then private copies materialize. That is a performance trick, not “the same process.”

Operating systems · Processes

Process vs program

Static file vs live execution context

TL;DR

A program is bits on disk (ELF segments, metadata); a process is those segments mapped into a private virtual address space with CPU state, fds, and kernel linkage, multiple processes can run the same program file concurrently.

Summary

Interviewers use this question to see if you confuse files with runtime state. Emphasize mapping, per-process tables, and the fact that scheduling and signals attach to tasks, not to inode numbers.

Deeper narrative

The program is static artifacts on disk (ELF segments, metadata); the process is dynamic execution state including brk/mmap arenas, stack, registers, and kernel bookkeeping. Multiple processes can map the same binary read-only with shared text pages.

Mechanism (step by step)

Treat each step as a sentence in the story you tell on a whiteboard.

Loader maps ELF

Interpreter or direct map PT_LOAD segments; dynamic linker resolves PLT/GOT.

Kernel creates task

Allocates mm, fd table, sets credentials from parent or file capabilities.

Execution advances PC

Instructions mutate registers and memory; program counter alone is not the whole story.

Persistence vs volatility

Program bytes on disk survive reboot; process RAM does not unless checkpointed.

Key insights

Each card is a compression of the lesson, use them as spaced-repetition prompts.

Many-to-one mapping

Two shells running `/bin/bash` are two processes mapping the same executable file, different heaps, fds, and PIDs.

Dynamic linking

The program file references shared objects; the dynamic loader maps `libc.so` into each process address space separately unless using prelink/huge page tricks.

Scripts need interpreters

A `#!` script’s “program” is the interpreter binary; the script file becomes an argument, process creation still ends in an executable image.

Containers still run programs

Namespaces change the view; cgroups limit resources, but inside, it is still processes + threads.

Did you know?

Trivia with teeth: the kind of fact that changes how you reason about a design.

Text segments of read-only binaries are often shared across processes via the same physical frames (COW until written).

`argv` and environment live in user memory but are set up by the loader/kernel at exec time.

The same inode can be executed while another process deletes the name, Linux keeps the inode until last close (unlink semantics).

Common pitfalls

Where smart people still trip, read slowly.

“Same binary ⇒ same process”

Each exec creates a new address space; shared libraries may dedupe physical frames but remain separate VAs.

Ignoring ASLR

Same program text may load at different virtual addresses per exec for security.

Glossary

ELF

Executable and Linkable Format, common container for binaries and shared objects on Unix.

CoW

Copy-on-write, share physical pages until a writer faults and duplicates.

Address space

Set of virtual addresses a process may reference subject to permissions.

Interview follow-ups

Why can two processes share physical pages for libc text yet remain isolated?
What distinguishes a script process from its interpreter process?
How does `MAP_PRIVATE` affect sharing of file-backed pages?

Callouts

Crisp answer template

“Program = file; process = loaded image + resources + threads; many processes can share one program file.”

Walkthrough & deep dive

Left: practical “how would I use this?” threads. Right: slower, code-leaning explanations, open one panel at a time so the page does not feel like a wall of sameness.

Walkthrough

Whiteboard

Draw one inode on disk fanning out to two processes with separate mm_structs pointing at shared text frames.

Deep dive

ELF segments

`.text` (code), `.rodata`, `.data`, `.bss`, heap (brk/mmap), stack, vDSO, each has permissions the MMU enforces.

Same binary, two PIDs

Terminal

/bin/sleep 100 &
/bin/sleep 100 &
pgrep -a sleep

Self-check

Misses here are cheap; misses in an interview are not. Treat wrong answers as a patch list for tomorrow.

1Two processes running the same binary typically…

2Which uniquely identifies a running instance?

3The loader primarily…