Operating System Basics·Lesson 2 of 11
Need for Operating System
Start With a Machine That Has No OS
The fastest way to understand why we need an operating system is to imagine a computer without one. You have a CPU, some RAM, a disk, a keyboard, and a screen. None of them know about each other. The CPU can only do one thing: fetch an instruction from a memory address and execute it. Nobody has decided which instructions to put there, where your program should live in memory, or how to turn a spinning disk into something called a "file."
Without an operating system, every program you write would have to solve all of that itself. It would need its own code to talk to your exact model of disk, its own scheme for laying out memory, and its own logic for reading the keyboard. Change the disk and the program breaks. Run a second program and the two would overwrite each other's memory within milliseconds.
The core reason in one sentence
An operating system exists because hardware is limited, awkward, and unprotected — and every program on the machine needs it at the same time.
A city with no traffic system
Imagine roads with no lights, no lane markings, no rules about who goes first. Every driver would have to negotiate every junction personally, and one reckless driver could block the whole city. Traffic infrastructure doesn't make cars faster — it makes it possible for thousands of cars to share the same roads without chaos. That is exactly what an operating system does for programs sharing one machine.
The Five Problems an OS Solves
Every feature you'll study later in this module traces back to one of five problems. If you can name these five, you can explain why almost any OS mechanism exists — scheduling, paging, file systems, and drivers are all answers to one of them.
Sharing scarce resources
There is one CPU and a fixed amount of RAM, but dozens of programs want both right now. Somebody has to decide the order and enforce it. The OS does, through scheduling and memory allocation.
Hiding hardware complexity
Talking to a disk means dealing with sectors, controllers, and timing. No application should know any of that. The OS turns it into open, read, write, and close.
Protection and isolation
A buggy or malicious program must not be able to read your bank details out of another program's memory, or wipe a disk it doesn't own. The OS enforces boundaries the hardware alone won't.
Portability across machines
The same Chrome build runs on thousands of hardware combinations. It can, because it targets the OS interface rather than any specific device. The OS absorbs hardware differences.
Keeping the hardware busy
A disk read takes millions of CPU cycles. Left alone, the CPU would sit idle waiting. The OS switches to another program during the wait, so nothing is wasted.
A usable interface for humans
Because the OS owns the machine, it can offer people a consistent way in — a desktop, a shell, a file explorer — instead of a different ritual for every device.
Problem 1 in Detail — Who Gets the CPU?
A single CPU core can execute exactly one instruction stream at a time. Yet your laptop right now is running a browser, a music player, a code editor, and a hundred background services. They aren't truly running at once — the OS is switching between them so quickly that all of them feel alive. That trick is called , and without an OS to perform the switch, whichever program started first would simply own the CPU forever.
The switch itself is called a , and the OS is the only software in a position to perform it, because only the OS can be trusted to save one program's half-finished state and restore another's without either program noticing.
Problem 3 in Detail — Why Protection Needs an OS
Protection is the problem people underestimate most. If any program could write to any memory address, a single typo in one app could corrupt another, and any downloaded program could read every password on your machine. The OS prevents this by never letting application code touch hardware directly. Programs run in a restricted , and only the kernel runs in the fully privileged .
This is the difference between a machine that can safely run software you didn't write and one that can't. Here's how the same situation plays out with and without an OS in charge:
| Situation | Bare hardware, no OS | With an operating system |
|---|---|---|
| Two programs need the CPU | First one keeps it forever | Scheduler shares it in slices |
| A program has a memory bug | Can overwrite anything, anywhere | Confined to its own address space; OS kills it |
| Reading a file | App must know the exact disk hardware | App calls open and read; OS handles the device |
| A program crashes | Whole machine likely goes down | Only that process dies; the system survives |
| New hardware is installed | Every app needs rewriting | One new driver, apps untouched |
| Two users on one machine | No way to keep data private | Per-user accounts, permissions, and file ownership |
What You Gain, and What It Costs
An operating system is not free. It occupies memory, its scheduling and switching consume CPU cycles, and the abstraction layer it provides means a program can never squeeze the absolute last drop of performance out of the hardware. Almost always that's a trade worth making — but it's worth knowing what you're trading.
What an OS gives you
- Many programs run at once, with the CPU kept busy instead of idle
- Programs are isolated, so one crash or bug can't take down the rest
- Hardware is presented as simple abstractions: files, processes, sockets
- The same application runs across very different machines
- Multiple users can share one machine with private data and permissions
- Devices work through drivers, so new hardware needs no application changes
- A consistent interface for humans, whether a desktop or a shell
What it costs you
- The kernel and its data structures permanently occupy memory
- Context switching and scheduling burn CPU cycles on no useful work
- Abstraction hides hardware features an expert program could exploit directly
- System calls cost more than plain function calls because of the mode switch
- The OS is a large, complex codebase — bugs in it affect everything
- A kernel-level failure can bring down the entire machine, not just one app
Where the trade-off flips
On tiny embedded chips — a washing machine controller, a simple sensor — a full OS costs more than it's worth, so a single program runs on bare metal. The moment you need two programs, protection between them, or portability, the OS earns its keep.
A Concrete Walkthrough
Take something as ordinary as opening a photo. Follow what the operating system does behind that one double-click and the need for it becomes obvious — each step is a resource it had to find, allocate, protect, or translate on your behalf.
Double-clicking a photo, step by step
- The OS finds the image viewer program on disk — you gave it a name, not a disk location
- It allocates memory for the program and loads its code in
- It creates a process, gives it an identity, and puts it in line for the CPU
- The program asks to open the photo; the OS checks you have permission to read that file
- The OS translates the filename into actual disk blocks and issues the hardware read
- While the disk works, the OS runs other programs so the CPU isn't wasted
- The data arrives, the OS hands it to the program, and the program draws it to the screen through the OS's display interface
- You close the window; the OS reclaims the memory and removes the process
“"We need an operating system mainly so people have a nice interface to click on."”
“"Modern hardware is fast enough that an OS is just overhead we tolerate."”
Q:Why can't applications just talk to the hardware directly? It would be faster.
A: It would be marginally faster and enormously worse. Every application would need drivers for every device, would break whenever hardware changed, and could read or corrupt any other program's data. And with no neutral referee, the first program to grab the CPU would never give it back. The small cost of going through the OS buys safety, sharing, and portability.
Q:If an OS adds overhead, why does a machine with an OS often feel faster?
A: Because the biggest waste in a computer isn't switching overhead, it's idle time. Disk and network operations take millions of CPU cycles, and a lone program simply sits there waiting. The OS fills that dead time with other work. The cycles it spends scheduling are far fewer than the cycles it rescues from idling.
Quick Revision Cheat Sheet
Core need: Hardware is limited, awkward, and unprotected — and every program wants it at once
Problem 1: Sharing scarce resources — CPU, memory, disk
Problem 2: Hiding hardware complexity behind simple abstractions
Problem 3: Protection and isolation between programs and users
Problem 4: Portability — one app across many machines
Problem 5: Utilization — filling idle CPU time during slow I/O
Main costs: Memory footprint, context-switch overhead, hidden hardware features
When to skip an OS: Tiny embedded devices running exactly one program on bare metal