Operating Systems 📂 Introduction · 3 of 5 43 min read

OS Generations, System Boot, Services, User Interfaces & System Calls

A complete Galvin-style deep dive covering the five generations of operating systems, the full boot sequence from power-on to login, every OS service, user interface types (CLI, GUI, touch, voice), and the entire world of system calls — mechanism, parameter passing, and all six categories with real Linux and Windows examples. Includes animated SVG diagrams and hands-on strace demonstrations.

Section 01

The Five Generations of Operating Systems

From Telegrams to WhatsApp
Communication evolved from telegrams (slow, manual) → landlines → SMS → email → real-time messaging. Each leap didn't just add speed — it changed who could communicate and how. Operating systems evolved identically. Each generation solved the biggest frustration of the era before it, moving computing steadily closer to ordinary humans and further from the raw hardware.

Animated Timeline — 80 Years of OS Evolution

Five Generations at a Glance
1 1945-55 Vacuum Tubes No OS 2 1955-65 Transistors Batch OS FMS, IBSYS 3 1965-80 ICs, Multi- programming UNIX, OS/360 4 1980-2000 PCs & GUI Networking Win, Linux, Mac 5 2000-Now Mobile, Cloud AI, IoT iOS, Android, K8s 80 Years of Progress — from Room-Sized to Pocket-Sized Each dot pulses; a pulse of light travels the timeline continuously

1.1 Generation 1 (1945–1955) — Vacuum Tubes, No OS

Machines like ENIAC and UNIVAC I filled entire rooms. A programmer physically rewired plugboards or fed punched cards for every program. There was no operating system, no library, no compiler — just the programmer and raw hardware. Machine failures happened every few minutes because vacuum tubes burned out.

1.2 Generation 2 (1955–1965) — Transistors and Batch Systems

Transistors replaced tubes, making machines smaller and more reliable. Programs were still submitted as decks of punched cards, but an operator collected them into batches and ran them one after another. This gave birth to the first real operating systems — FMS (Fortran Monitor System) and IBM's IBSYS. FORTRAN and COBOL emerged as programming languages.

1.3 Generation 3 (1965–1980) — Integrated Circuits, Multiprogramming

Integrated circuits dramatically shrank hardware. IBM's OS/360 introduced the idea of one OS running across an entire product family. MULTICS pioneered time-sharing; its lessons produced UNIX at Bell Labs in 1969. Key concepts born here: multiprogramming, virtual memory, spooling, time-sharing, minicomputers.

1.4 Generation 4 (1980–2000) — Personal Computers and GUI

VLSI put a full CPU on a single chip. MS-DOS (1981), the Apple Macintosh (1984), Windows 3.1 (1992), and Linux (1991) put a computer on every desk. Xerox PARC's WIMP interface (Windows, Icons, Menus, Pointer) became mainstream. TCP/IP networking made network operating systems possible.

1.5 Generation 5 (2000–Present) — Mobile, Cloud, and AI

iOS (2007) and Android (2008) made touch the primary input. Cloud OS platforms (AWS, Azure, GCP) turned data centers into rentable slices. Container orchestration (Kubernetes) treats thousands of servers as one machine. AI-assisted schedulers, predictive prefetching, and secure enclaves define the current frontier.

🔬
One Idea Runs Through All Five Generations

Every generation moved computing closer to the user and further from the hardware. First programmers were the OS. Then the OS mediated. Now the OS is invisible — you tap an icon and everything just works.


Section 02

System Boot — From Power Button to Login Screen

When you press the power button, your computer has no idea what an OS is. Getting from "electricity flowing" to "here's your desktop" is a carefully choreographed boot sequence. Galvin calls the small program that starts it all the bootstrap program.

Animated Boot Flow — Six Stages, Each Bootstrapping the Next

Live Boot Sequence
1. POWER ON (electricity flows) 2. BIOS / UEFI FIRMWARE POST → detects CPU, RAM, disk → picks boot device 3. BOOTLOADER (GRUB / Windows BM) Loaded from MBR / ESP → loads the kernel 4. KERNEL INITIALISATION Decompress vmlinuz → drivers → mount root FS 5. INIT PROCESS (systemd, PID 1) Start services → reach target (multi-user, graphical) 6. LOGIN PROMPT / DESKTOP ✓ Hardware Firmware (ROM) Disk Kernel space User space You! Watch the pulse travel through each stage → each bootstraps the next
🔌 Why "Bootstrapping"?
Problem
RAM is empty at power-on. Where does the CPU get its first instruction?
Solution
The CPU is hard-wired to fetch from a fixed ROM address (0xFFFFFFF0 on x86-64). That ROM holds the BIOS/UEFI firmware — the first instructions ever executed.
Result
Tiny bootstrap in ROM → small bootloader on disk → huge kernel → userspace. Each stage bootstraps the next — the term borrowed from "pulling yourself up by your bootstraps".

