Operating Systems: Services, Interfaces, and Structures

2.1 What Is an Operating System

2.1.1 What an Operating System Does

Every course on operating systems starts with the same three questions. What is an operating system — the master program that controls the whole computer? What are the components of the system? And what are the various responsibilities of the operating system?

The main answer is that the operating system is a resource allocator — the thing that decides who gets what. A computer system has many resources that may be needed to solve a problem: CPU time, memory space, file-storage space, I/O devices, and so on. Facing many and possibly conflicting requests for these resources, the operating system must decide how to allocate them to specific programs and users so that the computer runs efficiently and fairly.

Apart from allocation, the operating system manages the memory, it manages processes, it handles free space management, and it takes care of many more things:

• Memory management — deciding which part of memory each running program occupies, and keeping programs from trampling over one another.
• Process management — creating, scheduling, and ending the programs in execution.
• Free space management — tracking which areas of the disk are free and which are occupied, so new files can be placed somewhere sensible.
• Device management — coordinating the use of every device attached to the machine.

Think about the hardware for a moment. All the devices connected to a system need the support of the operating system for smooth coordination with the rest of the machine. That includes the disk, the keyboard, the display, everything. In that sense, the system is the hardware, and the operating system acts as its manager. Every device that is attached to the system has to go through the operating system, which decides when and how the device is used.

Visual intuition: Picture a vertical stack. At the bottom is the hardware — the CPU, memory, disk, keyboard, display. In the middle is the operating system, drawn as a full-width band because every device and every program must cross it. At the top sit the application programs and users. Requests travel downward through the operating system to the hardware; results travel back up. The landmark of this picture is the middle band: nothing passes between top and bottom without its permission — that is the whole point of the manager.

2.1.2 The Roadmap of This Session

This session walks a single path through the subject. First come the services the operating system provides, both to users and to the system itself. Then we look at the interface between the user and the operating system, and at system calls — the low-level functions through which programs ask the operating system for work. After that come the types of system calls, and then the system programs that ship with an operating system. Next we consider how an operating system is designed and implemented. That leads to the overall structures of operating systems — the different ways the pieces can be organized — and the session concludes with debugging and failure analysis.

The path in brief:

1. Services — what the OS does for users (2.2) and for the smooth running of the system itself (2.3).
2. The overall view — how a user's request flows from interface to kernel to hardware and back (2.4).
3. Interfaces in practice — command line, GUI, touch, and voice (2.5).
4. System calls and the API — how programs ask the OS for work, with a fully worked file-copying example (2.6).
5. System programs — the utilities shipped with the OS (2.7).
6. Design and implementation — goals, policy versus mechanism, and implementation languages (2.8).
7. Structures — simple, layered, microkernel, modular, hybrid, and mobile arrangements (2.9).
8. Debugging and failure analysis — finding and fixing errors when things go wrong (2.10), and portability and booting (2.11).

The first few sessions stay mostly theoretical. Once processes get involved — from about the fourth or fifth session onward — many real problems appear, and things get more interesting. So the foundation being built now matters later.

Real-world & domain connection: Every system you touch runs one of these designs. A Windows laptop, an Ubuntu workstation on WSL, an iPhone, and an Android phone all provide the same class of services — program execution, I/O, file management, communication, error detection — through different structures. When you later debug a slow server or a crashing app, you are using the very debugging and failure-analysis tools (2.10) this roadmap ends with. The roadmap is not a tour of trivia; it is the map of every operating systems course, and it frames how professionals reason about real systems when things go wrong.

2.2 Operating System Services: The User-Facing Set

The operating system provides an environment where programs can execute, and where one program can get the services of another program. The services it offers to users fall into six groups.

The six user-facing services are: user interface, program execution, I/O operations, file system implementation, communication, and error detection.

2.2.1 User Interface

Almost every operating system you have seen has a user interface — the part of the system you actually interact with. Windows is the very obvious example; Unix systems such as Ubuntu also have one, with a desktop. You can click on things to get information, or you can go to the terminal, type something, and get the information back.

The interface differs in form:

• A command-line interface (CLI), where you type commands and get the output. The program that accepts those typed commands is a command interpreter (the shell), discussed in depth in section 2.5.
• A GUI — a graphical user interface — where you click and get the output. The GUI is a window-and-menu system driven by a mouse or other pointing device, built on a desktop metaphor.
• Batch processing, where more than one process runs either in the background or in the foreground without you interacting with each one individually. Commands and their control directives are written into files, and the files are executed in sequence by the system.

Some systems provide two or even all three of these variations at once — Windows has a GUI plus a command prompt, and Ubuntu offers a desktop plus a terminal.

2.2.2 Program Execution

The operating system must let you load a program into memory and run it. When the program runs normally, everything proceeds on its own. When something goes wrong — abnormal termination, an error inside the program — the error has to be indicated in some way. Usually it is indicated by interrupting the services the operating system is providing. At that point you either kill the application that is running or suspend that particular process. The exact mechanisms for doing all of this are studied later.

2.2.3 I/O Operations

Every program that runs requires I/O — input/output. The input or output can come in the form of a file: the program needs to open the file, read information from it, and write information back to it. Or the I/O can involve any external device connected to the system — a keyboard, a mouse, or a printer as an output device. Any one of these devices is required to perform the input/output operation, and providing these I/O services is one of the operating system's responsibilities.

