Skip to main content
Applications never get unrestricted access to hardware. They can’t write directly to disk, play audio through speakers, or draw pixels on the screen by themselves. The operating system is the gatekeeper that mediates every hardware request.

​
How apps get things done

Apps request services through two related layers:
  • A high-level API (application programming interface): the functions and conventions apps call (for example, “save this file” or “play this sound”).
  • A low-level kernel interface implemented as system calls: the controlled entry points the kernel exposes to perform hardware operations.
When an app calls an API function, that function typically ends up invoking one or more system calls. The kernel validates permissions, and then uses device drivers to talk to physical hardware. Device drivers usually run in kernel space (though some run in user space). Example (typical flow): app → API/library → system call → kernel → device driver → hardware Simple C-style system call example: 
int fd = open("file.txt", O_WRONLY | O_CREAT, 0644);
write(fd, "Hello\n", 6);
close(fd);
A higher-level function such as fopen() or std::ofstream may call open()/write() under the hood. Quick practical check: you can observe system calls made by a utility with tools like strace: 
strace -e trace=open,write ls
Utilities like ls rely on system calls such as getdents, stat, and write to list directory contents and print output.
A presenter wearing a KodeKloud t-shirt stands on the right side of the image. On the left are three purple slide panels numbered 01–03 with text about apps asking for access, the OS acting as a gatekeeper, and protecting your data.

​
Why this design?

There are three primary goals behind this separation of concerns:
GoalWhat it prevents or enables
SafetyPrevents apps from performing arbitrary or malicious operations that could compromise the system or other apps.
SimplicityLets app developers rely on stable, well-documented APIs without needing to know hardware specifics.
StabilityKeeps the OS in control of resources, reducing crashes and data corruption when apps fail.
Quick checkpoint: Which of these best explains how apps interact with your device’s hardware? A. The app uses built-in drivers to manage hardware directly.
B. The app requests services from the OS, which handles hardware access.
C. The OS only gets involved if the app crashes or needs memory. Correct answer: B — apps request services from the OS. The OS enforces permissions and carries out hardware access via system calls and drivers.

​
Input and output: normalized events

Every user action — tapping, typing, clicking, or swiping — starts as raw input from device drivers. The OS interprets those raw events (for example, determining a touch position or a keypress) and dispatches standardized event objects to the focused application or to system subsystems. Output is handled similarly: when an app wants to display text, render graphics, play audio, or trigger haptics, it requests those outcomes from the OS. The OS decides how to draw pixels, mix audio, or route haptics to the appropriate hardware.
A dark slide graphic on the left shows a flow diagram titled "App asks – The OS outputs" with icons for popup, sound, vibrates mapping to Screen, Speaker, and Haptics outputs. On the right a man in a black KodeKloud shirt is standing and gesturing as he presents.

​
Modern input modalities

Operating systems normalize many input types so apps can handle them consistently. Examples include:
Input modalityHow the OS helps
Mouse / Touch / KeyboardTranslated into pointer and keyboard events with coordinates, button/state information.
VoiceConverted to text or commands via speech recognition frameworks.
StylusProvides pressure, tilt, and precise coordinates through a common API.
Game controllersExposed via standardized gamepad APIs with mapping for buttons/axes.
Eye tracking / Face trackingNormalized gaze or face landmarks exposed as events or state objects.
A slide shows a colorful OS graphic with icons and labels for Voice, Stylus, Gamepad, and Eye tracking. A presenter stands to the right wearing a black KodeKloud t-shirt and gesturing toward the slide.
Because the OS exposes consistent event formats and APIs, application developers rarely have to write custom code for each hardware model. Instead, they handle canonical events and let the OS map device specifics to those events.

​
Accessibility as a core feature

Accessibility features are integrated into every major OS, not bolted on as optional extras. Common accessibility capabilities include:
  • High-contrast and large-text modes for low-vision users
  • Screen readers and text-to-speech for blind users
  • Closed captions and audio descriptions for hearing-impaired users
  • Voice control and alternative input methods for motor impairments
  • Speech-to-text and dictation for users with speech differences
Many accessibility features also benefit general users: dark mode, captions, dictation, and system-wide zoom are broadly useful beyond assistive scenarios.

​
Recap

  • Users interact with the OS through graphical and command-line interfaces.
  • Apps are managed by the OS and request services via APIs that invoke system calls.
  • The OS normalizes diverse inputs and routes outputs, providing a single, stable interface for apps.
  • Accessibility is a first-class OS responsibility to make devices usable for more people.
Key idea: Apps ask, the OS decides, and the kernel (via system calls and drivers) talks to the hardware. This separation provides safety, simplicity, and stability.
In the next lesson we’ll examine how the OS schedules work, manages processes and threads, and allocates resources behind the scenes.

Watch Video