2.1 BIOS vs UEFI — The Firmware Layer

🔒 BIOS (Legacy, 1975-2015)
16-bit real mode, 1 MB RAM limit
Boots from MBR — first 512 bytes of disk
Max disk size 2 TB (32-bit LBA)
No Secure Boot, no GUI setup
Text menu, keyboard-only navigation
✅ UEFI (Modern, 2005-Present)
64-bit, uses full RAM & hardware
Boots from EFI System Partition (.efi files)
Disk size up to 9.4 ZB (via GPT)
Secure Boot — cryptographic signature checks
GUI setup, mouse support, network boot

2.2 Practical — Observe Your Own Boot Sequence

# Linux — see kernel messages from the boot sequence
$ dmesg | head -20
[    0.000000] Linux version 6.5.0-15-generic (gcc 11.4.0)
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz root=UUID=... ro quiet
[    0.043210] ACPI: Early table checksum verification disabled
[    0.145678] smpboot: CPU0: Intel(R) Core(TM) i7-12700H
[    0.789012] usb 1-1: new high-speed USB device number 2

# How long each stage took
$ systemd-analyze
Startup finished in 2.851s (kernel) + 4.213s (userspace) = 7.064s
graphical.target reached after 4.198s in userspace

# Which services were the slowest to start
$ systemd-analyze blame | head -5
 2.410s  NetworkManager-wait-online.service
 1.184s  snapd.service
  978ms  plymouth-quit-wait.service
  542ms  systemd-journal-flush.service
  318ms  udisks2.service

