Lesson 1 · Operating Systems

Introduction to Operating Systems

An operating system sits between applications and hardware. It manages processes, memory, files, devices and security, and provides the interface you work through. This lesson covers what it does, the six functions named in exams, and every type of operating system with examples.

What is an operating system, and where does it sit

An introduction to OS study path usually starts here and moves to processes, memory, and files in that order, because each depends on the one before it.

An operating system is the software layer between your applications and the computer hardware. A browser does not program the disk controller or the network card. It asks the operating system, and the operating system does the work on its behalf.

That layer exists so hardware differences stop mattering. The same open() call reads a file whether the bytes live on an NVMe SSD, a USB stick, or a network share, because the OS hides the device behind one interface.

Two words appear constantly in this topic. The kernel is the core that talks to hardware and runs with full privilege. The shell is the outer layer you interact with, either a graphical desktop or a command line. The kernel is the OS proper; the shell is how you reach it.

Applications run in user mode, with restricted privilege
The kernel runs in kernel mode and controls hardware directly
Device drivers translate general requests into device-specific commands
The shell (GUI or CLI) is the user's interface to the kernel

Functions of an operating system

Exam questions on this topic almost always ask for the functions of an operating system. There are six, and each one answers a different question about a shared machine.

Notice the pattern: every function exists because a resource is limited and several programs want it at once. Take away the sharing and most of the operating system becomes unnecessary.

Process management — create, schedule, pause, and terminate processes; decide which one gets the CPU next
Memory management — allocate memory to processes, translate addresses, and stop one process reading another's memory
File management — organise data into files and directories, and control who may read or write each one
Device (I/O) management — queue requests to disks, printers, and network cards, and complete them through drivers
Security and protection — authenticate users, enforce permissions, and isolate processes from each other
User interface — provide the shell, whether a GUI with windows and icons or a CLI that accepts typed commands

Types of operating systems, with examples

The types differ in one respect: how they decide what runs next, and how long a user waits for an answer. Read the list with that question in mind rather than memorising labels.

A batch operating system collects jobs and runs them one after another with no interaction — early payroll and billing runs worked this way. A time-sharing (multitasking) system slices the CPU into short quanta so many users appear to run at once; Unix and Linux are the classic examples. A real-time operating system (RTOS) guarantees a response inside a fixed deadline, which is why VxWorks and FreeRTOS run in pacemakers, car braking systems, and industrial controllers. A distributed system spreads work across networked machines that behave as one. An embedded OS runs on fixed-purpose hardware with tight memory limits. A network OS manages shared servers, printers, and access control.

Single-user and multi-user cuts across that list. Windows on a laptop is single-user: one person at a time. A Linux server is multi-user: many accounts logged in simultaneously, each isolated from the others.

Batch — jobs queued and run without interaction (early mainframes)
Time-sharing / multitasking — CPU sliced between many users (Unix, Linux)
Real-time (RTOS) — hard deadline guarantees (VxWorks, FreeRTOS, QNX)
Distributed — many networked machines presented as one system
Embedded — fixed-purpose, memory-constrained devices (routers, cameras)
Network — manages shared resources and accounts across a LAN
Mobile — power and touch focused (Android, iOS)

Key reference

Terms, operations, and practical uses

System layers

ApplicationA user program that requests services instead of controlling hardware directly.
KernelThe privileged core that manages processors, memory, files, and devices.
DriverKernel-side software that translates a general request into commands for one device.

Managed resources

CPU timeScheduled among runnable threads.
MemoryAllocated, translated, protected, and reclaimed.
Persistent storageNamed through files and directories rather than raw device sectors.
Input and outputQueued and completed through drivers and interrupts.

Why the OS exists

ConvenienceApplications use consistent services across different hardware.
IsolationOne process cannot freely read or overwrite another process's memory.
CoordinationShared resources are assigned without requiring every application to negotiate directly.

Implementation

One program launch, traced through all four OS subsystems

import os, sys

# fork(): ask the process manager for a new process
pid = os.fork()

if pid == 0:
    # exec(): file system finds it, memory manager maps it
    os.execv("/usr/bin/report", ["report"])
else:
    # the shell waits until the process manager reports the exit
    _, status = os.waitpid(pid, 0)
    print("exit status", os.WEXITSTATUS(status))

#include <unistd.h>
#include <sys/wait.h>
#include <iostream>
int main() {
    pid_t pid = fork(); // process manager: new PCB
    if (pid == 0) {
        execl("/usr/bin/report", "report", nullptr); // file system + memory manager
        _exit(127); // only reached if exec failed
    }
    int status = 0;
    waitpid(pid, &status, 0); // block until the child exits
    std::cout << "exit status " << WEXITSTATUS(status) << '\n';
}

import java.io.*;
class Main {
    public static void main(String[] args) throws Exception {
        // the JVM asks the OS for the same fork + exec underneath
        Process p = new ProcessBuilder("/usr/bin/report").inheritIO().start();
        int status = p.waitFor(); // process manager reports the exit
        System.out.println("exit status " + status);
    }
}

Watch it run

Step through it

Running on ./report (a 2 MB program that prints one line)

Output

Read all 9 Steps

You type ./report and press Enter The shell is an ordinary user-mode program. It cannot create a process itself, so it asks the kernel. Nothing has crossed the boundary yet.
Process manager creates the process The kernel allocates a PCB — the record holding the process id, its state, and its saved registers. The process exists, but has no program in it yet.
File system locates the program exec() names a file. The file system resolves /usr/bin/report to an inode and checks that this user has execute permission. A wrong permission ends the launch here.
Memory manager maps the program in Rather than copying the whole binary, the kernel maps the file into the address space. Pages load on demand when first touched, so start-up does not wait for the entire file.
First instruction faults a page in The CPU hits an address with no frame behind it and traps. The memory manager fetches that one page from disk and resumes the instruction — the program never notices.
Process manager puts it on the ready queue The scheduler now owns the process. It shares the CPU between this program and everything else already running, switching between them fast enough to look simultaneous.
The program asks to write output printf reaches a buffer in user space first. Only when the buffer flushes does a write() system call cross into the kernel — the boundary is crossed as rarely as possible.
Device driver completes the I/O The driver translates a general 'write these bytes' request into commands this specific device understands, then signals completion with an interrupt.
Process exits, resources are reclaimed On exit the kernel frees the frames, closes the file descriptors, and wakes the shell that was waiting. Every resource the four subsystems handed out is returned.

Hard real-time versus soft real-time

Real-time does not mean fast. It means predictable. A hard real-time system treats a missed deadline as a total failure — an airbag controller that fires 50 ms late has failed, however quick it is on average.

A soft real-time system degrades instead of failing. A video player that misses a frame deadline drops the frame and continues. Both are 'real-time'; only one turns lateness into a fault.

Hard real-time — missing a deadline is a system failure (airbags, pacemakers)
Soft real-time — missing a deadline degrades quality (streaming, VoIP)
Both prioritise predictability over raw throughput