When you double-click an application or run a command such as:

it may appear that the program starts immediately.

Behind the scenes, however, the operating system performs several steps before the program can execute. It locates the program, creates a process, prepares memory, loads the required code, and gives the process time on the CPU.

This chapter explains that journey at a high level.

A program is a file containing instructions and data.

It is passive. A program stored on disk is not currently doing anything.

A process is a running instance of that program.

For example, Google Chrome may be installed once on your computer, but opening multiple Chrome windows can create several processes.

This distinction is important:

One file on disk can be started repeatedly, and each start produces a separate process with its own memory and its own process ID.

A program is the executable code. A process is that code being executed with memory, CPU state, and other resources assigned to it.

At a high level, running a program involves the following stages:

The first five stages are setup work done by the operating system before a single line of your code runs. The last three are the program's actual lifetime. Let us walk through each stage.

A program can be started in several ways.

You might enter a command in a terminal:

You might double-click an application icon, launch a service, or start a program from another program.

In each case, some existing program makes a request to the operating system.

In a terminal, that existing program is usually the shell. Examples include Bash, Zsh, and PowerShell.

The shell reads the command and determines which program should be started.

For example:

The shell must find the executable associated with git.

If you provide an explicit path such as:

the location is already known.

Otherwise, the shell searches through a configured list of directories until it finds a matching executable.

After locating the program, the operating system creates a new process to run it.

The operating system assigns the process an identifier, commonly called a process ID or PID.

It also creates internal information needed to manage the process, including its current state, security permissions, memory information, and open resources.

The exact mechanism depends on the operating system.

On Unix-like systems, a shell commonly creates a child process and then replaces the child’s current program with the requested program. On Windows, process creation is usually performed through a single process-creation operation.

The implementation differs, but the result is similar: the operating system creates an execution environment for the new program.

Before running the program, the operating system examines its executable file.

An executable is not simply a raw sequence of instructions. It contains structured information describing how the program should be loaded.

This information can include:

For example, executables on Linux commonly use the ELF format, while Windows programs commonly use the PE format.

The operating system verifies that the executable is valid and compatible with the machine.

A program compiled for a different processor architecture may not run unless an emulator or compatibility layer is available.

Every running process needs memory.

The operating system prepares an address space for the process and organizes it into logical regions.

A simplified process memory layout looks like this, with the highest addresses at the top:

The regions are stacked rather than connected, because this is a map of an address range, not a sequence of steps. The free space in the middle matters: the stack grows downward into it and the heap grows upward, so both can expand without a fixed size decided in advance.

The code region contains the program’s machine instructions.

The data region stores global and static variables.

The heap is used for memory allocated while the program is running.

The stack stores function-call information, local variables, and temporary execution data.

At this stage, it is enough to understand that the operating system gives each process an organized memory environment. The details of virtual memory and memory allocation will be covered later.

The operating system makes the program’s instructions available in memory.

This does not always mean that the entire executable is copied into physical memory immediately. Modern operating systems often load parts of a program only when they are first needed.

Many programs also depend on shared libraries.

For example, a C program may depend on a standard library that provides functions such as printf, while a graphical application may depend on libraries for windows, fonts, and user input.

Instead of including a separate copy of every library inside every program, applications can refer to shared libraries installed on the system.

A component called the dynamic linker or loader helps locate these libraries and connect the program’s references to the correct library code.

The detailed linking process will be covered separately. For now, the key idea is that the program’s own code may not be enough. Its required libraries must also be prepared before execution can continue normally.

Many programs execute inside a language runtime.

A Java program runs inside the Java Virtual Machine. A Python program runs through the Python interpreter. JavaScript may run inside Node.js or a browser engine.

These runtimes perform additional setup before the application’s own logic begins.

For example, they may initialize memory management, load modules, create background threads, parse configuration, or prepare garbage collection.

Even a native C or C++ program usually performs some startup work before its main function is called.

The actual flow is closer to:

The middle step is code you did not write and usually never see. For a Java service it loads the virtual machine and its classes, and for a C program it is smaller but still present.

This is why main is usually not the first instruction executed by the process. It is the application-level entry point after the required startup code has finished.

Once the process is prepared, it becomes eligible to execute.

However, the CPU may already be busy running other processes.

The operating system’s scheduler decides when the new process receives CPU time. When selected, the CPU begins executing the program’s instructions from its entry point.

The process may run for a short time, pause, and continue later.

These switches happen quickly, allowing many programs to make progress even when the computer has fewer CPU cores than active processes.

The exact scheduling process will be explored in a dedicated chapter.

Once the application starts running, it can perform normal computations directly on the CPU.

For example, it can add numbers, compare values, call functions, and manipulate data already available in its memory.

However, some operations require help from the operating system.

A program needs the operating system when it wants to perform actions such as reading a file, sending data over a network, displaying output, creating another process, or requesting additional memory.

The application makes a controlled request to the operating system, commonly through a system call.

Consider this simple program:

The printf function formats the text in user space. Eventually, the runtime asks the operating system to write the output to the terminal.

The simplified flow is:

The first two steps run inside your process, where the program is free to do as it likes. The system call is the point where control moves to the kernel, and everything after it happens on the operating system's terms.

System calls will be covered in detail later. For now, remember that programs use them whenever they need privileged operating-system services.

A process continues running until it finishes or is stopped.

It may terminate because it completed successfully, encountered an error, crashed, or was stopped by another process or the user.

When the program ends, it usually returns an exit status.

By convention, an exit status of 0 often indicates success, while a non-zero value indicates an error or another outcome.

After termination, the operating system cleans up the resources used by the process. It releases its memory, closes remaining open resources, and records its completion status.

The parent process can then inspect that status.

For example, in many shells you can view the previous command’s exit status using:

Not every program is started in exactly the same way.

A compiled native program can often be executed directly:

A script is commonly passed to an interpreter:

In the second example, the operating system directly starts the Python interpreter. The interpreter then reads and executes the contents of app.py.

The difference can be summarized as follows:

Java follows another variation:

The operating system starts the Java Virtual Machine, and the JVM loads and executes Java bytecode.

Although the execution model differs, all of these eventually become operating-system processes.

Suppose you run:

The shell first locates the java executable.

The operating system creates a new process and prepares memory for it. The Java Virtual Machine and its required libraries are loaded.

The JVM initializes its runtime, loads the classes inside server.jar, and eventually invokes the application’s entry point.

The backend application may then open a network socket, start worker threads, read configuration files, and begin accepting requests.

From the operating system’s perspective, the Java application is a process using CPU time, memory, files, threads, and network resources.

Run a long-lived command:

Open another terminal and search for the process:

You should see the running sleep process and its process ID.

You can stop it before the 60 seconds complete using:

This small exercise demonstrates the complete lifecycle: a program is located, turned into a process, assigned a process ID, executed, and eventually terminated.

When you run a program, the operating system locates its executable, creates a process, prepares its memory, loads the required code and libraries, and schedules it for execution.

The program then performs calculations directly and asks the operating system for services such as file access, networking, and additional memory.

When the program finishes, the operating system records its exit status and releases its resources.

The most important idea is:

Running a program means transforming passive code stored on disk into an active process managed by the operating system.