Why can't the program talk to the printer directly? For efficiency and protection, users usually cannot control I/O devices directly — a program that writes directly to the disk could destroy files belonging to other users, and a program that grabs the printer could lock out everyone else. So the operating system provides a controlled means to do I/O: the program requests the operation through a system call, and the operating system performs it on the device.

2.2.4 File System Implementation

The file system is how files are stored and organized, in the form of directories. With it, many files can be created, deleted, or searched for; you can list what files are available, and you can manage the various permissions on them. Some files cannot be accessed by everyone — only the administrator can access them. That permission management is performed by each and every operating system.

The file system service so covers four things:

1. Create and delete files and directories by name.
2. Read and write the contents of files.
3. Search and list — find a given file, or list the files and their information in a directory.
4. Permission management — allow or deny access to files and directories based on ownership, so that, for example, only the administrator can read a system configuration file.

2.2.5 Communication

The operating system supports process-to-process communication. Any number of processes can exchange information on the same system, or between systems if they are connected in a network. If they are on a network, the information may have to be broadcast. Three general mechanisms exist: we can send a signal, we can use shared memory, or we can use message passing.

• Signal — a small, one-way notification sent to a process (for example, telling it that an event happened or to stop).
• Shared memory — a region of memory that two or more processes agree to share; each process reads and writes that region directly. Shared memory can be accessed by any number of processes, though there are restrictions that are dealt with later. Because the data is read and written at memory speeds, this is the fastest mechanism, but the processes themselves are responsible for not writing to the same location at the same time.
• Message passing — the message, in the form of a packet, is sent from one system to another system, with the operating system moving the packet between the two processes. This is safer and easier to implement across a network, but slower for large amounts of data, because every exchange passes through the operating system.

Broadcasting information can also be done by way of a signal or message passing. All of this is studied in detail later, in the sessions on processes and inter-process communication.

When to pick which: use signals for tiny one-way events, shared memory for high-volume data exchange between processes on the same machine, and message passing whenever the processes live on different machines or when the data volumes are small.

2.2.6 Error Detection

Error detection means the operating system constantly keeps track of the errors that may possibly occur. The error can occur in the CPU, or in the hardware — in the memory of the hardware — or in an I/O device. Whatever error occurs, the operating system has to take appropriate action for the smooth functioning of the system. This error detection facility should act as a debugging facility, because it enhances both the user's ability and the programmer's ability to use the system efficiently. Since the operating system provides all these services, this facility should be present in each and every operating system.

Errors come from three places:

• CPU and memory hardware — for example, a memory error, an illegal memory address access, or a power failure.
• I/O devices — for example, a printer running out of paper, a network connection failing, or a disk error.
• User programs — for example, an arithmetic overflow, a divide by zero, or a program using too much CPU time.

For each type of error, the operating system takes appropriate action so the computation stays correct and consistent. That action may be to report the error to the user, to end the offending program, to retry the operation, or to record the event in a log for later analysis — the topic of debugging and failure analysis in section 2.10.

Real-world & domain connection: These six services are what make ordinary computing possible. When a browser downloads a file, it is using program execution, I/O, the file system, and communication all at once — and if the network drops mid-download, error detection is what triggers the "download failed" message. The same six services appear in every operating system you will ever touch, from Windows desktops to Android phones to the embedded systems in cars and routers, which is why every operating-systems course teaches this list first.

2.3 Operating System Services: Running the System

A second set of functions exists for the smooth operation of the system itself: resource allocation, accounting, and protection and security.

These three functions are not for any single user's convenience — they exist to keep the whole system healthy, fair, and safe when multiple users and processes share it.

2.3.1 Resource Allocation

Resource allocation was introduced in the previous session, and is covered in detail in the coming sessions. The problem is easy to state. Suppose there are three processes, P1, P2, and P3. All three are in need of a particular resource. The resource can be a variable, or it can be a record, or it can be a file — anything. All three processes are competing for this one resource. The operating system has to decide how the resource can be efficiently allocated among the three, or among any number of processes. That is what resource allocation means.

2.3.2 Accounting

Accounting means the operating system keeps track of how many users there are and what kind of resources they are using. If one user is consuming far more CPU time or memory than the others, the accounting records show it. These records are useful both for billing and for spotting problems.

2.3.3 Protection and Security

Protection and security form one of the services, and both are needed because we work in a multi-user, multitasking environment where people may be on a network. The other processes should be protected, and other processes should not interfere with each other. When any number of processes run at the same time — concurrent processes — each should not interfere with the resources the others are accessing. They should be able to access a particular resource without any conflict; that is the protection part. The security part says that outsiders cannot access the system as such. Proper authentication should be there, so that the system is defended from external I/O devices and from that kind of invalid access.

Real-world: in this respect, UNIX is more secure when compared to Windows. That judgment comes from hands-on experience with those two systems. You can think through these services for any other operating system in the same way.

Exam note: Resource allocation is foundational and is covered in detail in the coming sessions — the basic picture built here (competing processes, one resource, an allocator that decides) will be the foundation for scheduling and deadlock topics later, so make sure it is clear now rather than memorized.

