What an Operating System Does: The Manager Between Apps and Hardware

A music application should not need to know the electrical command format of every sound device ever manufactured. A text editor should not decide which physical flash cells store a document. Every program should not be allowed to read every other program's memory.

The operating system solves these problems.

An operating system manages hardware and shared resources, protects programs from one another, and provides common services that applications can request.

Windows, macOS, Linux, Android, and iOS differ in design and ecosystem, but they all perform versions of these responsibilities.

The abstraction layer

Hardware is detailed and varied. Applications want stable concepts:

• Open a file
• Draw a window
• Play audio
• Send network data
• Allocate memory
• Read keyboard input

The operating system and its drivers translate these general requests into device-specific work.

This separation is an abstraction. It hides unnecessary detail behind a manageable interface.

A music app asks an audio framework to play samples. The OS routes audio among applications, applies volume settings, and hands data to the correct driver. The driver controls the actual device.

Without this layer, each application would need custom support for every hardware combination.

Managing processor time

Several programs can be active even when the computer has only a few CPU cores.

The operating system scheduler:

• Tracks runnable tasks
• Assigns them to cores
• Gives them time slices
• Responds to priorities
• Pauses and resumes execution

Rapid switching creates the experience of multitasking. On multiple cores, some work genuinely runs at the same instant.

The OS also handles interrupts from timers and devices, regaining control when events occur.

Managing memory

Applications request memory without knowing which physical RAM chips or locations are involved.

The operating system:

• Gives processes virtual address spaces
• Maps virtual pages to physical RAM
• Enforces access permissions
• Shares selected memory safely
• Reclaims memory when processes finish
• Moves inactive pages to storage when necessary

Isolation is crucial. A bug in one ordinary process should not freely overwrite the operating system or another application's private data.

Hardware memory-management features and the kernel cooperate to enforce these boundaries.

Organizing files and storage

Raw storage exposes numbered blocks. A file system creates higher-level structures:

• Files
• Directories
• Names
• Paths
• Permissions
• Timestamps
• Free-space tracking

When an application saves a document, the OS and file system decide where its data and metadata belong on storage.

The system may cache writes for performance, so safely ejecting removable media gives the OS time to finish pending work.

File systems also attempt to recover from interrupted operations through techniques such as journaling or copy-on-write structures.

Devices and drivers

Hardware devices expose different command sets. Drivers translate operating-system operations into device-specific communication.

The OS:

1. Discovers a device.
2. Matches it with a driver.
3. Allocates resources.
4. Exposes a standard interface to applications.
5. Handles completion events and errors.

For example, an application can print through the system's printing APIs. The printer driver converts standard page instructions into commands the printer understands.

Drivers often run with high privilege, so defective drivers can crash or compromise the whole system.

Users, identity, and permissions

Multi-user operating systems distinguish accounts and security identities.

They control:

• Who may sign in
• Which files a user can access
• Which settings can change
• Whether an application may use the camera or microphone
• Which actions require administrator approval

An administrator account is not intended for every action without question. Elevation prompts create a boundary around sensitive changes.

Mobile operating systems add application sandboxes and permission prompts so one app does not automatically receive another app's data or every device sensor.

Networking services

The operating system implements network protocol stacks and exposes sockets to applications.

An application can request:

• A connection to a server
• A listening endpoint
• A packet to be sent
• Name resolution

The OS coordinates the network adapter, routing table, firewall, protocol state, and competing applications.

It also provides Wi-Fi and cellular management, virtual private network support, and network-interface configuration.

Applications still implement higher-level protocols such as HTTP, but they rely on lower networking layers supplied by the OS.

User interface and system services

The graphical desktop is one visible part of an operating-system environment.

It commonly includes:

• Window management
• Application launching
• Notifications
• Clipboard
• Search
• Settings
• Accessibility
• Input methods

Background services provide time synchronization, logging, updates, indexing, printing, Bluetooth, and many other capabilities.

Not every operating system has a graphical interface. Servers and embedded devices may use command-line or specialized interfaces while retaining the same underlying management roles.

A concrete example: joining a video call

Starting a video call involves many OS services:

1. The app requests camera and microphone permission.
2. Drivers deliver captured video and audio.
3. The scheduler gives processing time to encoding threads.
4. Memory management allocates buffers.
5. Networking sends encrypted media packets.
6. Audio output is mixed with other system sounds.
7. The window system displays remote participants.
8. Power management adjusts performance.

The application provides call behavior and interface. The OS supplies managed access to the machine.

APIs and system calls

Applications interact with operating-system services through interfaces.

A system call is a controlled transition into the privileged kernel for operations such as reading a file or creating a process.

Applications usually use higher-level libraries:

application
    ↓
framework or library
    ↓
system call
    ↓
kernel
    ↓
driver and hardware

These layers improve portability and usability. A developer can call a standard file API instead of constructing raw kernel requests manually.

Different operating systems

Operating systems make different choices about:

• Kernel architecture
• User interface
• Application distribution
• Security policy
• Hardware support
• File systems
• Update strategy
• Openness and customization

No single operating system is best for every purpose. A phone prioritizes battery life, touch interaction, radios, and app sandboxing. A server may prioritize remote administration, stability, automation, and throughput.

The shared concepts are more durable than any particular product interface.

Common misunderstandings

"The operating system is only the desktop"

The desktop is one user interface. Resource management, files, networking, drivers, and security continue underneath.

"Applications directly control hardware"

Some specialized software has low-level access, but ordinary applications usually go through OS APIs and drivers.

"Closing a window always ends the application"

An application may keep background processes or services running, depending on its design and the operating system.

"Administrator access removes every restriction"

It grants broad OS permissions but does not bypass encryption keys, hardware controls, remote policies, or every security boundary.

Knowledge check

The one idea to remember

The operating system is the computer's resource manager and shared service layer.

It turns diverse hardware into stable application interfaces while coordinating access, security, files, memory, processing, devices, and networking.

Next, we will examine the privileged kernel at the center of those responsibilities.