What Is an Operating System?
An operating system sits between hardware and applications, managing resources so programs don't have to. This guide explains what an OS does, its architecture, and why it matters.
What Is an Operating System?
Every time you tap an icon on your phone, run a program on your laptop, or even boot up a server in the cloud, you’re relying on a piece of software that most people never think about: the operating system. The OS is the unsung infrastructure that makes everything else possible. Without it, every program would need to know exactly how to talk to your processor, manage your memory, and read from your disk. That’s an unthinkable amount of duplicate work, and it would mean every application would break the moment you swapped out a hardware component.
An operating system solves this problem by sitting between the hardware and the applications. It presents a clean, consistent abstraction to every program, so a web browser doesn’t need to know whether it’s running on a ThinkPad or a MacBook. It handles the messy reality of real hardware underneath while giving everything above it a stable, predictable interface to build on.
Here’s what an operating system actually does, how it’s structured, and the different flavors you’re likely to encounter.
The OS as an Abstraction Layer
An operating system, at its most basic, is an abstraction provider. Hardware is physical, finicky, and full of quirks. The OS hides all of that complexity behind clean abstractions.
Consider what happens when a program wants to save a file. The program doesn’t send raw commands to the hard drive asking “please write these bytes to cylinder 5, head 3, sector 7.” It calls something like open() and write() — functions that ask for a named file to be created and filled with data. The OS translates those requests into whatever operations the specific hardware on this machine actually requires, whether that’s an NVMe SSD, a magnetic spinning disk, or even network-attached storage. If you swap out the disk tomorrow for a completely different type, the program still works because the OS adapts.
This abstraction extends to everything: memory management, process scheduling, network communication, device input. Programs don’t manage hardware directly. They ask the OS, and the OS figures out how to make it happen.
Kernel vs. User Space
One of the most important distinctions in operating system design is the line between kernel space and user space.
The kernel is the heart of the operating system. It runs in privileged mode with direct hardware access, full memory control, and the ability to execute special CPU instructions that regular programs can’t touch.
Everything else — your web browser, your text editor, your music player — runs in user space. These are normal programs with normal privileges. They can’t touch hardware directly. They can’t read kernel memory. If they misbehave, the kernel can kill them without bringing down the entire system.
This separation is a fundamental security boundary. User programs make requests to the kernel through a well-defined interface, and the kernel decides whether to fulfill those requests and how. A bug in your browser can’t corrupt the kernel’s internal data structures because the kernel sits in a completely different privilege level.
+------------------+
| User Space |
| |
| [ Browser ] |
| [ Editor ] |
| [ Games ] |
+------------------+
|
| system calls
v
+------------------+
| Kernel Space |
| |
| [ Process Mgmt ]|
| [ Memory Mgmt ] |
| [ File System ]|
| [ Drivers ] |
+------------------+
|
v
+------------------+
| Hardware |
| CPU | RAM | Disk|
+------------------+This two-world model shows up everywhere: Linux, Windows, macOS, most general-purpose OSes.
System Call Interface
So how exactly does a user program talk to the kernel? Through the system call interface — the defined boundary where user space asks kernel space for services.
A system call is a special kind of function call. In C on Linux, you might call write() to output data to a file or terminal. write() is a library function that wraps the actual system call instruction. Under the hood, the library places the system call number and arguments into specific CPU registers, then triggers a software interrupt or a special syscall instruction that transfers control to the kernel.
The kernel then:
- Examines the system call number to determine what operation is requested
- Validates the arguments (to prevent malicious programs from passing invalid pointers into kernel memory)
- Performs the operation (which might involve talking to hardware, modifying kernel data structures, or both)
- Returns a result code to the caller
The kernel acts as a referee here. It makes sure no user program can break the system. If a program passes a NULL pointer as a file descriptor to write(), the kernel catches it and returns an error instead of crashing.
Common system calls you’ll see in practice include open(), read(), write(), close() for file operations, fork() and exec() for creating processes, socket() and connect() for networking, and mmap() for memory mapping files.
Shell and User Interfaces
Most people interact with an operating system through a shell or a graphical user interface. Neither of these is technically part of the kernel, but both are fundamental to how we use computers.
A shell is a command-line interpreter. You type a command, the shell parses it, and then calls the appropriate programs or system calls to fulfill your request. Bash, Zsh, and PowerShell are all shells. When you run ls to list files or grep to search text, you’re using a shell to bridge your typed commands and the kernel’s system calls.
Shells are also programming languages in their own right. You can write loops, conditionals, and functions in a shell script, calling system utilities and orchestrating complex workflows. This makes them powerful tools for automation and system administration.
On Linux, you have desktop environments like GNOME and KDE. On Windows, it’s the Explorer shell and the Start menu. On macOS, it’s Finder and the Dock. Underneath all of these graphical environments, the kernel and the system call interface stay the same — they just add a graphical layer on top.
What matters is that neither the shell nor the GUI is the operating system itself. They’re user-space programs that make system calls to get things done. You could run a Linux server with no GUI at all, SSH in, and do everything through a shell. Or you could replace GNOME with KDE on the same Linux system without changing anything about how the kernel works.
OS as Resource Manager
Beyond providing abstractions, the operating system is a resource manager. The hardware on any computer is finite: there’s a limited number of CPU cores, a fixed amount of RAM, and disks that can only read and write so fast. Multiple programs want to use these resources simultaneously, and they often compete for them.
The OS resolves these conflicts. When you open ten browser tabs, each tab is a separate task that wants CPU time. The OS decides in what order and for how long each runs, a responsibility called CPU scheduling. Modern schedulers like the Completely Fair Scheduler in Linux try to give every process a fair share of CPU time while also prioritizing interactive tasks that users expect to feel snappy.
Memory allocation is another key responsibility. RAM is shared among all running processes, and the OS decides who gets what. Each process expects its own private address space, and the OS maintains that illusion even though physical RAM is shared. It does this through virtual memory — each process sees addresses from 0 up to some high number, but the kernel maps those virtual addresses to actual physical RAM pages, moving data in and out of RAM as needed.
For I/O, the OS schedules disk operations, manages network buffers, and handles interrupts from hardware devices. When you copy a large file, the OS breaks the operation into manageable chunks, intersperses it with other I/O requests so no single operation monopolizes the disk, and handles the fact that disk access is orders of magnitude slower than CPU operations.
OS as Service Provider
The operating system also acts as a service provider, offering fundamental services that every application needs.
File services are the most obvious. The OS maintains a file system — a structured way of naming, organizing, and storing files on disk. When your code opens /home/user/document.txt, the OS finds that file, checks permissions, and gives your program a file descriptor it can use to read from or write to the file. The OS handles the details of which disk blocks hold the data, how free space is tracked, and what happens if two programs try to modify the same file simultaneously.
Process services let programs start, stop, and communicate with each other. When you launch a new application, the OS creates a new process — allocates memory for it, sets up its environment, loads its code, and starts it running. The OS keeps track of every process with a data structure called the Process Control Block, which stores the process ID, its current state, its memory map, and more.
Networking services provide the socket API. Applications don’t need to know how TCP actually works to open a network connection. They call socket(), connect(), send(), and recv(), and the OS handles the protocol stack, the interface drivers, and packet transmission.
Security services include authentication (verifying who you are), authorization (deciding what you’re allowed to do), and accounting (tracking resource usage). Every login, every file permission check, every attempt to access a protected resource goes through the OS’s security machinery.
Types of Operating Systems
Not all operating systems are built for the same purpose. Different workloads demand different design trade-offs.
Batch operating systems were the earliest form. Programs were submitted in batches (punch cards or magnetic tape), and the OS ran them one after another without interactive input. No user sitting at a terminal waiting for results. Batch systems maximized throughput by keeping the CPU busy, minimizing downtime between jobs. Early mainframes used this approach extensively.
Time-sharing operating systems came along to make computers more interactive. Instead of running one job to completion before starting the next, these systems rapidly switch between multiple users and tasks, giving each a slice of CPU time. This creates the illusion that many programs run at once. Unix, MULTICS, and early versions of Windows were time-sharing systems. Linux and macOS are still fundamentally time-sharing systems at their core.
Real-time operating systems (RTOS) are designed for systems where timing matters more than throughput. In a microwave oven or a car’s anti-lock braking system, a computation that finishes one millisecond too late is functionally wrong. RTOSes like FreeRTOS, VxWorks, and Zephyr provide deterministic scheduling — they guarantee that a given operation completes within a known time bound. They’re used in embedded systems, industrial control, and safety-critical applications.
Embedded operating systems run on dedicated hardware for a specific purpose. Android powers phones and tablets. Embedded Linux runs on routers, smart TVs, and car infotainment systems. These OSes are often highly customized, stripping out anything not needed for the target device.
General-purpose operating systems are what most people think of as “an OS” — Windows, macOS, Linux distributions. They run on personal computers and servers, support a wide variety of applications, and handle an unpredictable mix of workloads. They prioritize convenience and flexibility over the strict determinism that embedded or real-time systems require.
Common Operating System Examples
Seeing how real operating systems work on the ground makes all this theory easier to absorb.
Linux is the dominant OS for servers, supercomputers, and Android phones. It’s open source, meaning anyone can read, modify, and redistribute the code. The Linux kernel powers everything from a Raspberry Pi to a Google data center. Its development model — thousands of contributors coordinating through email threads and a meritocratic hierarchy — is as interesting as the code itself.
Windows (specifically Windows NT and its descendants) runs on the vast majority of desktop and laptop computers. It also powers Azure cloud infrastructure and the Xbox gaming consoles. Windows took a different design path than Unix, with a more monolithic kernel architecture and a heavy emphasis on backwards compatibility with older Win32 applications.
macOS is Apple Macintosh’s operating system, built on a foundation of Darwin (a Unix-like OS) with a proprietary graphical shell on top. Its XNU kernel is a hybrid design combining the Mach microkernel with components from FreeBSD. macOS powers MacBook and iMac machines and is known for tight integration with Apple’s hardware ecosystem.
Android is Linux-based but diverges significantly from desktop Linux. Google maintains the Android Open Source Project (AOSP), which provides the base OS. On top of AOSP, device manufacturers add their own customizations, and Google adds its proprietary services (Play Store, Gmail, Maps). Android’s runtime (ART) executes Android apps, which are written in Java or Kotlin and run in a sandboxed environment.
Real-time operating systems like FreeRTOS, RTEMS, and Zephyr serve embedded and IoT markets. They typically consume only a few kilobytes of RAM and run on microcontrollers with severely constrained resources. You wouldn’t run a web server on them, but they’re ideal for a sensor node in a factory or the firmware in a medical device.
How This Fits Into the Roadmap
This post covers the foundational layer of operating systems: what they are, how they’re structured, and the major categories you’ll encounter. The rest of the Operating Systems Roadmap digs into each of the concepts mentioned here in far more depth.
From here, you’ll want to understand how the operating system has evolved over time in the OS History and Evolution post. Once you have the big picture, the Kernel Architecture post explores the different ways kernels can be designed — monolithic kernels versus microkernels versus hybrid designs. The System Calls Interface post goes deeper into how user programs actually invoke kernel services, which is essential for anyone writing low-level or systems code.
Understanding these fundamentals prepares you for the harder material ahead: how the OS schedules processes across multiple CPU cores, how memory allocation and virtual memory work, how file systems persist data, and how concurrent programs coordinate safely. Every advanced topic in this roadmap builds on the ideas introduced here.
Quick Recap Checklist
- An operating system sits between hardware and applications, providing clean abstractions so programs don’t need to manage hardware directly.
- The kernel runs in privileged mode with full hardware access; everything else runs in user space with restricted permissions.
- User programs communicate with the kernel through system calls — a defined interface that validates requests and executes them safely.
- The OS manages resources: CPU time, memory, and I/O are all scheduled, allocated, and coordinated by the kernel.
- The OS also provides services: file systems, process management, networking, and security are all kernel-provided.
- Operating systems come in several types: batch, time-sharing, real-time, embedded, and general-purpose, each optimized for different priorities.
- Linux, Windows, macOS, Android, and RTOSes each represent a different point in the design space of operating systems.
Interview Questions
The operating system's core purpose is to provide an abstraction layer between hardware and application software. It manages physical resources (CPU, memory, disk, network) and presents them as clean, virtualized interfaces that programs can use without needing to know the details of the underlying hardware. This includes resource management (scheduling, allocation), service provision (file systems, processes, networking), and enforcing security boundaries between user programs.
Kernel space is the privileged mode where the OS kernel runs with full access to hardware, memory, and special CPU instructions. User space is where regular applications run with restricted permissions — they cannot access hardware directly, cannot read kernel memory, and cannot execute privileged CPU instructions. This separation is enforced by the CPU's privilege levels (rings in x86 architecture). Every interaction between user space and kernel space happens through system calls, which the kernel validates before fulfilling.
A system call is the mechanism by which a user program requests a service from the kernel. On Linux, the process typically involves placing a system call number and arguments into CPU registers, then executing a syscall instruction that transitions to kernel mode. The kernel's system call handler validates the arguments, performs the requested operation (file access, process creation, memory allocation, etc.), and returns a result. Common system calls include read, write, fork, exec, and exit.
Batch operating systems process jobs in batches without user interaction, maximizing throughput. Time-sharing systems rapidly switch between multiple tasks to give interactive users the illusion of simultaneity (Linux, Unix, Windows NT). Real-time operating systems (RTOS) guarantee that operations complete within a specific time bound, making them suitable for embedded and safety-critical systems. Embedded OSes are customized for specific devices, stripping out features not needed for the target hardware.
As a resource manager, the OS allocates and schedules the finite hardware resources: CPU time is divided among competing processes by the scheduler, RAM is apportioned via virtual memory management, and I/O operations are queued and prioritized. As a service provider, the OS offers fundamental building blocks that every program needs — file systems for persistent storage, process management for launching and tracking tasks, networking stacks for communication, and security services for authentication and authorization. Programs consume these services through system calls rather than managing hardware themselves.
The shell (bash, zsh, PowerShell) is a user-space application that interprets commands and invokes other programs. It runs in user space just like any other application and must use system calls to interact with the kernel. The kernel, by contrast, runs in privileged mode and owns the hardware. The shell's job is to provide a convenient interface for human interaction — it's a program that makes system calls, not part of the kernel itself. You can replace bash with zsh or run a system with no shell at all (just automated scripts), but the kernel remains the same.
The Process Control Block (PCB), or task_struct in Linux, is the kernel's data structure representing a running process. It stores: process ID (PID) and parent PID, process state (running, sleeping, stopped, zombie), program counter and CPU registers, memory management info (page tables, segments), scheduling info (priority, quantum, run queue pointers), file descriptor table, accounting info (CPU time used, resource limits), signal mask and pending signals, and pointers to other related processes (thread group, parent-child relationships). The PCB is the central data structure the kernel uses to manage context switching, scheduling, and process lifecycle. When a scheduler switches away from a process, it saves the CPU registers into the PCB; when switching back, it restores them from the PCB.
Context switching is the process of saving the current process's state (CPU registers, program counter, stack pointer) into its PCB and loading another process's saved state from its PCB. The CPU is not executing user code during this switch — it's in kernel mode performing the save/load operations. Overhead comes from several sources: the cost of saving and restoring all CPU registers (including floating point and SIMD registers on modern CPUs), flushing CPU caches and branch predictors (the new process has a cold cache), TLB (Translation Lookaside Buffer) invalidation since virtual-to-physical mappings may differ for the new process, and potential pipeline stalls as the CPU fetches instructions from a completely different memory region. On a modern 3GHz CPU, a full context switch typically costs 1-5 microseconds of CPU time — negligible for infrequent switches but significant under heavy scheduler pressure with thousands of processes.
Virtual memory is a technique where the OS gives each process its own virtual address space (e.g., 0 to 2^64 on 64-bit systems), completely independent of what other processes see. The CPU's Memory Management Unit (MMU) translates virtual addresses to physical addresses using page tables maintained by the kernel. This translation means process A accessing virtual address 0x1000 is reading different physical memory than process B accessing the same virtual address 0x1000 — the kernel sets up different page tables for each process. The kernel can also mark pages as read-only, guard stack/heap regions with non-accessible pages to catch bugs, and swap less-used pages to disk. Without virtual memory, one process could read another process's memory directly — a fundamental breach of isolation. Virtual memory also enables Copy-On-Write fork, where pages are shared until either process writes to them.
A monolithic kernel (Linux, Unix) runs all kernel services — file systems, device drivers, networking, scheduling — in kernel space as a single large binary with full privileges. Communication between components happens through function calls within the same address space, making it fast but meaning a bug in any kernel component (e.g., a buggy filesystem driver) can crash the whole system. A microkernel (Minix, QNX, some research kernels) moves as much as possible out of kernel space into user-space processes — only minimal primitives like address space management and inter-process communication run in privileged mode. This provides better fault isolation (a crashed filesystem driver can be restarted) but introduces overhead from the IPC round-trips needed for every kernel operation, since a file read might require multiple IPC messages between the application, filesystem server, and block device server.
The boot sequence: (1) Power-on self-test (POST) initializes hardware and runs the BIOS/UEFI firmware from ROM. (2) The firmware loads the first 512 bytes of the boot device (MBR) or the EFI partition's boot loader (UEFI), which hands off to a boot loader like GRUB. (3) The boot loader loads the kernel binary into memory, sets up initial page tables, and passes control to the kernel's entry point. (4) The kernel initializes core subsystems in order: physical memory management, process scheduler, interrupt handlers, device drivers. (5) The kernel mounts the root filesystem and starts the first user-space process — init on traditional systems (PID 1) or systemd on modern Linux. (6) Init reads configuration and starts system services (network, logging, display manager), eventually presenting a login prompt (getty on console, display manager for GUI). The whole process typically takes 10-60 seconds on a modern system.
A device driver is kernel code that manages a specific piece of hardware — disks, network cards, USB controllers, GPUs. Drivers expose a standard interface to the rest of the kernel (e.g., a block device interface for disks, a character device interface for terminals) while handling all hardware-specific details: memory-mapped I/O registers, interrupt handling, DMA buffer management, firmware interaction. When an application reads from /dev/sda, the kernel routes the request to the SCSI/SATA driver, which issues commands to the disk controller via its command queue. Drivers run in kernel space with full hardware access, which is why buggy drivers cause BSODs and kernel panics rather than just crashing the application. Modern OSes use loadable kernel modules (Linux insmod, Windows AddDevice) so drivers can be loaded at runtime without rebooting.
A kernel panic (Linux) or Blue Screen of Death (Windows NT) is a fatal error in kernel space — the kernel detected an inconsistent state from which it cannot safely recover, so it halts the system rather than risk data corruption. Common causes: NULL pointer dereference in kernel code, deadlocks in kernel data structures (detected by a watchdog timer), corrupted scheduler run queues, hardware errors detected by the kernel. When a panic occurs, the kernel prints diagnostic information to the console (registers, stack trace, panic message), may dump a core file for later analysis, and either halts or automatically reboots depending on configuration. User-space crashes, by contrast, are handled by the kernel — it delivers a signal (SIGSEGV, SIGABRT) to the offending process and can clean up its resources (close files, free memory) because the kernel itself is still functioning. A kernel panic means the referee itself is down.
A zombie is a process that has exited (exit() or returned from main) but whose parent hasn't yet called wait() to read its exit status. The process table entry remains because the kernel retains the exit status until the parent collects it — zombies have no code running, no heap or stack, but still consume a slot in the process table. If the parent never calls wait() (a bug), zombies accumulate and can exhaust the PID table. An orphan is a process whose parent has died — the parent was wait()-ed on and exited, but the child is still running. In Linux, orphans are re-parented to init (PID 1) or systemd (in modern systems), which calls wait() on them to reap their exit statuses. This re-parenting ensures no process is ever left without a parent to reap it.
Filesystems present a hierarchical tree of named objects (files, directories, symlinks) as the user-facing interface to storage. The OS translates path names (like /home/user/doc.txt) through a chain of directory lookups using inode metadata — each directory entry maps a name to an inode number. The inode stores metadata (permissions, timestamps, size) and pointers to the actual data blocks on disk. This layering means applications see clean pathnames while the kernel maps them to whatever physical storage layout the specific filesystem uses (ext4, NTFS, Btrfs). The filesystem also handles concurrent access — file locks, journal recovery for crashes, permissions enforced at open time. If you rename or move a file, only directory entries change — the inode and data blocks stay the same. This is why renaming a large file is instantaneous regardless of file size.
The init system is the first user-space process (PID 1) started by the kernel during boot, and it is the ancestor of all subsequent processes. Its job is to bring the system to a working state: mounting filesystems, starting network services, launching background daemons, managing user login, and reaping zombie processes whose parents died. Traditional Unix init (SysV init) uses runlevels and shell scripts in /etc/rc.d/. systemd (modern Linux) is a parallelized init that manages services as units with explicit dependencies and tracks them as cgroups. macOS uses launchd, which implements a similar dependency-based service management. The init system also handles shutdown — it sends signals to services, unmounts filesystems, and powers off the machine. Because PID 1 inherits orphaned processes, init is also the process reaper for the entire system.
The x86 architecture defines four privilege levels (rings), but Linux and Windows use only ring 0 (kernel) and ring 3 (user). The CPU uses the Current Privilege Level (CPL) stored in the CS register's lower 2 bits to determine what operations are allowed — code running in ring 3 cannot execute privileged instructions like cli (disable interrupts), cannot write to control registers like CR3 (which holds the page table base), and cannot access memory not mapped into the current page tables. When a syscall or interrupt transfers control to kernel space, the CPU automatically switches to ring 0 and sets CPL=0. The transition is one-way for the duration of the kernel call; the kernel explicitly returns with sysret or iret, which restore ring 3. This hardware enforcement means a user bug can never corrupt kernel data structures — the CPU simply refuses to execute the operation.
Cooperative multitasking relies on processes voluntarily yielding the CPU — a process runs until it explicitly calls yield(), sleep(), or waits on I/O. The risk is a buggy process can monopolize the CPU indefinitely by never yielding. Preemptive multitasking lets the kernel forcibly interrupt a running process after its time quantum expires (timer interrupt) and schedule another process. The kernel has complete control over CPU time allocation, ensures no single process can starve others, and can prioritize interactive tasks over background ones. Linux, Windows, and macOS all use preemptive multitasking. Preemption introduces the need for kernel synchronization — an interrupt can fire while the kernel is holding a lock, and if the interrupt handler tries to acquire the same lock, deadlock ensues unless the kernel uses interrupt-disable or per-CPU locking strategies.
A regular function call within user space (e.g., calling strlen() in the C library) is just a call instruction — both functions share the same privilege level (ring 3) and the same address space. A system call is a deliberate crossing of a security boundary: the CPU transitions from ring 3 to ring 0, jumping into kernel code that has full hardware access. This is enforced by the CPU itself, not just software conventions. The kernel validates every argument from user space (not just trust them) before acting on them. A regular function call can corrupt your own process's memory but nothing else; a system call can affect the entire system, other processes, and hardware. The kernel is the security boundary that prevents one user process from accessing another process's memory or taking over the machine.
The scheduler decides which runnable process gets the CPU at any given moment, based on the scheduling policy (CFS on Linux, Multilevel Feedback Queue on Windows). It maintains run queues per CPU, each process's task_struct contains scheduling attributes like priority, quantum remaining, and vruntime for CFS's virtual deadline calculation. On each timer interrupt (typically every 1-4ms), the scheduler checks whether the current process has exhausted its quantum — if so, it's moved to the back of the run queue and the next process is selected. The scheduler also evaluates processes blocked on I/O, giving I/O-bound processes priority when their I/O completes (since they tend to be interactive). On symmetric multiprocessing (SMP) systems, the scheduler load-balances across CPUs, migrating processes to avoid idle cores. The goal is maximizing throughput and responsiveness while ensuring fairness — no single process should starve.
Further Reading
- OS History & Evolution — How operating systems evolved over time
- Boot Process — From power button to login prompt
- Kernel Architecture — How kernels are designed internally
- System Calls Interface — How programs talk to the kernel
- Silberschatz, Galvin, Gagne — Operating System Concepts (the “OS bible”)
Conclusion
Category
Related Posts
System Calls Interface
System calls are the boundary between user programs and the kernel. They are the mechanism by which user-space applications request services from the operating system — opening files, creating processes, allocating memory, and more. Understanding syscalls reveals how the OS enforces isolation and provides safe access to hardware.
Build Your Own OS
A hands-on project guide to building a minimal operating system from scratch: boot loader, kernel, scheduler, and file system.
CPU Affinity & Real-Time Operating Systems
CPU affinity binds processes to specific cores for cache warmth and latency control. RTOS adds deterministic scheduling with bounded latency for industrial, medical, and automotive systems.