Real-world & domain connection: These three services run silently on every shared machine you have used. A university lab server allocates CPU among hundreds of student processes, its accounting records decide who to charge or throttle, and its authentication system (login + password) is the security gate. Cloud providers such as AWS and Azure operate on exactly this trio at industrial scale: allocation decides how many virtual CPUs a customer's instance receives, accounting produces the usage bill, and protection and security isolate one customer's processes from another's.

2.4 The Overall View: User, System Calls, and Hardware

2.4.1 The Flow from User to Hardware

Here is the overall view of how the whole interaction takes place between the hardware and the user. It happens in terms of three things: the user interface, system calls, and services.

When a user runs a particular program — it can be any system program or application program — everything has to go through one of these interfaces. Going through the interface causes a system call to be made. The system call can be I/O-related, it can be file-related, or it can be a resource-oriented system call. One of the system calls is then activated.

When a system call is made, a call is made to the operating system. Automatically the system goes to kernel mode — the privileged mode of the CPU where the operating system itself runs. It starts executing that particular file or program, and in turn it interacts with the hardware, sends the request, and gets the response back to the user. That is the complete loop.

Visual intuition: Picture a vertical pipeline with four lanes, drawn top to bottom: user interface → system call → kernel → hardware. The request is a marble dropped at the top. It rolls through the interface lane, enters the system-call lane where the mode switches from user to kernel (mark this point on the drawing — it is the only place where the marble changes lanes from user world to kernel world), then rolls through the kernel lane where the OS executes it against the hardware, and the result returns up the same path. The one-sentence takeaway: every user action is a round trip through the kernel.

2.4.2 Interfaces and System Call Types

So the user interface — whether GUI, batch, or command line — always funnels into system calls. The services are what the operating system provides through those calls, and every one of the services seen earlier is delivered this way. The details of the system calls themselves are the next topic.

Real-world & domain connection: When you press Ctrl+S to save a document, the editor's interface issues a file-related system call (write), the CPU switches to kernel mode, the kernel writes your file to disk, and control returns — all within milliseconds. When a security tool on your machine monitors which programs access the network, it is watching this exact funnel: every network action by any program must pass through the kernel in kernel mode, which is why the OS is the natural chokepoint for enforcing permissions. Understanding this single loop is the key to later topics such as process scheduling, virtual memory, and security, which all live inside the kernel lane of the diagram.

2.5 User Interfaces in Practice

2.5.1 The Command-Line Interface

A live demonstration shows the command-line interface in action. The demo system is WSL — the Windows Subsystem for Linux. Windows provides it so that you can install and run Ubuntu inside Windows without occupying much of the space, and without using a full virtual machine like VMware. With WSL you can directly run Linux commands and any type of Linux program.

In this interface you type commands in a terminal. The place where you type the information or the command is called the shell, and the shell is a command interpreter. The prompt is the symbol that signals the shell is ready, and after the prompt you type the command. The shell understands the command and sends the request to the kernel — the heart of the operating system. The kernel sends the information to the hardware, gets the response back from the hardware, and passes it back to the shell, where you see the output. This is how the whole chain works: command, shell, kernel, hardware, and back.

Real-world example: On WSL, typing ls at the prompt shows the files in the current directory; typing date shows the current date and time. Each command name identifies a small program that the shell loads and the kernel runs — you can watch the whole command → shell → kernel → hardware chain happen live, with output returning to your terminal.

2.5.2 The Shell and Its History

The shell shown in the first demo is the default shell found on Ubuntu. That shell is the Bourne shell — more precisely Bash, the Bourne Again Shell, so named because Bourne is the author who created the original Bourne shell. The second example prompt in the demo was captured on a Mac, which you can recognize from the prompt itself; the same kinds of commands work there.

2.5.3 The Graphical User Interface

Most of you already know the GUI. It is a very user-friendly desktop metaphor interface: you have a mouse, a keyboard, and a monitor, and you have icons. The icons represent either a program, or a file, or any type of action that can be performed; you just click an icon. The GUI was originally invented at Xerox, and now many versions exist: Microsoft Windows, and Apple's Mac OS with its Aqua interface. UNIX and Linux have both a command-line interface and a GUI. Windows is the most widely used operating system — roughly 64% of the usage — then come the Unix-family systems, then Mac.

2.5.4 Touch and Voice Interfaces

A touch screen interface exists on some devices, and some laptops also have that facility: you directly touch the screen and click instead of using a mouse, or you click directly on the icon to open the file or app. Voice-based commands are also possible — nowadays even some display-based devices have assistants like Alexa, where you talk and get the information. These interfaces matter in specific situations: when there is no possibility of a mouse, or when the mouse is not required. That happens when the selection or the action has to be done based on a gesture, when there is only a virtual keyboard for entering text, or when you have a voice-based commanding system. Otherwise they are not required.

Real-world: the practical message is that one operating system can host all of these — click, type, touch, or speak. The choice of interface depends on the device.

Real-world & domain connection: Every interface style above is in daily use in industry. System administrators manage cloud servers almost entirely over SSH command lines (because servers have no screen); desktop users interact through GUIs; warehouses and hospitals use touch screens where gloves or space make mice impractical; and voice assistants such as Alexa sit in millions of homes. All of them — from an AWS server console to a smart speaker — end at the same place: the kernel of the operating system underneath.

