Every tap and app launch passes through one piece of software first. This guide explains how the operating system boots, shares the processor, protects memory, organises files and keeps you safe, with diagrams and worked calculations.
Every time you tap an icon, save a file or switch between apps, one piece of software is quietly doing the work in the background: the operating system, or OS. It decides which program gets the processor next, keeps each app out of the others' memory, remembers where every file lives, and talks to the screen, speakers, camera and battery so that apps do not have to. You rarely notice it, because when it works well everything simply feels easy. This guide explains what an operating system does, step by step, with diagrams and worked calculations, and how Windows, macOS, Linux, Android and iOS are related and different.
Helpful background: How Computers Work introduces the processor, memory and storage that the operating system manages.
Imagine if every app had to include its own instructions for every kind of screen, keyboard, storage drive and camera ever made. That would be enormous, error-prone work, and two apps could easily clash by trying to control the same device at the same moment. An operating system solves this by sitting in the middle. It manages the hardware once, and offers every app a simple, standard set of requests such as "open this file", "draw this on the screen" or "send this over the network".
The processor can run in at least two modes. In kernel mode code may touch any hardware or memory. In user mode, where ordinary apps run, it may not. If a user-mode app needs something restricted, it must ask the kernel through a system call. This is why one crashing app usually cannot take the whole device down with it, and it is a basic security boundary.
When you press the power button, the operating system is not yet in memory, so something else has to start the process. This chain of steps is called booting (from "pulling yourself up by your bootstraps"):
A program is a set of instructions stored on disk. A process is a program that is running, together with its memory and current state. A thread is a smaller unit of work inside a process, and a process can have several. A modern device may have dozens or hundreds of processes, but only a handful of processor cores that can run instructions at the same moment.
The solution is multitasking. The operating system lets each process use the processor for a very short time slice, then switches to another, then another, and comes back around. Each switch is called a context switch: the OS saves the first process's state and loads the next one's. Because the slices are milliseconds long, everything seems to run at once. The part of the OS that decides who runs next is the scheduler.
At any moment a process is in one of three main states. It is running on a core, ready and waiting for a turn, or waiting for something slow, such as a disk read or a key press. A process that is waiting is not wasting the processor, because the scheduler gives the processor to another process meanwhile.
Three processes all arrive at time 0 and need processor time as follows: A needs 5 ms, B needs 3 ms, C needs 7 ms. The scheduler uses round-robin: each process runs for at most a time slice of 3 ms, then goes to the back of the queue.
Step 1: Build the timeline.
Step 2: Average finishing time. (11 + 6 + 15) ÷ 3 = 32 ÷ 3 ≈ 10.7 ms.
Step 3: Compare with "first come, first served" (run A fully, then B, then C): finishing times are 5, 8 and 15 ms, which averages (5 + 8 + 15) ÷ 3 = 9.3 ms.
Step 4: Compare how soon each first gets a turn. Round-robin: A at 0, B at 3, C at 6, an average of 3 ms. First come, first served: A at 0, B at 5, C at 8, an average of about 4.3 ms.
What this shows: round-robin finished jobs slightly later on average here, but everyone got a turn sooner, so the system feels more responsive. Real schedulers balance several goals, including fairness, speed and how important a task is.
Every process needs memory for its code and data. The OS gives each process its own virtual address space, a private set of addresses that looks like a long, empty stretch of memory belonging to that process alone. Behind the scenes, the OS and the processor translate these virtual addresses into real locations in physical memory (RAM). Memory is divided into equal blocks: pages in the virtual space and frames in physical memory. A page table records which page sits in which frame.
This gives three benefits:
Suppose pages are 4 KB each, which is 4,096 bytes. A program asks for the byte at virtual address 10,000.
Step 1: Which page? Divide by the page size: 10,000 ÷ 4,096 = 2 with a remainder. So the address is in page 2 (pages are numbered from 0).
Step 2: How far into the page? The remainder is the offset: 10,000 − (2 × 4,096) = 10,000 − 8,192 = 1,808.
Step 3: Translate. The OS looks up page 2 in the page table. If page 2 is in frame 7, the real location is frame 7 plus an offset of 1,808.
Another quick check: a program of 100 MB needs 100 × 1,024 ÷ 4 = 25,600 pages of 4 KB each.
Note: page sizes vary between systems and 4 KB is only a common choice. The idea is the same: split an address into a page number and an offset.
A storage drive is just a huge series of blocks. The file system organises them into files, folders (directories) and paths (such as Documents/School/essay.txt), and keeps records of where each file's data is stored. It also stores metadata: the name, size, dates and permissions of each file. Common file systems include NTFS on Windows, APFS on Apple devices and ext4 on many Linux systems.
Suppose the allocation unit is 4 KB = 4,096 bytes.
A 10,000-byte file: 10,000 ÷ 4,096 = 2.44, so it needs 3 units (always round up). It occupies 3 × 4,096 = 12,288 bytes. The unused part is 12,288 − 10,000 = 2,288 bytes, often called slack space.
1,000 tiny files of 100 bytes each: each still takes a whole unit, so they occupy 1,000 × 4,096 = 4,096,000 bytes (about 4.1 MB), even though they hold only 1,000 × 100 = 100,000 bytes of real data. That is about 41 times more space than the data itself.
Lesson: many small files waste more space than a few large ones. Different file systems handle small files in different ways, so the exact waste varies.
Hardware devices work at very different speeds. A processor can do millions of operations in the time it takes to press a key. Instead of constantly checking whether a key has been pressed, the processor gets on with other work, and the device sends a signal called an interrupt when something happens. The processor pauses what it is doing, the OS runs a short piece of code to handle the event through the right driver, and then normal work resumes. This is why you can type while a download runs in the background.
The operating system is also the first line of defence. It keeps separate user accounts, checks permissions before letting a program touch a file or device, and isolates processes from each other. Everyday use should be done from a standard account rather than an administrator account, so that malware running in your name has less power (this is the idea of least privilege in Cybersecurity Basics). Phone systems add sandboxing, which confines each app to its own area, and ask permission before an app can use the camera, location or contacts (see Digital Footprint & Online Privacy).
Updates matter because the OS is a huge program with inevitable flaws. Updates fix security holes, and installing them promptly is one of the best defences available.
The OS also provides the way you control the device. A command-line interface (CLI) accepts typed commands through a program called a shell. It is precise, can be automated, and is still widely used by programmers and system administrators. A graphical user interface (GUI) uses windows, icons, menus and a pointer, an idea developed at Xerox PARC in the 1970s and popularised by the Macintosh and Windows. Phones and tablets are built around touch, and many devices now also accept voice. All of these sit on top of the same underlying kernel jobs.
Operating systems have a family tree. In the early 1970s at Bell Labs, Ken Thompson and Dennis Ritchie created Unix, whose ideas strongly influenced many later systems. In 1991 Linus Torvalds began writing a free kernel, now called Linux, in the Unix style.
| System | Where you find it | Useful facts |
|---|---|---|
| Windows | Many desktops and laptops | Made by Microsoft. First released in 1985. It runs on a kernel of its own design, not Unix-based. |
| macOS | Apple laptops and desktops | Made by Apple. Built on a Unix-based core, introduced in the early 2000s. |
| Linux | Servers, supercomputers, many embedded devices, and desktops | Strictly the name of the kernel. It is combined with other software into "distributions". It is open source. |
| Android | Most of the world's smartphones, plus tablets and TVs | Based on the Linux kernel. Released in 2008. Open-source core, though phone makers add their own software. |
| iOS / iPadOS | iPhone and iPad | Made by Apple, related to macOS. Released in 2007. |
| Embedded and real-time systems | Routers, cars, medical devices, appliances | Small operating systems designed to respond within a guaranteed time. |
Open source means the source code is published and others may study, modify and share it under a licence. Proprietary software keeps its code private. Each approach has advantages: openness lets many people inspect and improve the code, while a single company can control the whole experience tightly. Both kinds power huge numbers of devices.
A hypervisor can divide one physical computer into several virtual machines, each running its own operating system (see Cloud Computing). This is how data centres share one server among many customers, and how a person can run Windows and Linux side by side on one laptop. Many servers in the cloud use Linux, although they also run other systems.
Understanding the OS helps you diagnose everyday problems. Match the symptom to the idea behind it:
| Symptom | Likely idea | Sensible action |
|---|---|---|
| Everything slows when many apps are open | Too many processes competing for the processor and RAM; swapping to storage | Close apps you are not using. Look at your device's activity monitor to see what uses the most. |
| A device is slow right after switching on | Many background services and start-up apps launching | Disable start-up apps you do not need. |
| "Disk full" warnings | The file system has no free space; storage is crowded | Remove unused files and apps, and move big files elsewhere. |
| An app freezes but others work | One process is stuck; process isolation means others are unaffected | Close that app. Restart if it keeps happening. |
| Battery drains quickly | Background processes and screen use keep the processor busy | Check battery settings to see which apps use most. |
| Strange behaviour after a long time on | Memory problems or buggy software | Restart. It clears memory and starts a fresh set of processes. |
Keep the system and your apps updated, keep backups of important files (see Cloud Computing), and only force-close or delete things you recognise. Ending the wrong system process can make a device unstable.
Try each question first, then tap it to reveal the answer. A scored multiple-choice quiz follows below.
It manages the hardware and gives apps a standard, safe way to use it, handling processes, memory, files and devices.
They would need code for every device, and two apps could clash. Letting the kernel control hardware also keeps one faulty app from crashing the whole device.
Every process gets its first turn sooner (average 3 ms instead of about 4.3 ms), so the system feels more responsive.
5,000 ÷ 4,096 = 1 remainder 904, so page 1, offset 904.
5,000 ÷ 4,096 is about 1.22, so it needs 2 units: 2 × 4,096 = 8,192 bytes.
Malware running as a standard user has fewer permissions, so it can do less damage. This is the principle of least privilege.
Be the scheduler: give each student a card saying how many "time units" their job needs, and let one student act as the scheduler with a time slice of 3. Record the finishing times and compare with first come, first served, as in Worked Example 1.
Paper file system: use index cards as storage blocks and let students write file names and a list of block numbers on a "directory" sheet. Delete a file by crossing out only its directory entry and discuss what remains.
Explore your own device: with an adult nearby, open the device's built-in activity or battery screen (such as Task Manager, Activity Monitor or battery settings), look at which apps use the most, and discuss why. Do not end processes you do not recognise.
Safety note: installing or removing operating systems, and changing system settings, should be done on a spare or practice device, with a backup, and with a responsible adult.
This article is original EDUSAMBAM writing. Its structure follows the three themes of the free university textbook below (virtualisation of the processor and memory, concurrency and persistence), and the diagrams are original EDUSAMBAM schematics. The scheduling, paging and file-space calculations are simplified teaching models with invented numbers, and real systems use more advanced methods. Dates and names (Unix, Linux, Windows, Android, iOS) are from the public historical record.
Operating systems change with every release, so check your own device's current settings and documentation. This article does not recommend one operating system over another.
10 questions. Select an answer for each, then submit to see your score instantly.