What Changes When a Program Is Loaded and Running?

Learning Question

What changes when a program is loaded and running?

hello.py can be discussed in three useful states:

stored
loaded
running

These are not always cleanly separated in every system, but the distinction prevents one common confusion: a program can be available without currently doing anything.

Stored

When hello.py is stored, it is passive.

It has a path, bytes, text, and metadata. It can be inspected by an editor or versioned by Git. It can sit on disk for months without producing output.

At this point, there is no Python stack frame for this file, no active print call, and no terminal output caused by it. The file describes possible behavior, but no run is happening.

Stored evidence looks like this:

file exists
contents can be read
timestamp and permissions exist
no process is required

Loaded

When you run:

python hello.py

the source file becomes input to an execution context.

The operating system has started a Python process. The interpreter has received the file path. The interpreter reads the source and prepares internal runtime material from it.

Different runtimes expose this phase differently. Python may compile source into internal code objects before executing them. Java loads class data into a JVM. A native executable has loadable segments mapped into a process address space.

The shared idea is narrower than any one implementation:

loaded means the representation is now connected to an execution context

Loaded evidence might include:

• a process exists
• the runtime has opened or read the file
• modules, code objects, classes, or executable segments are available to the runtime
• runtime structures now refer to the program material

The file is no longer merely a file being inspected by a text editor. It is now material being prepared for execution.

Running

Running means behavior is unfolding through runtime state.

For hello.py, the interpreter executes the top-level statement:

print("hello")

That execution creates a call to print, sends data to standard output, and returns control. The process then exits with an exit status.

For a short script, the running phase can be so brief that it is easy to miss. For a server, a GUI app, or a program waiting for input, the running phase can last much longer.

Running evidence looks like this:

control flow is active or waiting
memory and runtime state exist
I/O resources may be open
output, errors, or side effects can occur
the run can finish, fail, block, or be interrupted

Why Loaded and Running Are Not Always the Same

Some code can be loaded before it executes. A module can be imported and define functions that are not called yet. A class can be loaded before a particular method runs. A program can be waiting on input while its process still exists.

So “loaded” means the execution environment has made representation available. “Running” means behavior is actually unfolding, or the runtime instance is alive and able to continue behavior.

For quick scripts, those states are close together. For larger systems, they separate more clearly.

The Durable Model

Use this model when the word “program” becomes blurry:

stored: represented somewhere
loaded: connected to an execution context
running: live state and behavior exist over time

The same stored program can support many runs. Two terminal windows can run the same hello.py at the same time. The file is shared, but the processes and runtime state are separate.