2.6 System Calls and the API

2.6.1 The API

A system call is the service provided by the operating system to running programs. The API — the application programming interface — is the programming interface through which programs reach it. The API is written in a higher-level language; it can be any higher-level language, such as C or C++. If you have an application, you can embed system calls using the API rather than calling the system calls directly. Very common examples of APIs are the Win32 API for Windows and the POSIX API for POSIX-based systems. POSIX is present in all Unix, Linux, and Mac OS X systems. The Java API for the JVM is another example. Through these APIs you can use the system.

The three most common APIs are:

2.6.2 What a System Call Is

Whenever you have to get some information, or perform some action, you have to make a system call. The system call takes the form of a function, just like a normal function. By seeing the name of the function, you know what type of action it is going to perform. The classic example shows a sequence of system calls that copies the contents of one file into another.

2.6.3 Worked Example: Copying a File with System Calls

The sequence of system calls for copying a file works like this:

1. First, try to get the information from the input file — find out that the source file exists and is readable.
2. Once the input is accepted, try to get the information about the destination file.
3. Once both pieces of information are available, open the source file. If the file does not exist, come out — the program stops there.
4. If the file exists, read the input file and write the contents into the destination file.
5. This read-and-write loop continues until the end of the file is reached, or until the read phase completes.
6. Close the output file and also the input file.
7. Whatever has been written can be printed, if you want.
8. The program ends.

This is how the copying of information from one file to another happens in terms of system calls. And this is not the only thing a system call can do. The system call is a general tool, capable of performing whatever we do with the help of the command-line interface or with respect to the GUI. You can create a directory, you can change the permission of a file, and many more things besides opening, reading, and writing files. Most of the things you can do with the system can be done through system calls.

2.6.4 The read() System Call in Detail

Look at the read system call as a concrete example. In C programming, you have to include the general file unistd.h. read is the function name. What does it return? It returns some amount of bytes as the return value. You have to pass three parameters. First, the file descriptor of the file — a number the operating system uses to identify the open file. Second, the name of the buffer, where the data is to be placed. Third, the amount of data that you are going to copy.

Suppose the read system call succeeds and you are reading 30 bytes of data. Then 30 is the return value of this function. If there is any error, it returns −1. Each system call has its own function and its own return type; the return type varies from one system call to another. A number is associated with each and every system call, but you need not know that number, and you need not know how the call is implemented. The only thing you need to know is the work this particular system call performs; the rest of the implementation is hidden from the user. The calls are also supported by runtime libraries — hidden support libraries included by the compiler in order to implement the system calls.

2.6.5 How a System Call Executes

The visual for this shows the relationship between the system call and the operating system. A user application, in user mode, tries to use a system call such as open(). As soon as this system call is given, the system call interface changes the environment from user mode to kernel mode. The system goes and finds where the implementation is, does its work, and returns. As soon as it returns, the environment goes back to user mode, and you get the output. That is the interface between the system call and the operating system.

Visual intuition: Draw a horizontal line across the middle of the page: user mode above, kernel mode below. The application runs above the line. When it calls open(), an arrow crosses the line downward — this crossing is the system-call interface, which switches the CPU from user mode to kernel mode. Below the line the OS locates the implementation of the call, performs the work, and the arrow returns upward, switching back to user mode. The one-sentence takeaway: every system call is a round trip across the user/kernel boundary, and the system-call interface is the gatekeeper on that boundary.

2.6.6 Parameter Passing

Some system calls need parameters passed to them, as we saw with read() and with creating a directory. Sometimes the parameters are simple enough to be placed in registers — the small, fast storage areas inside the CPU. If there are more parameters, or the parameter size is larger — in terms of a block, or a table, or an address to the block — then the parameters have to be pushed onto the stack, and later popped from the stack by the system. There is no limit on the length of the parameter list in terms of blocks or stack. Only in some cases will the registers be used, because the registers are limited: if the parameters are very simple in terms of size, we can use the registers. Parameter passing may also be done via a table. Whichever way it is passed, the operating system goes and gets the parameter — from the register, or from the table — and loads and executes it. The user does not execute it; the operating system does. The user only needs to give the right system call with the right parameters.

2.6.7 Categories of System Calls

The different types of system calls depend on what we are doing:

• Process control. Create a process, terminate it, end, abort, load, execute, get the attributes of the process, set the attributes of the process, wait for a process, wait for a signal or an event, allocate or free memory. A debugger will also try to do single-step execution of the code.
• File management. Create a file, delete a file, open, close, read, write, reposition (that is, seeking within the file), get file attributes, and set file attributes.
• Device management. Request a device, release the device, read from the device, write to the device. All of this can be done with the help of system calls.
• Information maintenance. Get the time or set the time and date, get the system data or set the system data, get or set the process, file, and device attributes.
• Communication. Communication between processes happens by sending and receiving messages — there is a send system call and a receive system call. If you have studied network programming, you know that a socket has to be created between the two systems: the socket is the endpoint of the communication. An endpoint is created on one system, and another endpoint on the other system. The request is sent from one system to the other, and the response comes back. That is client-server communication; peer-to-peer communication also exists. All of this is used in client-server programming. If a shared memory has to be created, the system call attaches the memory and detaches it, and the operating system keeps track of the processes accessing the shared memory.
• Protection. Controlling access to the resources — giving the permissions, setting the permissions, denying the user access, or allowing the access.

