The operating system manages the machine: memory, files, processes, I/O, security, and the user interface — hiding hardware differences from programs.

OS responsibilities: memory management, disc/file management, process management (multitasking & inter-process communication), I/O & communication, hardware homogeneity, a user interface, and security. Unix layers: hardware → device drivers → kernel (process manager, memory manager, scheduler, file system, IPC) → system-call interface → shell/applications. Boot: ROM/UEFI firmware loads the OS. Multitasking : several programs live in memory, each with its own stack and heap. A process record stores status (running/waiting/blocked), stack pointer, heap/access info. The CPU jumps between processes.

A context switch (triggered by a timer interrupt) saves the current process's registers on its stack, saves SP into its process record, moves it to the waiting queue, picks the next process, restores its SP and registers, and does RTI. Because plain x:=x+1 compiles to load-add-store ( non-atomic ), two processes can interleave and lose an update — so semaphores/mutexes (Dijkstra's P/'Passeer' and V/'Vrijgeven') provide mutual exclusion via a queue. OS history: resident monitors → time-sharing → multitasking (IBM 360) → Minix/Linux → modern Windows NT/macOS.

Every modern OS multitasks via timer-driven context switches; race conditions from non-atomic updates are a leading class of concurrency bugs.

Virtual memory lets programs use an address space larger than physical RAM by keeping part of it on disc. The principle of locality says only a small part is in active use at once.

Old approach: overlays (programmer splits the program into parts that load each other — tedious). Modern approach: paging . Divide both the virtual address space and physical memory into fixed-size pages . A page table maps virtual pages to physical frames. The MMU (memory-management unit) does the translation; an address = (page number, offset). If a referenced page is not in RAM, the MMU raises a page fault (TRAP). The handler swaps: store an old page to disc, load the needed page, update the page table, and re-execute the faulting instruction.

Page-table entry bits: present (in RAM? else page fault), written/dirty (changed since load? avoids needless write-back), writeable (may the program modify it? security), executable (may it run as code? security), protection (may it be swapped out?). Writeable/executable must be checked by hardware; the dirty bit is best set by hardware. Access violations (write to read-only, execute non-executable) raise their own traps.

Paging underlies every modern OS; the executable/writeable bits are the W^X protection that blocks many code-injection exploits.

When RAM is full, which page do you evict? And how do you let regions (code, data, stack) grow independently? Answers: replacement policies and segmentation.

Optimal policy: evict the page not used for the longest future time — but that needs clairvoyance, so we approximate: FIFO : evict the oldest-loaded page. Simple; fails on long cyclic programs. LRU : evict the least-recently-used page. Updated on every access; slightly better than FIFO but also fails on large cyclic data. Random . When data is cyclic and bigger than the available frames, every policy thrashes — you simply need more memory.

Segmentation gives several independent address spaces (segments) that can grow/shrink — an address = (segment number, offset). Implemented by swapping whole segments (variable size → external fragmentation) or by paging each segment (address = segment, page, offset; on average half a page wasted internally). Combining segments with paging gives per-object growable spaces with manageable fragmentation. The MMU/System-MMU maps all of this to physical memory.

x86 historically combined segmentation and paging; today flat paging dominates, but the segment idea survives in thread-local storage and memory protection.