# Are you booted via UEFI or BIOS?
$ [ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"
UEFI

Section 03

Operating System Services — What the OS Provides

Galvin groups OS services into two families: services that help the user, and services that ensure efficient system operation. Both reach programs through system calls and reach humans through interfaces.

Animated Overview — All OS Services Orbiting the Kernel

The OS Service Constellation
KERNEL Service hub UI CLI/GUI Exec Programs I/O Devices Files FS Comm IPC Errors Detect Alloc CPU/RAM Services orbit the kernel — each reachable through a system call
Service Family What It Does
User InterfaceUser-facingCLI, GUI, or touch — human ↔ machine
Program ExecutionUser-facingLoad binary, run, terminate cleanly
I/O OperationsUser-facingUniform interface to disk, network, keyboard
File-System ManipulationUser-facingFiles, directories, permissions, search
CommunicationUser-facingPipes, sockets, shared memory, IPC
Error DetectionUser-facingHardware faults, memory errors, invalid ops
Resource AllocationSystem-facingDistribute CPU, RAM, disk among processes
AccountingSystem-facingTrack usage per user for billing/planning
Protection & SecuritySystem-facingIsolate processes, authenticate users

Section 04

User & OS Interface — CLI, GUI, Touch, Voice

Every OS exposes at least one interface for humans. Most modern OSes provide several so users can pick the right tool for the task.

Animated Comparison — Same Task, Different Interfaces

Which Interface Wins Where
CLI $ mkdir p_{01..99} 99 folders created $ _ One line · < 1 sec Scriptable · fast GUI 📁 New Folder 📁 project_01 Click × 99 · minutes Discoverable TOUCH Tap · swipe · pinch Mobile-first VOICE "Hey Siri…" Hands-free Same OS — Four Ways to Ask It Something
💻
CLI
Type commands into a shell (bash, zsh, PowerShell). Fast, scriptable, minimal resource use. Ideal for sysadmins and servers.
bash · zsh · powershell
🖥️
GUI
Windows, icons, menus, pointer (WIMP). Discoverable, forgiving. Ideal for everyday users and creative work.
windows · macOS · gnome
📱
Touch
Direct manipulation with fingers — taps, swipes, pinches. Default on phones and tablets.
iOS · Android
🎤
Voice
Speech-to-text plus NLU. Hands-free, accessible. Siri, Alexa, Google Assistant, Cortana.
smart speakers · cars · IoT
📝
Batch / Scripted
A file of commands runs unattended to completion. Shell scripts, cron, systemd timers, CI/CD.
cron · systemd · CI
🧠
Programmatic (API)
Not a human interface — programs speak to the OS through libraries and system calls. Covered in the next section.
libc · WinAPI

Section 05

System Calls — The Programmer's Doorway to the Kernel

A system call is the programmatic way a user process asks the OS kernel to do something on its behalf. It is the only legal path from user mode to kernel mode — hardware enforces this via a special instruction (syscall on x86-64, svc on ARM64).

Animated Mode Switch — What Really Happens on write()

Anatomy of a System Call — Live Mode Switch
USER SPACE (mode bit = 1) KERNEL SPACE (mode bit = 0) 1. printf("Hi") in your program 2. glibc's write() wrapper 3. Args → registers · syscall instr 4. Trap → mode switch → kernel 5. Lookup sys_call_table[1] → sys_write 6. Bytes written to terminal device 7. Return value in RAX → back to user 8. printf returns · your code continues MODE BIT Packet changes color at every mode switch — blue = user, red = kernel
🔒
Hardware-Enforced Boundary

You cannot "fake" a mode switch from user code. The syscall instruction is the only instruction that atomically sets the mode bit to kernel and jumps to a fixed kernel entry point. Any attempt to modify the mode bit directly from user space raises a General Protection Fault and the OS kills your process.

5.1 API vs System Call — What You Write vs What Actually Happens

LayerWhat It IsExample
ApplicationYour programprintf("Hi")
API (library)Portable wrapperglibc write()
System callActual kernel entrysyscall #1 on Linux x86-64
Kernel routineHandlerLinux sys_write()
HardwareDevice drivertty driver → terminal

5.2 How Parameters Are Passed to a Syscall

1️⃣
Registers
Fastest, limited count
Args placed directly in CPU registers (RDI, RSI, RDX, R10, R8, R9 on Linux x86-64). Fastest but limited to ~6 args.
2️⃣
Memory Block
For many/large args
Args stored in a memory block; the block's address is placed in a register. Used when the arg count exceeds register limits.
3️⃣
Stack
Traditional (32-bit)
Args pushed onto the process's user stack; kernel pops them off. Common on older 32-bit systems (Linux x86 int 0x80).

Section 06

The Six Categories of System Calls (Galvin)

Every syscall, regardless of OS, falls into one of six functional groups. Learn these six and any kernel's syscall table becomes readable.

Animated View — Syscall Categories Feeding the Kernel

Six Streams Into the Kernel
KERNEL 1. Process Control 2. File Management 3. Device Mgmt 4. Info Maintenance 5. Communication 6. Protection fork · exec · exit · wait open · read · write · close ioctl · request · release getpid · time · uname pipe · socket · send · recv chmod · chown · setuid Every request from every program lands in one of these six buckets Watch the colored packets flow into the kernel continuously
Category Purpose Linux Windows
Process Control Create, terminate, wait, load, execute processes fork(), execve(), wait(), exit() CreateProcess(), ExitProcess()
File Management Create, open, read, write, delete, close files open(), read(), write(), close() CreateFile(), ReadFile(), WriteFile()
Device Management Request & release devices, read/write, get/set attributes ioctl(), read(), write() on /dev/* DeviceIoControl()
Information Maintenance Get/set time, date, PID, system data getpid(), time(), uname() GetCurrentProcessId(), GetSystemTime()
Communication Create/delete connections, send/receive messages, shared memory pipe(), socket(), send(), shmget() CreatePipe(), socket()
Protection Control access to resources, set/get permissions chmod(), chown(), setuid() SetFileSecurity()

6.1 Process Control — fork() and exec() in C

// Classic Galvin fork-exec-wait pattern
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main() {
    pid_t pid = fork();           // SYSCALL — clone the process

    if (pid == 0) {
        printf("Child PID %d\n", getpid());
        execlp("ls", "ls", "-l", NULL);   // SYSCALL — replace child image
    } else {
        int status;
        wait(&status);          // SYSCALL — parent waits
        printf("Child finished with status %d\n", status);
    }
    return 0;
}
OUTPUT
Child PID 4127 total 12 -rw-r--r-- 1 mohit mohit 298 Jul 18 09:14 fork_demo.c -rwxr-xr-x 1 mohit mohit 8760 Jul 18 09:14 fork_demo Child finished with status 0

6.2 File Management — Reading a File with Raw Syscalls

#include <fcntl.h>
#include <unistd.h>

int main() {
    int  fd = open("/etc/hostname", O_RDONLY);   // SYSCALL 1
    char buf[64];
    int  n  = read(fd, buf, sizeof(buf));         // SYSCALL 2
    write(1, buf, n);                              // SYSCALL 3  (fd 1 = stdout)
    close(fd);                                     // SYSCALL 4
    return 0;
}

6.3 Communication — Pipe Between Parent and Child

#include <stdio.h>
#include <unistd.h>

int main() {
    int fd[2];  pipe(fd);                     // SYSCALL — create pipe
    if (fork() == 0) {
        close(fd[0]);
        write(fd[1], "Hello parent!\n", 14);
    } else {
        char buf[64];
        close(fd[1]);
        int n = read(fd[0], buf, sizeof(buf));
        write(1, buf, n);
    }
    return 0;
}

6.4 Watch Every System Call a Program Makes

# strace shows every syscall + args + return value
$ strace -e trace=openat,read,write,close cat /etc/hostname

openat(AT_FDCWD, "/etc/hostname", O_RDONLY)  = 3
read(3, "mohit-laptop\n", 131072)            = 13
write(1, "mohit-laptop\n", 13)               = 13
close(3)                                     = 0
+++ exited with 0 +++

# Aggregate — how many syscalls of each type
$ strace -c ls / > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 28.14    0.000203           7        27           mmap
 19.35    0.000140           6        22           openat
 12.06    0.000087           4        22           close
  9.98    0.000072           3        21           read
  7.34    0.000053           2        19           fstat
------ ----------- ----------- --------- --------- ----------------
100.00    0.000723                    120         0 total

Section 07

System Programs — Between the User and the Syscall

Users rarely make syscalls directly. Instead, they use system programs — utilities bundled with the OS that wrap syscalls in friendly commands. Galvin lists eight common categories.

📁
File Manipulation
cp, mv, rm, ls, mkdir
📈
Status Info
date, ps, top, df, uptime
✏️
File Modification
nano, vim, sed, awk
🔧
Programming Support
gcc, python, make, gdb
🚀
Program Loading
ld, dynamic loader, ldd
📱
Communications
ssh, curl, ping, mail
🌐
Background Services
systemd, cron, sshd
🔌
Applications
Browsers, editors, spreadsheets bundled with the OS

Section 08

Practical — Trace echo hi All the Way Down

🔍 A Trivial Command, Traced to the Kernel
1
Shell reads keystrokes via read() from stdin → File Management syscall.
2
Shell parses "echo hi" and calls fork()Process Control.
3
Child calls execve("/bin/echo", ...)Process Control. Kernel loads the binary and jumps to its entry point.
4
echo calls write(1, "hi\n", 3)File Management. Kernel forwards bytes to the terminal driver.
5
echo calls exit_group(0)Process Control. Kernel reclaims memory.
6
Parent shell's wait4() returns → Process Control. Prompt reappears.
🏆
Two Categories, One Trivial Command

A one-word echo hi triggered at least six syscalls spanning two of Galvin's six categories. Every interactive command is a small conversation between your shell and the kernel.


Section 09

Golden Rules — What to Remember

📚 Generations, Boot, Services & System Calls — Foundations
1
Each OS generation was born to solve the pain of the previous. Batch fixed one-at-a-time; time-sharing fixed no-user-interaction; GUI fixed the steep learning curve; cloud fixed owning the hardware.
2
Booting is bootstrapping — tiny ROM code loads a small bootloader, which loads the huge kernel, which loads userspace. Each stage bootstraps the next.
3
BIOS is legacy; UEFI is the present. UEFI supports Secure Boot, 64-bit firmware, network boot, and disks > 2 TB.
4
OS services split neatly: user-facing (UI, execution, file access, I/O, communication, error detection) vs system-facing (allocation, accounting, protection).
5
A system call is the only legal path from user mode to kernel mode. Hardware enforces it via the syscall instruction and mode bit — user code cannot fake it.
6
API ≠ syscall. API (glibc, WinAPI) is what you write; it wraps the actual syscall so your code is portable across OS versions and architectures.
7
Every syscall fits into one of six categories: Process Control, File Management, Device Management, Information Maintenance, Communication, Protection. Learn these six and any kernel becomes navigable.
8
Use strace (Linux), dtruss (macOS), or Process Monitor (Windows) to see syscalls live. Watching a program's kernel entries is the fastest way to truly understand the OS.