Data, memory, and execution

A photo editor seems to turn a picture into a finished result. Underneath, instructions and data move through several different places. Understanding those places explains both everyday failures and why running software needs carefully limited permissions.

A program is a recipe; a process is work in progress

A program is stored instructions plus supporting resources. Starting it creates or uses a process: an operating-system container for execution state, memory mappings, and references to resources. A thread is a sequence of execution inside that process. Several threads can work within one process, and several processes can run the same program.

The recipe analogy is useful because two cooks can follow one recipe independently. Its limit is that computer processes can deliberately share memory and other resources. Separate processes do not imply absolute isolation from every form of communication.

Working bytes are not the saved file

In our fictional editor, opening holiday.png reads encoded image data. The editor interprets those bytes, creates a representation it can work with, and draws pixels on screen. Cropping changes that working state. Saving asks the operating system to write a chosen representation to storage. A crash before a successful save may lose the work without changing the original file.

RAM is the physical memory hardware used for active work. A process normally deals with virtual addresses, which the operating system and processor translate through mappings. A virtual address is therefore not simply a label on one permanently assigned RAM chip. Some mappings refer to files, some are private, and some pages may temporarily be absent from RAM.

PredictThe editor and music player both refer to virtual address 1000 in a simplified model. Must they see the same data?

No. Each process can map that address to different storage. They share bytes only when the relevant mappings and permissions arrange sharing. The small address is fictional; the important idea is the address-space context.

Instructions still need authority

The editor asks the operating system to open files or create network connections. Those requests run within a security context: identities, groups, privileges, and restrictions. The person signed into an online photo account is an application identity; it need not be the same identity that controls local file access.

An opened file can be represented by a handle or file descriptor. Later operations use that reference subject to platform rules. Changing permissions on a pathname does not universally invalidate existing references. This distinction matters when reasoning about revocation: removing future access and ending current access can be separate tasks.

A useful failure story

If saving fails, separate the possibilities: an application error, insufficient storage, a permission decision, or an interrupted write. “The computer broke” hides the mechanism. A careful explanation names the operation, the resource, and which component reported failure. That habit will make later lessons about least privilege and memory safety much easier to follow.