Importance of Operating Systems: A Guide to Core Functions

You click a browser, a song starts, and a document heads to the printer, all on one laptop. Something has to decide which of those jobs gets the processor, which bytes stay in memory, and what happens when two of them want the disk at once.

That layer is the operating system. It manages the hardware and offers services to your programs, and it is the piece you actually talk to, through icons on a screen or a typed command. The importance of operating systems shows up in that ordinary minute, because without this layer each program would have to drive the keyboard, the disk, and the screen on its own.

This guide covers process states, threads, memory, and device drivers, and then kernel shape, the detail that decides whether a fault in one driver takes every window with it.

Jobs an Operating System Does on Your Machine

An operating system has two faces at the same time. Toward the hardware, it shares the processor, memory, disk, and devices among programs that all want them. Toward your programs, it hides the particulars of one disk or network card behind requests those programs already know how to make.

You meet it through an interface. A graphical interface uses icons and other visual cues, which is the style Windows is known for. A command line takes typed instructions, which is the style of DOS. Programs do not poke the wires themselves. They ask through an application programming interface, the rules and tools for those requests, often shortened to API.

The kernel is the part that stays in charge of the hardware, together with file systems, a memory manager, a process manager, network support, device drivers, and interrupt handlers. The windows you click, and the shell that reads a typed command, sit above that core. Code that may run only with full privilege is a privileged system program. Bootstrap code is the clear case: it is the first code that runs when the machine starts, and the operating system depends on it to load. Code limited to user mode, such as a program that reads the processor status or the system time, is a non-privileged system program. If user-mode code tries a privileged instruction, that instruction does not run.

Kernel mode is the other half of that split, and it is what lets the operating system touch hardware the applications are not trusted to touch. A UC Berkeley lecture in the CS 61C series walks through the same split, from supervisor mode to the calls a program makes when it needs help.

The practical bargain is the one the UC Davis notes on operating system jobs describe: load programs, share the processor by turns, keep a file system, and handle input and output, including the network. Each program gets a place to run, one program is kept from writing over another, and a file or a packet is requested the same way no matter which application asked.

Process Management and the CPU

Once that layer sits between you and the hardware, the next piece is how more than one program can be in progress. A program stored on disk is passive. It is bytes that encode instructions, and nothing is running yet. A process is that program actually in execution: an execution context, plus the code and data of this particular run.

The context is the stuff the processor needs in order to resume the work, including the program counter, registers (very fast storage inside the processor), virtual memory maps, and the resources the operating system has already granted. The processor doing the work can be a real chip or a virtual processor, meaning a core assigned to a virtual machine. Several processes can run copies of the same editor. Each one is separate, and each is usually independent of the others.

The operating system creates processes, destroys them, and schedules them. It also keeps them from interfering with one another, which is process synchronization. One tool for that control is a semaphore, a data type used to gate access to a resource so two pieces of work do not collide on it.

THE THREE PROCESS STATES

• Running: The processor is executing this process right now.
• Ready: The process has what it needs and is waiting for a turn on the processor.
• Blocked: The process is waiting for an event, such as a disk read or a keypress, before it can go on.

A browser drawing a page is running, ready, or blocked depending on the instant you catch it, and the same three words cover the other windows too. While it is drawing, it is running. A music player that is prepared and simply has not been given the processor is ready. A print job waiting on the printer is blocked, because it cannot continue until that event arrives. The scheduler picks the next ready process. When the processor moves from one address space to another, it switches CPU context as well.

Windows and UNIX do not create a process the same way. Windows adds an operating system call that creates the process, plus other calls for the rest of the work. UNIX splits the job into two steps. Fork sets up privileges by making a complete copy of the process. Exec brings the executable file into memory and starts execution.

System programs get the same wrapper as the apps you launched. A print manager, a name server, and a file server are each encapsulated in a process. Background jobs and scripts are too. The click that opened your browser did not skip this machinery. It created one more process for the scheduler to place.

Threads Compared With Processes

A process is the whole running program, and much of the work inside it is smaller than that. A thread is a lightweight portion of a process, managed on its own. It needs fewer resources than a full process, it takes less time to handle, and threads inside one process share memory and data. The process around them stays mostly isolated from other processes.

That split is why a browser can keep several tabs alive without starting a brand-new program for every tab. The tabs can be threads that share the browser’s memory, so opening one more view is cheaper than launching another application. A separate application, with its own files and its own memory, is a different process. A bug in one thread can corrupt memory the other threads of that process are using. A bug in one process is much less free to write into a different process, because those address spaces stay apart.

Memory Management for Each Program

Processes and threads both need a place to keep code and data, which is the memory manager’s job. Programs generate addresses as they refer to instructions and data. That set of addresses is the address space. The memory space is the real main-memory locations the processor can use directly. The operating system manages both, and it keeps the mapping between them.

Virtual memory is what lets a program see a large, continuous block even when physical memory is smaller than that picture. The machine combines physical memory with a portion of the drive that holds the swap file or page file. Pages of address-space information move in and out so the pages of programs that are actually running have room in physical memory.

