Operating Systems.

An operating system sits between your program and the hardware and shares the CPU, memory and devices among every running program. Your code never talks to the disk or network directly. It asks the OS through system calls, and the OS grants access.

The OS has three main jobs. It schedules CPU time, so many programs take turns on limited cores. It gives each program its own view of memory, so a bug in one program cannot overwrite another program's memory. It also manages files, devices and the network behind uniform interfaces.

This design lets your program act as if it has the machine to itself, while dozens of programs share it. Without the OS enforcing those boundaries, a single careless loop could freeze everything or read another program's secrets.

A process is a running instance of a program, with its own memory and resources. Launching the same program twice creates two processes that cannot see each other's memory.

The OS tracks each process in a structure often called a process control block.

• Process ID
• Current registers
• Program counter
• Memory layout
• Open file descriptors
• Parent process
• Scheduling priority
• Current state, such as running, ready or waiting

This bookkeeping is what makes pausing and resuming possible. When the OS switches away, it saves those registers, then restores them later so the process continues where it stopped.

The core difference is memory sharing. A process owns a private address space. Threads live inside one process and share that space, including the heap and global data.

Because threads share memory, they can pass data by reading and writing the same variables. Two processes cannot, so they need pipes, sockets or shared-memory setups. Each thread still gets its own stack and registers, so it can run its own function calls independently.

The tradeoff is safety versus speed. Shared memory makes thread communication fast but risky, since one thread's bad write can corrupt another's data. Separate processes stay isolated, so a crash in one usually leaves the others running. Pick threads for tight cooperation and processes for isolation.

The stack holds local variables and call frames that last until their function returns, while the heap holds memory you allocate and free yourself.

The stack is automatic and fast. Each function call pushes a frame, and returning pops it. The compiler must know each frame's size up front, and the return frees that space at once.

The heap is flexible. You allocate a block, use it as long as you like, then free it yourself.

That flexibility has a cost. Heap allocation is slower, and the heap can fragment over time. Forget to free a block, and you leak memory.

Use the stack for short-lived, fixed-size data, and the heap when the size is unknown or the data must outlive the call.

Virtual memory gives each process a private address space, a range of addresses the OS maps onto physical RAM. Your program sees one continuous range starting near zero, even though physical memory is shared and scattered.

The hardware and OS translate every virtual address to a physical one during access. A process can only reach memory it owns, because its map has no entry for anyone else's pages.

That isolation is the main reason for separate address spaces. One process cannot read or corrupt another's data through a stray pointer. It also simplifies your code, since every program can assume the same layout. And because pages not in use can wait on disk, the machine can run programs whose combined footprint exceeds its RAM.

A system call is a request to the OS kernel to do something your program cannot do alone. Reading a file, opening a socket or asking the OS for more memory all end in system calls.

A normal function call stays inside your program's own code and privileges. A system call crosses the privilege boundary. The CPU switches from user mode into kernel mode, runs trusted kernel code, then switches back with a result.

That crossing is why system calls cost more than normal function calls. The mode switch takes time, and the kernel saves your registers on entry and restores them on return. Libraries often batch or buffer work to make fewer system calls.

User mode and kernel mode are CPU privilege levels, and modern CPUs have at least these two. Kernel mode can touch any hardware and any memory. User mode is restricted, and that is where your application code runs.

Your program cannot directly access devices or other processes' memory while in user mode. When it needs a privileged action, it makes a system call. That call enters kernel code at a fixed entry point and runs it in kernel mode.

The split exists because programs cannot be trusted with full access. If every program ran with full privileges, one bug or one malicious line could crash the machine or steal data. With two modes, the kernel checks each privileged request before carrying it out.