Kinds of Programs and How They Run

In this chapter

We'll look at the kinds of programs — command-line apps, GUI apps and background services (daemons) — and follow what happens when a program starts, runs and ends, including exit codes.

12–14 min

The Problem in Real Life

BlueTicket is running on Anna's laptop. The terminal window just sits there, printing a new line every time she clicks something in the browser. When she presses Ctrl+C, it prints "Shutting down..." and stops.

Meanwhile, other things on her laptop run all the time without any window at all — the Wi-Fi, the antivirus, the clock syncing itself. "Some programs have windows, some live in the terminal, and some are invisible," she says. "Are they all the same kind of thing?"

Where does a program actually go while it's running?

Anna

"Opening an App" vs. What the Computer Actually Does

Programs look different

Some have windows, some only text, some nothing at all — but they all run the same way underneath.

Every program has a life cycle

It starts, runs, and ends — and the way it ends tells you whether it worked.

Programs come in three main shapes, depending on how people (or other programs) use them:

CLI application (Command-Line Interface) — you use it by typing commands in a terminal, and it answers with text. Examples: git, npm, node. CLI tools are fast, easy to automate in scripts, and work on servers that have no screen.
GUI application (Graphical User Interface) — you use it with windows, buttons and a mouse or touch. Examples: a browser, VS Code, Spotify. Easier for most people, but harder to automate.
Background service — runs without any window, usually starting when the computer starts and running until it shuts down. It waits for work and does it quietly. On Windows these are called services; on Linux and Mac they're called daemons (often named with a "d" at the end, like sshd, the program that accepts remote logins). BlueTicket's web server and its reminder-email sender are background services on its servers.

Table — CLI vs. GUI vs. background service

Feature	CLI app	GUI app	Background service
How you use it	Type commands	Click and tap	You don't — it works by itself
Has a window?	Terminal only	Yes	No
Easy to automate?	Very	Hard	Runs automatically
Examples	git, npm, node	Chrome, VS Code	sshd, Windows Update, a web server

Table — Exit codes in practice

Exit code	Meaning	Example
0	Success	npm test — all tests passed
1	General error	npm test — a test failed
127	Command not found (in many shells)	Typing a program that isn't installed
130	Stopped with Ctrl+C (in many shells)	Anna stopping the dev server

The life of a program

Executable on disk

a file, not doing anything

start (click, command, boot)

OS loads it into RAM

creates a process, gives it memory

run

Runs from the entry point

CPU executes; system calls for files, network, screen

end

Finishes

exit code 0

Crashes

non-zero exit code

Is stopped

Ctrl+C or a stop signal

OS cleans up

memory and resources are freed

In a terminal, the special variable $? holds the exit code of the last command (on Mac and Linux; PowerShell uses $LASTEXITCODE).

Checking a program's exit code

npm test
echo $?        # 0 means every test passed

node --versionn   # a typo
echo $?        # not 0 — the command failed

Build tools and deployment pipelines use exactly this number to decide whether to continue or stop.

Underneath, every kind of program runs in the same way. Here is the life of a program:

1. Start: Someone (or something) asks the operating system to run a program — by double-clicking, typing a command, or at boot. The operating system finds the executable, loads its code into RAM, gives it memory and other resources, and creates a process: a running copy of a program. (A program is the file on disk; a process is that program while it runs. One program can run as many processes — think of two browser windows. Act 05 goes deeper.)

2. Run: The CPU executes the program's instructions, starting at its entry point — the first instruction to run, often a function called main. Whenever the program needs something outside itself — read a file, send data over the network, show something on screen — it asks the operating system through a system call. For a script like BlueTicket's app, the process being started is the runtime (node), which then loads and runs the JavaScript files.

3. End: A program ends in one of three ways. It finishes its work normally. It crashes because of an error it can't handle. Or it is stopped from outside — like when Anna pressed Ctrl+C, which sends the program a signal asking it to stop. Background services usually never finish on their own; they run until they're stopped.

When a program ends, it returns a small number called an exit code. 0 means success; any other number means something went wrong. Other programs and scripts check this number to decide what to do next — for example, a build pipeline (Act 19) stops if the tests exit with 1. After the process ends, the operating system takes back its memory and resources.

Key Takeaway

Programs can be CLI tools, GUI apps or background services (daemons), but they all run the same way: the operating system loads them into memory as a process, the CPU runs them from their entry point, they use system calls to reach the outside world, and they end with an exit code — 0 for success.

Why This Matters

Almost everything BlueTicket runs in production is a background service, managed without anyone watching. Understanding how processes start, how they report success or failure, and how they're stopped is the base for running servers (Act 19), automating deployments with exit codes, and finding out why a service died at 3 AM (exactly what happens to Anna in Act 10).

In one week, Anna went from node: command not found to understanding the whole journey of BlueTicket's code — from source, through a build and a runtime, to a running process. Time to prove she can explain that journey from start to finish.