Exam note: the categories of system calls and their functions are core material, and they are studied in greater detail in later sessions.

Real-world & domain connection: These categories are what programmers use every day: fork/exec (process control) run every program you start; open/read/write (file management) power editors and databases; socket/send/recv (communication) carry every web request; chmod (protection) sets file permissions; time (information maintenance) stamps logs. If you want elaborate information about system calls, there is a book called Advanced Programming in the UNIX Environment, which covers them in depth — it is the standard reference that professional Unix and Linux developers keep on their desks.

2.7 System Programs

2.7.1 The Categories of System Programs

System programs are the programs that are already there in your system. They provide an environment for development and execution, and they divide into a few groups:

• File manipulation. Text editors and word processors — a notepad, or in Microsoft terms a spreadsheet, a presentation, or a Word document.
• Status information. The date and time, the amount of memory, the disk space, or any other information about the system, including logging and debugging information. Some systems implement a registry — a place used to store and retrieve configuration information — and these details are available through system programs.
• Language support. Example: compiling. This is a system program. To run a program written in a particular programming language, you need a compatible compiler — one compatible with the architecture or the processor of your system. Only with a compatible compiler can you run the program. Not all operating systems will allow you to store or run the system program in terms of a compiler or assembler.
• Program loading and execution. The loader, the relocatable loader, and linking loaders take care of getting a program into memory and running it.
• Communication. Networking-related programs that provide virtual communication among processes, users, and systems.
• Background services. After the desktop appears, you can see, on the bottom-right, the date being displayed — which means that particular service is running. Some things are automatically started at startup, because what has to be done after startup has already been programmed by a system program that starts running them.
• Application programs. Applications such as a browser are installed in the system and started by the user; they are not a part of the operating system.

System programs are programs, not the actual system calls, and they range from very convenient small programs to very complex ones. A compiler for a programming language is one of the complex ones.

2.7.2 The Boot Process

When you switch on the system, the first process that runs is the boot process. Booting is one of the system programs; we can also call it the init process — the initial process. Wherever it is located, first it has to be brought into the memory, and then it has to be executed. Only after the boot process executes do the necessary programs that are needed for the execution of other programs or applications start executing. That is the very first thing that happens when a system starts.

Real-world & domain connection: Every professional toolchain rests on these system programs: developers compile with the language support utilities, debug with the status/debugging utilities, and deploy through loaders and background services. On a Linux server, init (or its modern successors such as systemd) is the first process — PID 1 — and every other process on the machine descends from it; when a server's init service crashes, the whole system goes down. Understanding which utilities are system programs and which are applications explains why a server image ships with a fixed toolchain and why adding an application to it is a separate step.

2.8 Operating System Design and Implementation

2.8.1 Goals and Specifications

The goal here is not to design an operating system or to implement one, but to understand what we have to keep in mind when designing one. The first thing to do, before going for the design of an operating system, is to define some goals and specifications. When we define the goals, we must keep in mind what hardware the operating system will be used on, and what type of system will be affected by the operating system we are going to design.

Two sets of goals are fixed. The user goals say that, as a user, the operating system should be convenient for us to use, easy to learn, reliable, safe, and fast. The system goals say the operating system should be easy to design, easy to implement, and easy to maintain; it should be error free and it should be efficient. An operating system that you are going to use should be reliable: it should not produce errors often, it should be error free, it should be efficient, and it should be very flexible when you try to use it. Those are the system goals; the convenience, reliability, safety, and speed are the user goals.

Visual intuition: Picture two overlapping lists on a whiteboard. On the left, a stick figure labeled "user" with four words beneath it: convenient, easy to learn, safe, fast. On the right, a gear labeled "system" with: easy to design, easy to implement, easy to maintain, error free, efficient. The lists overlap only in the middle (reliability appears on both sides). The one-sentence takeaway: a good operating system design begins by writing both lists down before a single line of code — and the tension between the two lists is where most design trade-offs live.

2.8.2 Policy versus Mechanism

Two more things matter when we go for implementation: policy and mechanism. Policy is what you are going to do — what will be done. Mechanism determines how to do something. There should be a separation of policy from mechanism. Not all operating systems do this.

Think of how it works in an organization. Before starting an application or a project, the organization first fixes the policy. It decides what things are going to be accomplished, within what span of time, and how many resources we need and how many are available. Those things are designed first. Then comes the implementation — that is the mechanism — which takes care of how to build it. After the policy is defined, the mechanism decides how long it will take and how to implement it.

Specifying and designing this type of system is the main, creative task of the software.

2.8.3 Implementation Languages

Earlier operating systems were written in assembly-level language. Assembly language is a mnemonic type of code, which is not very easy to understand compared to a higher-level language. Later, UNIX broke this traditional way of writing operating systems in assembly: UNIX was written in C, by Ken Thompson and Dennis Ritchie. Operating systems today may be written in C++, though which operating system uses what is not public knowledge in this course. What you can do, if you try to create an operating system, is to have a mix: some parts in assembly-level language, some parts in a higher-level language, embedded together.

