How Computer Programs Run

When you launch a program, the operating system does much more than "open a file and start running lines". It creates a process, builds an execution environment, maps code and data into virtual memory, and hands control to machine instructions that interact with the kernel whenever they need privileged work.

1. The OS creates a process

Clicking an icon, running a command, or tapping an app eventually asks the operating system to create a new process. A process is more than the executable file on disk. It is a running instance with its own virtual address space, file descriptors or handles, environment variables, security context, and one or more threads.

On Unix-like systems this often involves fork and exec or a close variant. On Windows the API surface differs, but the core outcome is similar: a new execution context is created from an executable image.

2. The loader maps the executable into memory

The executable file itself is usually in a format such as ELF, PE, or Mach-O. The OS loader reads the file headers to learn which parts are code, which are read-only data, which are writable data, and where the program expects them in virtual memory.

Crucially, the loader often maps pages from the file rather than copying the entire program into RAM up front. Demand paging means code and data are brought into physical memory as pages are actually touched.

3. Shared libraries and runtime glue are prepared

Most programs depend on shared libraries. The dynamic linker resolves those dependencies, maps the required libraries, and applies relocations so symbol references point to the right addresses. If the program is written in a managed language, a runtime such as the JVM or .NET CLR may then initialise its own world on top: garbage collector, class loader, JIT compiler, and so on.

Even native C and C++ binaries do not jump straight from disk to main. Startup code sets up the stack, thread-local storage, environment pointers, and runtime bookkeeping first.

4. The CPU begins executing instructions

Eventually control reaches the program's entry sequence and then the developer-facing entry point such as main. From there the CPU performs the classic fetch-decode-execute loop on machine instructions stored in memory. Registers hold immediate working state, caches reduce memory latency, and the program counter advances through the instruction stream.

A key detail is that the CPU does not understand "open file" or "create socket" as ordinary user-space instructions. For privileged operations, the program makes a system call into the kernel.

5. The kernel provides services and schedules time

The kernel handles file I/O, networking, memory management, process isolation, timers, and hardware access. If the program blocks on disk or network input, the scheduler may run another thread in the meantime. On multicore systems, several threads from several processes may execute in parallel.

This is why a running program is never just "its own code". It is constantly interacting with the operating system, libraries, and hardware caches beneath it.

6. Termination and cleanup

When the program exits normally, it closes files, flushes buffers, releases locks, and returns an exit status. If it crashes, the operating system still reclaims the process's memory and kernel resources. Some higher-level cleanup may be skipped, which is why crashes can leave partial files, broken transactions, or missing telemetry.

So the short answer is: a computer program runs because the operating system turns a file on disk into a managed process in memory, then the CPU executes its instructions while the kernel supplies the privileged services the program cannot perform alone.