Primary memory is the processor’s direct working storage, and a program has to reside there to execute. It is volatile, so a power cut clears it. Secondary memory is the long-term store for the operating system, your applications, and the data you expect to find after the power returns. Hard disk drives and solid-state drives are the common examples. Unlike primary memory, that storage keeps its contents when the power is off.

The operating system decides how much physical memory each process gets and when a process has to leave memory. It sets memory aside for variables and for instances of structures, either fixed in advance or handed out while the program runs, and it frees that space when a process is finished and the rest of the system needs the room. Page tables hold the map from virtual addresses to physical ones. Switching the processor between address spaces is part of the same job.

A file is how the long-term store becomes something you can name and open again after primary memory has been cleared. File systems sit beside the memory manager, the process manager, and the drivers. The bytes that left RAM can come back as a document rather than as a raw stretch of the disk, with a name, a place in a folder, and permissions the operating system checks.

Device Drivers and Hardware

Memory answers where the bytes live. Devices answer how a program reaches a keyboard, a disk, or a printer without driving the hardware itself. Keyboards, mice, displays, and USB ports are ordinary devices. In operating-system terms, a file system on disk, a network socket, and the frame buffer for the screen are devices too. A frame buffer is a portion of RAM that holds a bitmap for the video display. A large part of the kernel is concerned with input and output.

Privileges a Device Driver Holds

A device driver is specialized software whose routines talk to one kind of hardware. The operating system offers programs a standard interface, and the driver is what meets the device behind that interface. Drivers are written by the device maker or by open-source contributors, and they support a standard internal interface.

• Start the device: The driver initializes the hardware so the operating system can use it.
• Move the data: It requests input and output on behalf of a program.
• Answer signals: It responds to interrupts and to errors from that device.
• Run trusted: It can execute in the operating system’s address space at high privilege.

That last point is why a driver is not just another application you installed for fun. Ethernet card drivers, video card drivers, sound card drivers, and PCIe drivers for graphics cards and other peripherals all sit in this trusted position. The CPU itself does not need a separate driver for its basic operation, because managing the processor is already a core job of the operating system. Ordinary RAM is managed directly too. Storage devices and network interfaces do need drivers, and flash storage such as SSDs, USB sticks, and memory cards is reached through file-system drivers that organize the data.

Using Device Registers

The driver meets the device through device registers. Each device appears in the machine’s physical address space as a memory address, and the operating system reads and writes those registers to control it. There are three kinds. A status register reports the device’s state. A command register takes a command, such as a value written to start work. A data register moves bytes between the computer and the device.

The bits serve three purposes: parameters the processor gives the device, status bits the device reports, and control bits the processor sets to begin an operation. These registers do not behave like ordinary memory. A start-operation bit may always read as 0, and a status bit can change even though the processor did not write it.

The OpenStax chapter on fundamental OS concepts uses a keyboard register to show the idea: the register is 2 bytes (16 bits), the character sits in the first byte, and bit 15 is the ready bit, set to 1 when you start typing.

1. Start: The processor writes device registers to begin the operation.
2. Poll: The processor checks the ready bit in the device register.
3. Finish: The device sets the ready bit when the operation is done.
4. Place: The processor loads a buffer address so the device knows where to copy data read from disk.
5. Transfer: Fast storage moves data straight to or from physical memory with direct memory access; other devices need the processor, through programmed input and output or through interrupts.
6. Continue: Interrupts let the processor do other work while the device runs, and the operating system figures out which device interrupted.

Printing uses that same handoff. The application gives the document to the operating system, the operating system instructs the printer’s driver, and the driver sends the signals the printer understands. A network application sends messages from process to process through the transport-layer socket API. The operating system splits those messages into packets and passes them to the network interface card, which transmits them.

Why Does the Importance of Operating Systems Depend on Kernel Shape?

A list of jobs stops at device management. The further fact is where the driver code lives. If it shares the kernel’s address space, a fault in it can take process management and memory management down with it. If it sits outside that space, the core has a chance to keep running. That placement is the part worth knowing when a session dies and every window dies with it.

Building an operating system is a hard software problem because the program has to perform well and also stay reliable, extensible, and compatible with older software. Designs that have worked include monolithic kernels, layered systems, a hardware abstraction layer, microkernels, exokernels, and virtual machine monitors. There is no single correct structure. The choice follows the requirements, the trade-offs, and the goals of the machine.

In a monolithic design the whole operating system runs as one integrated unit in kernel space. Process management, file systems, device drivers, and memory management share that same address space, and any module can call another with no extra boundary. Communication is fast, and the cost of those calls stays low. The structure is hard to understand, change, or maintain, and it does not contain faults. A failure in any one component can crash the entire system. Traditional UNIX was built this way.

A monolithic kernel can still be modular. The Linux kernel notes on kernel structure describe components chosen when the kernel is built, plus modules loaded while the system is running, with strict interfaces and low overhead from direct calls. Loading a module is not the same thing as putting that driver in its own protected process. The services still share the kernel’s privilege.

