How your OS runs an app
Launch an editor. Open a note. Make the edit last.
The models could not load. Keep this page beside the assets folder; the written explanations still work.
Launch the editor.
The OS creates a process and its resources. No real program is launched.
Each process gets its own virtual address-space view.
Another ready task can use the CPU while storage works.
A program becomes a process.
The kernel creates resources and virtual mappings. A needed code page is loaded, and the scheduler gives the editor a CPU turn. Ordinary instructions then execute directly on the CPU.
The kernel coordinates and checks privileged work; it does not interpret every application instruction.
What crosses the user/kernel boundary?
File access uses a checked system-call entry point. The kernel validates arguments and permissions, then returns a result. Calculating 2 + 2 normally stays in user mode. A library function need not make a system call; changing privilege mode need not switch processes.
“Administrator” is a user identity with permissions. “Kernel mode” is a CPU execution privilege—not the same thing. The wider OS also includes services and interfaces beyond its kernel.
How do threads share CPU time?
A process owns resources; its threads share them. Runnable threads can wait for CPU time, run, or block for an event. This separate round-robin close-up has one thread per process and nine CPU ticks of work. Its toy ticks do not set the editor story’s timing.
When the editor waits for storage, another ready task can run.
Concurrency means making progress on several tasks; parallelism means executing simultaneously. This example uses zero switching cost, one-tick turns, and an independently progressing I/O device. Real schedulers use richer policies.
Ask for a file—not a disk address.
The editor asks to open /notes/todo.txt. Directories resolve its name, the kernel checks access, and a descriptor refers to the file object. Opening it does not yet read the document’s bytes.
Open → descriptor 3 → the same object
After opening, renaming the file changes its name—not the object referenced by the descriptor.
Permission denial is an error the editor can handle, not an automatic process crash.
Where are filenames, metadata, and bytes?
Directories associate names with objects. Inodes hold metadata and allocation information; data blocks hold bytes. A block device knows addresses, not filenames. Later reads and writes normally use a descriptor and offset rather than resolving the name every time.
The rename stays within one filesystem and does not change file contents or inode 42. This shows identity, not rename crash-durability. Network, memory-backed, and synthetic filesystems need not use local disk at all.
Cached bytes—or a trip to storage.
A cache miss goes through a driver to the device. The editor blocks while I/O runs. Completion makes it ready; a later CPU turn lets the read return.
This changes the document read. The executable still starts with one cold code-page read.
Waiting for storage does not require the editor to keep a CPU busy.
What do the driver and interrupt do?
The driver turns the read into device-specific work. This blocking reader sleeps. A device completion interrupt leads to OS handling that makes the thread ready—not automatically running. The scheduler chooses when it next gets CPU time.
Cache hits can bypass the storage request. System calls and interrupts are different events. Real systems also use asynchronous APIs, queues, polling, DMA, and deferred completion work. Not every interrupt is an I/O completion.
Change your copy, not the stored file.
The editor adds “+ bread” in its own document buffer. The OS’s cached file and persistent version still say “Buy milk”. Neither typing nor allocating memory automatically writes the file.
This forces an extra executable-page read. The document and its stored bytes are unchanged by that reclamation.
A page fault is an access for the OS to handle—not necessarily a disk read or a crash.
How does a virtual address find RAM?
This independent inspector uses toy 16-byte pages. It explains address translation without changing the editor’s mappings or document. Two processes can use the same virtual address for different physical frames, or deliberately share a frame.
Page plus offset maps to frame plus offset. Shared pages can have read-only access.
First use may allocate a zero-filled page without reading storage. A storage-backed page may need a read; unmapped or disallowed accesses are rejected. This inspector explains faults but does not resolve them. Stacks and heaps both live in virtual address spaces; every allocation need not cause a system call or a fresh physical page.
Inspect clean-page reclamation
A separate cold, clean file-page trace: A → B → C → A → D → B → E → A. Exact LRU is a teaching policy, not a claim about a real OS. This example’s counts do not add to the editor story’s read counter.
0 storage reads · 0 hits
Initially empty frames.
Clean file pages can be reclaimed and reloaded. Dirty file pages require writeback before their changes can be discarded. Anonymous memory may use swap, if configured. If reclamation is insufficient, allocations can fail or a process may be terminated. Virtual memory exists even without swap.
Written is not yet durable.
Play this stage or use Next event. A buffered write reaches the OS cache; writeback reaches the device cache; successful synchronization makes this existing file version durable.
An app crash leaves the OS alive. Power loss removes volatile copies.
What does “durable” promise here?
This Linux-inspired model updates an existing file. It assumes successful fsync and a storage stack that honors its flush contract. Tiny whole-file versions change atomically for teaching; real interrupted writes may be partial. No further writeback happens between our what-if failure and inspection.
New or renamed files may also need directory synchronization. Our rename demonstrates file identity, not durability of the directory change. Closing a file does not inherently synchronize it. No promise covers arbitrary hardware failure.
Does journaling save the latest edit?
Not by itself. Journaling helps recover consistent filesystem structures; metadata journaling need not journal contents. A consistent filesystem can still have lost application data. Copy-on-write is another design, not a universal atomic transaction across files.
Stage 1 of 5 · Launch.