Why do some people prefer the higher-level language? Because it is easier to port — to move from one system to another, based on the architecture. The only problem with the higher-level language is the storage consumption: the space the code occupies in the memory is more when compared to assembly. At times, because of that storage space, the execution also slows down. So the trade-off is: assembly is fast and compact but hard to understand and hard to port; a higher-level language is easy to understand and portable but occupies more memory and can be slower.

2.8.4 Emulation

There is also something called emulation: you can allow an operating system to run on non-native hardware. Some systems are designed for a particular hardware. If you try to run an operating system that is not designed for that particular hardware, the hardware is non-native for it, and running the OS there is emulation.

Real-world & domain connection: Design trade-offs seen here decide real products: Linux is portable C and so runs on everything from Raspberry Pi to mainframes; Mac OS X and Windows encode policy and mechanism together for a consistent user experience; game console operating systems and embedded devices still use tight assembly where every byte counts; and emulation runs classic games and legacy software (DOSBox runs MS-DOS games on modern PCs) exactly as described here. When a company announces "now available on ARM," that is portability; when it instead runs x86 software translated instruction-by-instruction on ARM chips, that is emulation — the two are different engineering paths with different performance.

2.9 Operating System Structures

2.9.1 The Simple Structure: MS-DOS

Any general-purpose operating system is a very large program. How it is structured matters, and the structures differ from MS-DOS to Mac. MS-DOS has a very simple structure: everything can be accessed. As an application program, you can go all the way up to the ROM BIOS, and you can access it through system programs and device drivers. The functionality has not been separated, and the modules have not been separated from one another — the application programs are not separated from the rest. Because of this, if some program tries to change something, it will destroy the whole thing, and there will not be any proper functioning of MS-DOS. That was the problem with this operating system.

2.9.2 Traditional UNIX

UNIX was not so simple, and the functionality of the hardware support is very well separated. Each and every part is separable here: one part is the system program and another part is the kernel. In the traditional UNIX structure, the user cannot directly interact with any of the device drivers, terminal controllers, or memory controllers. The user has to go either through the shell, or through the system library, or through the compilers and interpreters, to access the information present in the hardware.

The kernel — the heart of the operating system, present in each and every operating system — takes care of interfacing with the hardware. That includes signal handling, file system handling, scheduling, page replacement, virtual memory management, and disk or tape drivers. Everything is handled with the help of the controllers that are present. Through the controllers, the information is sent to the hardware, and the information is retrieved from the hardware. That is the traditional structure.

Visual intuition: Picture UNIX as two stacked boxes: a slim top box labeled "system programs (shell, libraries, compilers)" and a huge bottom box labeled "kernel" containing scheduling, file system, virtual memory, and drivers as labeled compartments. The user interacts only with the top box; every request descends through the system-call interface into the kernel's compartments, which talk to the hardware through controllers. The landmark: one big kernel compartment — the reason UNIX's successor structures all try to shrink or divide that compartment.

2.9.3 The Layered Approach

Nowadays there is a layered type of approach, where each and every layer corresponds to a particular functionality. Starting from the top — the Nth layer — is the user interface, where the user enters the input. The input has to cross these many layers. Each layer provides the services to the layer above it, and uses the services of the lower level. If layer 1 exists, it uses the services of layer 0; if layer 2 exists, it uses the services of layer 1. Each and every layer is independent of the others, and each is built on top of the other. The highest layer is the user layer, and the lowest is the hardware. No layer is affected because of the other layers: they can use the services, but they cannot modify each other; each is independent of the other. This is the UNIX architecture expressed in the layered approach.

2.9.4 Microkernel-Based Systems

In a microkernel-based system, the kernel is a small program. Mach is a very good example of a microkernel, and Mac OS X is based on Mach; the kernel in Mac OS X is called the Darwin kernel. In a microkernel system, the communication between the user-mode programs takes place in terms of message passing. It is easier to extend the microkernel, and it is very easy to port it to another operating system, and it is very secure and reliable as well.

The main problem is the performance overhead. When the communication has to take place between the user and the kernel, there is a performance overhead that has to be taken care of. Look at the layout: the application program is there, and it has to interact with the file system or with the device drivers — and all these things are in the user mode. The IPC, memory management, and CPU scheduling are in the kernel mode. Together these form the microkernel. If a program has to access the file system, it has to go through message passing, so every time this performance overhead is there. If a device has to communicate with the file system, the device drivers again pass the message. The overhead also loads every time we switch from user mode to kernel mode and from kernel mode back to user mode.

2.9.5 Loadable Kernel Modules

Some operating systems use loadable kernel modules. Loadable means: if you have to perform a task, then that particular module is going to be loaded as a part of the kernel, in terms of a table. It is going to load a new table; whenever a command is executed, a new table is loaded, and from there the information is retrieved. Solaris is a good example — Solaris is a modular-based approach. The kernel is the core; if it has to run any one of the modules, it loads that particular table, and with the help of the table that particular module is executed. Each module is responsible for a certain function. Some systems use a combination of approaches: it may use an object-oriented approach or a component-based approach, or it can talk through a known interface, or the module is loaded whenever it is needed. That is the approach taken by Linux and Solaris.