DIJKSTRA’S THE SYSTEM LAYERS

• Layer 5: A job manager executes users’ programs.
• Layer 4: A device manager handles devices and provides buffering.
• Layer 3: A console manager implements virtual consoles.
• Layer 2: A page manager implements virtual memories for each process.
• Layer 1: A kernel implements a virtual processor for each process.
• Layer 0: Hardware, the physical parts of the computer.

Each of those layers can be tested and verified on its own, and calling only downward avoids a loop that wanders across layers. The stack fights real machines, though. A file system needs virtual memory services, and virtual memory wants files for its backing store, so the dependency does not point only one way. Each layer crossing has a performance cost. A system drawn as layers may not have been built that way at all.

The hardware abstraction layer is layering as you meet it when one core has to run on different hardware. It lets the operating system treat a device at a general level instead of baking every hardware detail into the core. Hardware-specific routines stay separate, which makes the core easier to read, easier to maintain, and easier to carry to another machine.

A microkernel keeps the core minimal and adds other functions as plug-ins, with much of what used to live in the kernel moved into user-level processes. Isolation between components improves reliability, less code runs at full privilege, and extending or customizing the system is easier. Performance is generally poor because of the crossings between user and kernel, and those crossings are a security risk when kernel code operates on the data. Hydra, built at Carnegie Mellon, was the first microkernel system. Mach, also at Carnegie Mellon, Chorus, and OS X followed that line.

The MIT lecture notes on microkernels put the hope of this shape in plain terms: a smaller core, a better chance of fewer bugs, a kernel small enough to verify, and services that can be restarted on their own. The notes single out drivers, because moving them out of the kernel means a driver fault need not force a restart of the whole machine. Windows, in the OpenStax account, used a microkernel earlier and uses a hybrid that mixes monolithic, microkernel, and plug-in ideas. Those same Linux kernel notes argue that when the usual services still run in kernel mode, the hybrid label does not change the basic shape, and Linus Torvalds has called that label marketing.

An exokernel pushes the core even smaller and shows hardware details to applications, so each application can manage resources in its own way. That can suit specialized work, and it cuts out steps a general-purpose kernel would insert. The limits are sharp. The design lacks shared abstractions for operating-system services, so consistency across applications is hard, and each application has to handle allocation, protection, and security itself. Cloud services push abstraction the other direction: you rent machines, a developer platform, or a whole application over a network instead of running every layer on the computer in front of you. Virtual machine monitors are yet another structure that has been used, hosting systems that look separate on one physical machine.

Picking a Kernel Shape for Your Machine

With the shapes in view, the useful step is matching one to the computer you actually use, rather than memorizing the names.

KERNEL SHAPES AND THE JOB

• A shared desktop: A general computer in the UNIX line, including Linux, already uses a monolithic kernel, because direct calls keep ordinary work fast and a driver fault is allowed to become a system fault.
• Many kinds of hardware: A core that must run on very different machines leans on a hardware abstraction layer, so hardware-specific routines change and the core stays put.
• A fault that must stay put: When one failing service must not halt the rest, a microkernel matches the job, and you pay the crossing cost for that boundary.
• An app that drives hardware: An exokernel fits only when the application will manage the hardware itself, including protection and security.

The question to ask of any device manager is where the driver runs. If it runs inside the kernel’s address space, its faults are the system’s faults. If it runs as a separate service, the core can keep scheduling other work while that service is restarted. Function lists that stop at “manages devices” never ask you to make that distinction.

Frequently Asked Questions

Can a Computer Run Without an Operating System?

A processor can execute instructions before an operating system is loaded, which is what bootstrap code does in the first moments after you power on. What you cannot do in that moment is open a named file, share the processor between two programs, or print, because those services arrive with the operating system.

What Is a System Call?

A system call is a request from a program that crosses into kernel mode so the operating system can do work the program is not trusted to do itself, such as creating a process or starting a device operation. The call is the doorway. The application programming interface is the set of rules for how the program asks.

Why Does a Computer Feel Slow When Memory Is Full?

Pages have to come back from the drive before a program can continue, and that drive traffic is the pause you feel when primary memory is full. The operating system has moved pages out to the swap file or page file so the programs that are running still have room, then it has to read the needed pages back.

What Is a Semaphore Used For?

Scheduling chooses which ready process runs next. A semaphore is the separate gate on a shared resource, so two processes do not change that resource at the same moment and corrupt the work. It does not rank your programs by importance.

Does the Command Line Replace the Operating System?

The command line does not replace the operating system. It is one way to talk to it, just as a desktop of icons is another way. DOS is a command-line example, and Windows is a graphical example. Under either interface, processes, memory, and devices are still the operating system’s job.

Next time a browser, a music player, and a print job are open together, watch which one is actually running and which one is waiting on a device. The operating system is the reason they can share one processor and one disk. If a driver fault then ends the whole session, that driver was living in the same address space as the rest of the kernel, and the boundary you needed was never there.