When a user initiates a software application, they are effectively triggering a complex orchestration of hardware and operating system protocols designed to transform inert code into a living, executing entity. This process, often taken for granted as a momentary delay between a double-click and a window appearing, involves a rigorous series of translations, allocations, and synchronizations.

The Wake-Up Call: System Interruption

The journey begins while the program is still a static file residing on the secondary storage device, such as a hard drive or solid-state drive. At this stage, the program is merely a sequence of bytes, organized in a specific format like the Portable Executable (PE) on Windows or the Executable and Linkable Format (ELF) on Unix systems. When the command to execute is issued, the operating system’s graphical interface or command shell sends a request to the kernel. This is typically achieved through a system call, such as execve on Linux or CreateProcess on Windows. This system call signals the kernel that a new process needs to be instantiated.

The Loader and Memory Mapping

Upon receiving the system call, the operating system invokes the program loader. The loader reads the header of the executable file to understand its structure, size, and requirements. However, the operating system does not simply copy the entire program into physical RAM immediately. Instead, it sets up a virtual memory address space for the new process. This is an abstraction layer that fools the program into believing it has access to a contiguous block of memory, while in reality, the data may be scattered across physical RAM or even temporarily swapped out to the disk.

The loader maps the various sections of the executable into this virtual space. The “text segment” contains the read-only machine code instructions, while the “data segment” holds global and static variables. The OS also establishes the “stack,” which is crucial for managing function calls and local variables, and the “heap,” which is reserved for dynamic memory allocation requested during runtime

.

Dynamic Linking and Resolution

Modern programs rarely function in isolation; they rely on external libraries to perform standard tasks like drawing graphics or accessing the network. Before the program can truly run, the dynamic linker steps in. It examines the program’s dependencies and locates the necessary shared libraries (files ending in .dll or .so). The linker maps these libraries into the process’s address space and resolves undefined symbols, effectively connecting the program’s internal wires to the operating system’s existing infrastructure. This allows multiple running programs to share the same physical copy of a library in memory, optimizing resource usage.

The Process Control Block

Simultaneously, the kernel creates a data structure known as the Process Control Block (PCB). This serves as the administrative record for the program. It contains critical metadata, including the unique Process ID (PID), the current state of the process (ready, running, or waiting), process priority levels, and the values of the CPU registers. The PCB ensures that if the operating system needs to pause this program to let another one run, it can save the exact state of execution and resume it later without data loss—a mechanism known as context switching.

The Fetch-Decode-Execute Cycle

Once the memory is mapped and the administrative structures are in place, the scheduler places the process in the “ready” queue. When the CPU becomes available, the context switch occurs. The CPU’s Instruction Pointer (or Program Counter) is updated to point to the entry point of the program’s code in memory.

At this precise moment, the hardware takes over. The CPU begins the relentless fetch-decode-execute cycle. It fetches the binary instruction from the memory address indicated by the Instruction Pointer. It decodes this binary pattern to understand the command—whether it is to add two numbers, move data between registers, or jump to a different part of the code. Finally, it executes the instruction. This cycle repeats billions of times per second.

Runtime interaction and Termination

As the program runs, it inevitably requires interaction with the outside world. It may need to read a file, capture a keystroke, or display a pixel. Since the program runs in “user mode” with restricted privileges, it cannot touch hardware directly. It must pause and issue a system call to the kernel. The CPU switches to “kernel mode,” performs the hardware operation, and then returns control to the program. This back-and-forth negotiation continues until the user closes the application. At that point, the operating system reclaims the memory, destroys the Process Control Block, and the code returns to being a silent, static file on the disk.