2.9.6 Hybrid Systems: Mac OS X

A hybrid type of system is a combination of multiple approaches, because we have to address performance, security, and usability, everything. Hybrid systems mostly go for a monolithic type of approach — monolithic acts with only one thing at a time, not multiple things. Sometimes they go for microkernel-type approaches. Mac OS X is a hybrid type of system. Its user interface is called Aqua. On top of that there is Cocoa — a programming interface. Cocoa helps you to run the various frameworks present in the system; that is its main use. The loadable modules in Mac OS X are called kernel extensions. In the Mac OS structure, you have the GUI, Aqua, through which you call any one of the applications or the services. Cocoa acts as the API to run the frameworks in order to provide the service to the kernel environment, and then you get the information back.

2.9.7 Mobile Platforms: iOS and Android

iOS is mainly for mobile devices like the iPhone and the iPad. Apart from the functionality provided by Mac OS X, iOS provides something called Cocoa Touch. Cocoa Touch is different from Cocoa: it is an API specifically designed for mobile devices, in order to use the touch screen of devices like the iPhone or the iPad. This particular API — Objective-C — was designed by Apple. Apart from that, iOS has media services, core services, and the core operating system, which is mainly based on Mac OS X. Media services provide audio, video, and multimedia services. Core services provide database-based or cloud-based services.

Android is the operating system on many handsets. It was developed by the Open Handset Alliance, and it is open source. Its structure is more or less similar to iOS. Android has libraries that help you run databases — SQLite is there — plus OpenGL for graphics, the surface manager, the media framework, libc, and WebKit for developing or running web applications. There is also a runtime environment where Dalvik is used: Dalvik acts as a virtual machine. Whatever code is given is converted into an executable code, which then runs with the help of the Dalvik machine. So in the Android architecture, the application runs by taking the support of the libraries. With the help of the runtime environment, the kernel loads the modules and runs the application.

Real-world & domain connection: These structures decide what you can do with real devices: Android's Dalvik/ART runtime runs apps in a sandboxed virtual machine on billions of handsets; iOS's Cocoa Touch determines how every iPhone app handles touch input; Linux's loadable kernel modules are why you can plug in a new USB Wi-Fi adapter and have the driver load automatically without rebooting; and the Mach microkernel heritage in Darwin is why Mac OS X survived the transition from PowerPC to Intel and then to Apple Silicon. Choosing a structure is one of the first architectural decisions a real operating system project makes, and it constrains everything that follows.

2.10 Debugging and Failure Analysis

2.10.1 Kernighan's Rule

This topic is flagged as very, very important. According to Kernighan, debugging is twice as hard as writing the code. If you have written the code properly — or cleverly — then when something happens you may not have the capability to debug that particular code. So always keep this in mind: if you write code as cleverly as possible, you may not be clever enough to debug it. Writing simple, debuggable code beats writing clever, undebuggable code.

2.10.2 Log Files and Dumps

The main use of debugging is to find and fix the errors — the bugs. To do that, we have some log files that are generated in case there is any error information. Suppose there is an error in the application: we can capture that error in the code dump. "Core" actually means memory, so a core dump file is created, which captures the information with respect to the failure of an application. At times the system can also crash, and that creates a crash dump file, which has the kernel memory.

2.10.3 Profiling and Performance Tuning

Sometimes we need to keep track of the activities and record them for performance optimization — that is profiling. Profiling means periodically sampling the instructions and the statistical trends that are going through the system, and maintaining them accordingly. For performance tuning, we have to remove the bottlenecks present in the system.

2.10.4 Monitoring Tools in Practice

In Windows, there is the Task Manager. It has a performance tab where you can see the CPU usage, the page file usage history, the total number of threads, how many threads are in use, how many processors there are, the total memory, and the kernel memory. By seeing this you can understand whether the CPU is utilized properly — CPU utilization is very important.

In Solaris and Mac OS there is a tool called DTrace. DTrace has probes: whenever a code is executed, a probe fires, captures the data, and sends it. Events specified by the user are in the user space; the execution happens in the kernel. Whenever this particular event is triggered or fired, automatically the control moves from the user library to the kernel, and again it comes back to the user library.

The monitoring also records, for each process with a particular user ID, the amount of time it is running — in terms of nanoseconds. That per-process CPU time is reported precisely.

Real-world & domain connection: Debugging and performance work dominate real system administration and engineering. A server team investigating a slowdown starts exactly as this section describes: check Task Manager equivalents (top on Linux), sample profiles (perf, DTrace), find the saturated resource, and tune it. When an app crashes, the core dump is what the vendor's engineers analyze; when a machine blue-screens, the crash dump is what Microsoft asks for. Kernighan's rule is quoted in every code review discussion about clever code, and the per-process CPU time in nanoseconds is what cloud billing and autoscaling systems are built on.

2.11 Portability, Booting, and Platform-Specific Software

2.11.1 Portability and Compatibility

