Native Executables Need Loader and Process Context

Learning Question

Why does a native executable still need a loader and process context?

A native executable is closer to running behavior than source code, but it is still a stored file. It must be loaded into a process context before its instructions can execute as one running instance.

Running a native executable usually starts with a command:

.\app.exe

That command does not make the file act by itself. The shell asks the operating system to start a program. The operating system checks the executable format, creates a process, maps needed parts of the executable into memory, prepares process state, and transfers control to startup code.

What the Loader Contributes

The executable file contains instructions and metadata. It does not by itself contain a live address space, open handles, command-line arguments, environment variables, stack, thread, or process identity.

The loader and operating system provide the missing runtime context:

• a process identity
• a virtual address space
• mapped executable code and data
• dynamic libraries when needed
• an initial thread
• a stack
• command-line arguments
• environment variables
• open standard streams or handles
• an entry point where execution can begin

The exact details vary by platform, but the boundary is stable:

native executable file != running process

Why Native Does Not Mean Self-Running

“Native” means the executable is meant for a machine and operating-system environment rather than for a managed language runtime such as the JVM.

It does not mean the file can run without support.

The operating system still controls process creation, memory mapping, permissions, resources, scheduling, and interaction with devices. The CPU executes instructions only after the process exists and control reaches code mapped into that process.

Native execution removes one kind of language runtime layer. It does not remove the operating system boundary.

What This Chapter Leaves to the OS Collection

This chapter does not explain executable formats, dynamic linking, virtual memory internals, system calls, scheduling, permissions, or process tables in detail.

Those topics belong in How Operating Systems Support Running Programs.

The point here is only the transition:

native executable artifact
OS loader and process creation
running process

Mental Model

When you see a native executable, do not stop at “this can run.”

Ask:

Which operating system can load this?
What process context must be created?
Where is the entry point?
What resources does the process receive at startup?

A native executable is a loadable artifact. A process is the live runtime container created from it.