An operating system stands between your program and the raw hardware. Your code never talks to the disk or network directly. It asks the OS, which grants access through system calls.

Three jobs dominate. The OS schedules CPU time, so many programs take turns on limited cores. It hands each program its own memory view, so one bug cannot scribble on another. It manages files, devices, and network behind uniform interfaces.

This design lets your program pretend it owns the machine. In reality dozens of programs share one box. Without the OS enforcing boundaries, a single careless loop could freeze everything or read another program's secrets. That isolation and sharing is the whole point.

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. It records the process ID, current registers, the program counter, and memory layout. It also holds open file descriptors, the parent process, scheduling priority, and current state like 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 exactly where it stopped. The tracked state is the process's whole identity to the kernel.

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 just reading the same variables. Two processes cannot; 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. Separate processes stay isolated, so a crash in one usually leaves the others standing. Pick threads for tight cooperation, processes for isolation.

Both hold your program's data, but they behave very differently. The stack stores local variables and function call frames. The heap stores memory you request explicitly and control by hand.

The stack is automatic and fast. Each function call pushes a frame; returning pops it. Sizes must be known up front, and the space is freed the instant the function returns. The heap is flexible. You allocate a block, use it as long as you like, then free it yourself.

That flexibility carries a cost. Heap allocation is slower and can fragment over time. Forget to free, and you leak memory. Use the stack for short-lived, fixed-size data, and the heap when size or lifetime outlives one function call.

Virtual memory gives each process a private set of addresses that the OS maps to real physical RAM. Your program sees a clean, 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 simply has no entry for anyone else's pages.

That isolation is the main payoff. 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 familiar layout. And it lets the machine run programs whose combined footprint exceeds the RAM actually installed.

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 allocating memory all end in system calls.

A normal function call stays inside your program's own code and privileges. A system call crosses a hard 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 plain calls. There is mode-switching overhead and saved state on each side. Libraries often batch or buffer work to make fewer of them. So treat system calls as the expensive doorway between your code and the machine's protected parts.

Modern CPUs run in at least two privilege levels. Kernel mode can touch any hardware and any memory. User mode is restricted, and that is where your application code lives.

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, which safely transfers control to kernel code running in kernel mode.

We need both because trust is not free. If every program ran with full privileges, one bug or one malicious line could crash the machine or steal data. The two-mode split lets the kernel police every dangerous action. User code stays sandboxed, and the kernel stays the single gatekeeper.