When we try to design an operating system, it should be able to run on any kind of machine, or it can be designed to run on a specific system. Some systems have been designed to run only on specific hardware — the system can be tied to the architecture of the processor. Especially in the Mac world, the machines have their own processor, their own architecture, and their own instructions, which they handle themselves. They do not allow other operating systems to be used on them. For the rest, the portability or compatibility should be there — the ability to access information and run across systems.

2.11.2 How a System Boots

Whenever you switch on a system, the first thing has to be brought up and placed in the memory for execution, and then the rest of the system starts. A small piece of code — the bootstrap loader — is what loads that particular program into the memory. Sometimes there is a block called the boot block, which holds the code. The process works in two steps: first, we go and find where the boot block is and get the information; second, we load it into the memory and start executing. Alternatively, we can have a boot menu — something like GRUB — which allows the selection among multiple disks. Multiple boot options are shown, and from that we can load a kernel and start fresh. These are the various ways the system can be booted.

2.11.3 Platform-Specific Software

There is a specific reason why most newly built software is Windows-first. Mac OS offers stronger protection when compared to Windows. Those using the Windows operating system know: Windows can run almost any system. We are not bothered about threads or whatever — we install whatever software we can run and start running it. It even asks whether you want to run the application, and we go on. Mac, and whatever carefully guarded software in the system, will not allow you to run all software. The authenticity, the protection, and the security provided for the system are more in those cases, because the new software should not affect the operating system. Windows does not take care of all those things, so any new build works on Windows.

That is why vendors ship separate versions for each platform: sometimes three things — Windows, Mac, and Unix — and sometimes only two — Windows and Mac. Each build has different functionality because the structure of each operating system differs. Within Windows you have to be very particular: the software will be specific to 32-bit or 64-bit, and to Windows 10 or Windows 11, so there will be two different specifications to choose from. And for Mac: people working in organizations use Macs because they have their own processor, their own architecture, and their own instructions, and they do not allow other operating systems to be used with them. Mac users generally stay with Mac OS. People who use a MacBook feel very comfortable with it, and booting feels easy. On processor-based Windows machines, booting can happen within fractions of a second.

2.11.4 Student Questions and Answers

Real-world & domain connection: Every one of these topics shows up in daily practice. Booting is why you can dual-boot Windows and Linux with GRUB, why a Mac's startup key combination picks a boot disk, and why firmware updates matter for security. Portability is why Linux runs on servers, phones, and Raspberry Pis while macOS stays on Apple hardware. Platform-specific distribution is why your Windows installer asks for 32-bit or 64-bit, why Mac software installs with a drag to Applications, and why organizations standardize on one platform. The virtual machine answer in the Q&A is exactly how developers today run Windows, Linux, and macOS guests on one laptop — the same VMware mechanism, with the same space and speed costs.

Exam Guidance Summary

• Debugging and failure analysis are flagged as very, very important; treat that emphasis as a strong signal for revision.
• The categories of system calls — process control, file management, device management, information maintenance, communication, and protection — and what each category can do are core material, studied in greater detail in later sessions.
• Resource allocation, communication, shared memory, and message passing are foundational: the coming sessions revisit them in detail, so the basic picture from this session will be built on, not replaced.
• The first few sessions are mostly theoretical; once processes are introduced, the material gets harder and the problems become more interesting, so expectations should be set accordingly.

Key Industry Applications

• WSL (Windows Subsystem for Linux): running Ubuntu and Linux commands inside Windows without a full virtual machine.
• VMware virtual machines: running guest operating systems (two or more) side by side, at the cost of disk space and speed.
• GUIs: Windows as the most widely used system (about 64% of usage), Mac OS X with the Aqua interface, and the GUI's origin at Xerox.
• Voice and touch interfaces: assistants like Alexa, and touch screens on laptops and mobile devices.
• Win32 API for Windows, POSIX API for Unix, Linux, and Mac OS X, and the Java API for the JVM — the standard ways applications reach system calls.
• The Unix design lineage: UNIX written in C by Ken Thompson and Dennis Ritchie, the layered architecture, and the Darwin kernel in Mac OS X built on the Mach microkernel.
• Solaris and Linux loadable kernel modules, and hybrid designs such as Mac OS X with its Cocoa framework API and kernel extensions.
• Mobile structures: iOS with Cocoa Touch and Objective-C, and Android from the Open Handset Alliance with SQLite, OpenGL, WebKit, and the Dalvik virtual machine.
• Debugging and performance tooling: the Windows Task Manager performance tab, DTrace probes in Solaris and Mac OS, and per-process CPU time measured in nanoseconds.
• Boot-time infrastructure: the bootstrap loader, the boot block, and boot menus such as GRUB for choosing among multiple disks and kernels.
• Platform-specific software distribution: separate installer builds for Windows (32-bit versus 64-bit, Windows 10 versus 11), Mac, and Unix, driven by each platform's security model and architecture.

Where these live in practice: every application you install touches one or more of these industry realities — a Windows installer is platform-specific software; a phone app runs on iOS's Cocoa Touch or Android's Dalvik runtime; a cloud server boots through a bootstrap loader and is monitored with Task Manager-style tools and DTrace-class tracing; and the code you write reaches the hardware through Win32, POSIX, or the Java API. When later sessions discuss processes, scheduling, and memory, these applications are what those topics will be operating on.