Introduction to Operating Systems

At its most fundamental level, an Operating System (OS) is a collection of software that manages computer hardware resources and provides common services for computer programs. It acts as an intermediary between users/applications and the computer hardware. Without an OS, every programmer would need to write code to directly manipulate disk read-heads, manage voltage levels for memory cells, and handle the intricate timing of network hardware.

The Core Responsibilities

An operating system typically fulfills four primary roles:

1. Resource Manager: The OS allocates resources—such as CPU time, memory space, and file storage—to specific programs and users. It ensures that no single process can monopolize the system or interfere with others.
2. Hardware Abstraction Layer (HAL): It provides a consistent interface to diverse hardware. A program can “write a file” to a disk without knowing whether that disk is a spinning platter HDD, a NAND-flash SSD, or a network-mounted drive.
3. Process Coordinator: It manages the execution of multiple programs simultaneously, a feat known as multitasking. This involves scheduling processes, handling interrupts, and facilitating inter-process communication (IPC).
4. Security and Protection: The OS enforces boundaries. It prevents a browser tab from reading your bank password stored in a password manager’s memory space and ensures that users can only access their own files.

For example, standard file writing avoids interacting with physical storage tracks and cylinders directly. Instead, programmers use high-level file system abstractions provided by the OS:

#include <stdio.h>

// Example demonstrating Hardware Abstraction:
// Writing a message to disk without manual sector/head addressing.
int main() {
    FILE *file = fopen("log.txt", "w");
    if (file == NULL) {
        perror("Failed to open file");
        return 1;
    }
    fprintf(file, "LibreUni: Hardware Abstraction Example\n");
    fclose(file);
    return 0;
}

The Dual Mode Operation

A critical concept in modern OS design is the distinction between User Mode and Kernel Mode. This is hardware-supported (via a “mode bit” in the CPU) and is essential for system stability.

• User Mode: Applications (like Chrome, VS Code, or a game) run in User Mode. They have restricted access to hardware. If an application crashes, it only affects that application’s memory space.
• Kernel Mode: The OS kernel runs in Kernel Mode. It has unrestricted access to the hardware and memory. If the kernel crashes, the entire system “Blue Screens” or “Kernel Panics.”

When an application needs to perform a privileged operation (like reading a file or sending a packet), it must perform a System Call. This triggers a transition from User Mode to Kernel Mode, where the OS validates the request, performs the action, and then returns control to the application.

An example of assembly code executing a system call on an x86-64 CPU shows the mode transition path:

; Example of a system call invocation in x86-64 assembly.
; This code writes "Hello" to stdout and triggers a mode transition.
section .data
    msg db 'Hello', 0xa
    len equ $ - msg

section .text
    global _start

_start:
    mov rax, 1          ; System call number for sys_write
    mov rdi, 1          ; File descriptor 1 (stdout)
    mov rsi, msg        ; Pointer to message buffer
    mov rdx, len        ; Number of bytes to write
    syscall             ; Privilege transition: User Mode -> Kernel Mode

    mov rax, 60         ; System call number for sys_exit
    xor rdi, rdi        ; Exit code 0
    syscall             ; Privilege transition: User Mode -> Kernel Mode

participant "User Application" as app
participant "System Call Interface" as sci
participant "OS Kernel" as kernel
participant "Hardware" as hw

app -> sci : request(read_file)
activate sci
sci -> kernel : trap to kernel mode
activate kernel
kernel -> hw : read disk sectors
hw --> kernel : data bytes
kernel -> kernel : copy to user buffer
kernel --> sci : return success
deactivate kernel
sci --> app : return data
deactivate sci

Components of an Operating System

While internal architectures vary, most systems share these core components:

1. The Kernel

The “heart” of the OS. It is the first part of the OS to load and remains in memory. It manages the CPU, memory, and devices. Modern kernels are often categorized as Monolithic (like Linux/Windows) or Microkernels (like Mach/Minix).

2. The Shell and GUI

The user interface. The shell is a command-line interpreter (like bash or PowerShell), while the GUI (Graphical User Interface) provides windows, icons, and menus.

3. System Libraries

These are standard functions that applications use to interact with the kernel (e.g., libc in Unix-like systems or the Win32 API in Windows).

4. Device Drivers

Specialized programs that allow the kernel to communicate with specific hardware devices. The driver “translates” generic OS commands into device-specific instructions.

An example in C demonstrates how System Libraries wrap low-level kernel transitions:

#include <unistd.h>
#include <string.h>

// Example demonstrating System Library wrapper usage to communicate with the Kernel:
int main() {
    const char *msg = "Invoking write() via glibc\n";
    // write() wraps the low-level sys_write syscall
    write(STDOUT_FILENO, msg, strlen(msg));
    return 0;
}

The Boot Process (Bootstrapping)

How does the OS start? When you press the power button, the CPU is in a primitive state and must be “bootstrapped” into a fully functional environment. This involves a hand-off between several layers of software:

1. BIOS/UEFI: Firmware that performs a Power-On Self-Test (POST) and initializes basic hardware.
2. Bootloader: A specialized program (like GRUB) that loads the OS kernel into memory.
3. Kernel Loading: The kernel takes control, initializes drivers, and sets up memory management.
4. Initialization: The kernel launches the first process (PID 1), which starts the rest of the system.

For a deep dive into these mechanics, see the System Initialization & Booting module later in this course.

An example flowchart maps the execution control flow and processor modes during bootstrapping:

Boot Sequence and Mode Transitions:
+-------------------+      [16-bit Real Mode]
| 1. Power On / POST| ---> CPU starts at Reset Vector (0xFFFFFFF0)
+-------------------+
          |
          v
+-------------------+      [16-bit Real Mode / 32-bit Protected Mode]
| 2. Bootloader     | ---> Load MBR / read partition, load kernel image
+-------------------+
          |
          v
+-------------------+      [64-bit Long Mode]
| 3. Kernel Load    | ---> Kernel takes control, initializes virtual memory
+-------------------+
          |
          v
+-------------------+      [64-bit User Mode]
| 4. PID 1 / init   | ---> Start systemd or launch user shell / GUI
+-------------------+

Operating systems have evolved from simple “batch processing” systems in the 1950s—which ran one job at a time—to the highly sophisticated, distributed, and real-time systems we use today across laptops, smartphones, and cloud servers. In the following modules, we will dive deeper into the mechanics of how these components work together to create the seamless experience of modern computing.

Interactive Practice: Operating System Core Concepts

Test your understanding of operating system definitions, responsibilities, and execution modes.

References & Further Reading

• Operating system (CC-BY-SA 4.0)
• Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts (10th ed.). John Wiley & Sons.
• Tanenbaum, A. S., & Bos, H. (2014). Modern Operating Systems (4th ed.). Pearson.