Operating Systems

Virtually all computer systems require an operating system – a piece of software which interacts directly with the hardware, manages resources, and usually presents a user interface to the user.

In an operating system, there is a ‘core’ element, the kernel. This is the heart of the operating system. It does not have any sort of user interface – this is provided by other components of the OS.

Categorisation of OSes

It should come as no surprise that there are different types of operating system, each of which is used in specific situations. The types that you need to understand are:

Real-time operating system

A real-time OS (RTOS) runs on hardware much like any other OS. Where it is differentiated from a regular operating system is in the manner with which tasks are managed.

In an RTOS, there can be multiple tasks running simultaneously – or rather, that appear to run simultaneously (this is the same with any multi-tasking OS). In fact, in order to give the impression that multiple tasks are running, the OS simply switches between processing different tasks on a regular basis. It will complete a tiny bit of work on task 1, switch to task 2 and complete a tin bit of work, switch to task 3 and so on. This cycle makes it appear to the end-user that multiple tasks are being processed concurrently.

Where an RTOS differs from a regular OS is that this switching happens very rapidly, and external inputs are guaranteed to be responded to extremely quickly – essentially, fast enough to appear to be in ‘real time’. A regular OS makes no guarantee about the order in which tasks will be completed, nor does it make any promises about the reaction time to inputs.

RTOSes are used where delay to inputs or processing delays would be problematic – for example, air traffic control or controls within a plane.

Single-user, single-task

This category of OS is used on devices that have a single user, and where that user is only working on one task at a time.

Most mobile phone OSes used to fit into this category, although the line between single-task and multi-task is becoming blurred.

A mobile device is used by only one user at a time, and historically, the user could only interact with one of the installed apps at a time.

Read more about the comparison of SUST and SUMT here.

Single-user, multi-task

In comparison, a home PC runs a single-user multi-task operating system. This allows a single user to user the machine at any one time (we are ignoring features that allow an additional user to sign on whilst leaving the original user’s applications open in the background, because that user can’t be ‘using’ the PC at the same time).

Operatings systems such as Windows, MacOS and so on allow multiple programs to be open and running ‘simultaneously’ (more on that in a later section).

Multi-user

A multi-user operating system is one that allows multiple users, on separate computing devices, to all access the resources of a single system at the same time. For example, Windows is not technically a multi-user OS, but Windows Server is: the machine running Windows Server is available for many users to connect to simultaneously via the network.

The role of the kernel in controlling and managing system components and tasks

The kernel is the most important component of an operating system. It has the highest level of privilege (meaning it can access anything and do anything) without being challenged.

When a computer is started up, the typical pattern is:

BIOS is loaded and executed. The BIOS is EPROM (Read Only Memory, but also Erasable and Programmable, hence the ability to update BIOS).
Bootloader is launched. This is the application which determines what operating system will be loaded, or presents options to choose if you have multiple options.
The kernel loads – this is the first component to be loaded, and will remain in memory until shutdown at which point it will be the last component to be unloaded.

Program execution

The kernel manages all running programs, and mediates between them and hardware resources.

For example, it has been repeatedly mentioned that multiple programs can run simultaneously on a PC. The reality is that multiple programs are afforded tiny slices of time running on the CPU in a rota system. This is processor scheduling: the kernel is responsible for determining which process(es) should currently be running, on which CPU core, and for how long. Usually, this is achieved through the use of a priority system: processes are marked as low through to high priority. In the event that two or more processes both need to perform work, the higher priority one is granted CPU time.

When programs want to communicate with the hardware, this is achieved through the use of system calls: calls to the kernel that interact with the hardware.

Interrupts

An interrupt is a signal originating from the processor that states something needs to be done – for example, the keyboard has input that needs processing, or data has arrived via a network connection.

The processor may well be in the middle of doing something else; to solve the problem, the CPU sends an interrupt which is picked up by the kernel, and the kernel then calls the appropriate function.

As the operating system starts up, the kernel loads the location of these interrupt handlers into the Interrupt Descriptor Table (IDT). The CPU then disables interrupts and calls the appropriate function. Upon its completion, the CPU re-enables interrupts.

Modes

Recalling that the kernel operates with extremely high privileges, there have to be protections in place in order to mitigate the risk of nefarious attacks on a system. At all times, the computer will be running the kernel; what else runs will vary from time to time and use case to use case.

The kernel operates in two different modes, and this is reflected in the operating mode of the CPU:

User mode
Kernel mode

In user mode, applications are able to run – a word processor for example. In user mode, there are operations that are not possible, because they are considered too ‘low level’ and should not be available to a user application.

In kernel mode, anything is allowed – this means accessing any memory area, any resource, or performing any task.

Protections are put in place to ensure that should a user-mode application attempt to run any kernel-mode code, a trap is generated – this will stall the computer. In Windows, a kernel error results in the famous Blue Screen of Death. On MacOS, it will result in a kernel panic.

In normal operation, the kernel is switching back and forward may thousands of times a second between user mode and kernel mode.

Microsoft documentation about kernel modes and addressing

Kernel modes

Memory management

The kernel is also responsible for memory management. Memory management means that:

Memory is available to applications when they need it
Applications can not access the memory used by other applications

Applications, when loaded by the kernel, are assigned a ‘virtual address space’ – that is, a range of memory where they are able to operate. The kernel will keep track of this, and inform the CPU. Attempts to access memory locations outside of that space are not approved.

Every application that runs in user mode will have its own, unshared memory.

The kernel is able to access all memory locations of the system. It is meant to provide a safe way for data to be channelled to and from different processes. This should help explain why bugs in an OS’s kernel are so serious: if the kernel is compromised, a malicious application can access anything it wants to.

In contrast, there are some applications which run in kernel mode: device drivers being a common example. In kernel mode, applications all share a single address space, which is also shared with the OS itself. This means that a driver can write directly to a memory address which may be in use elsewhere – often, the result of such an action is that the system will require restarting. This is why device drivers are so often responsible for system instability.

Multi tasking

As already discussed, the kernel facilitates multi-tasking – the apparent simultaneous execution of multiple processes.

In order to achieve this, the kernel performs context switching: a process where the state of a process and any pertinent data are stored so that execution can switch to a different process. When the paused process is reinstated, its saved data can be reloaded so that execution appears to continue seamlessly.

A long read is found here.

Disk access

All disk IO is marshalled through the kernel; this means that when requests are made from programs to access parts of a filesystem, the kernel is responsible for translation of the request into commands that the device drivers can facilitate. Allowing disk access from outside of the kernel would compromise security restrictions – for example, being able to open other people’s documents. (If you physically remove a non-encrypted disk from a computer, and connect it to another machine as a secondary drive, you can browse the contents even without knowing the users’ credentials – that’s what the kernel is trying to stop).

File systems

The OS kernel is responsible for the maintenance of the file system. This encompasses the following responsibilities:

maintaining a list of which devices are attached to the system and routing requests to the correct drive
assigning identifiers to files so that the correct file can be located
managing free space on a system
enforcing security policy – i.e. who can read and/or write individual files or folders

In practise, this is achieved in a layered system in much the same way as the OSI network model splits network communication into layers (application layer, transport layer etc).

A detailed explanation of how this works is found here.

Device drivers

Device drivers are pieces of software that sit between the kernel and the hardware devices in a system. They provide a layer of abstraction: the kernel does not need to know the exact capabilities or method of implementation of the devices with which it communicates. Instead, it requires that all devices conform to an ‘interface’ – called an API (Application Programming Interface) – and the device drivers fulfil this.

Having a system where device drivers sit between the hardware and the kernel allows huge amounts of flexibility in terms of what hardware can be supported.

However, a lot of device drivers are targeted at hardware devices which require maximum performance or availability to all applications. Recalling that user-mode applications have their own memory space, implementing, for example, a display driver in user-mode would not be efficient. Huge amounts of data would have to be fetched from the originating application by the kernel, and then written out to the address space used by the driver, in order for the information to be displayed. This would have a huge negative impact on performance.

For this reason, drivers which deal with hardware devices that typically involve large volumes of data or need to work in as-close-to-real-time as possible will run in kernel mode, allowing direct access to the memory used by other applications.

The role of the operating system in managing

Networking

Thirty years ago, OSes could be classified as to whether they were a network OS or not. Nowadays, all OSes are capable of network interaction.

What this means in practise is that a modern OS contains software that simplifies the process of networking. Consider the steps that must be taken in order to connect two computers together via an ethernet cable:

Decide which is client and which is server
Negotiate what speed to transfer information
Negotiate a protocol
Decide who is currently sending and who is receiving
Check whether data was correctly received, and in full
And so on…

Having capabilities built in to the OS simplifies this sort of scenario – replace the devices and technology (e.g. a smart phone connecting to a data service via WiFi) and the important becomes obvious.

Security

The kernel is responsible for applying security schemes. This works on various levels, but essentially it comes down to the management of users and permissions.

As the kernel already has responsibility for so much of the system (IO, file access etc), it is perfectly placed to enforce permissions on access:

A user is logged in to Windows and launches File Explorer. This shows files on the system. The user sees one that looks interesting and tries to open it. However, their user account is not granted access to open this file. As the IO/File request goes via the kernel, the kernel can ensure the file is not opened.
A user runs a program which tries to make changes on the system, to some files in a protected area. The kernel intercepts these requests, and perhaps shows an authorisation form (UAC in Windows) or denies the request.

As noted in the file system section, removing the drive from the PC and mounting it as an external device can bypass most, if not all, of these restrictions, which is why encryption is commonly used in conjunction with account control.

Factors affecting the choice of user interface

Graphical

A graphical interface is the most common interface for PCs and laptops. It provides the user with a collection of abstract entities with which they can interact: as an example, there is no such thing as a ‘window’ on a computer, but as an abstract item (a container to hold an application) it works well for a human to interact with.

Common examples are Windows, MacOS and many Linux variations also provide GUIs.

The advantages of using a GUI include:

Simplifying the learning curve – operations available to the user are often presented graphically, eg through a set of icons (application icons, maximise, minimise etc)
No need to learn bespoke word commands or refer to manuals to see what commands are available
Consistency: for example most users understand that a right-click on an item will show a list of potential operations
Easy to visually check on the status of multiple systems simultaneously through use of windows

Disadvantages of a GUI:

Could be incredibly complex; some operations have potentially hundreds of combinations of parameters. Trying to represent this visually can be tough
Require a lot of time and effort to effectively implement. In cases where users will not interact regularly, this is wasted development time
Requires additional resources: better graphics hardware and more memory is required to create a GUI in comparison to a command line prompt

Command line

A command line operating system isn’t necessarily less complex than a GUI-based operating system. In fact, most Linux distributions can be installed with or without a window manager.

Using a command-line OS is more practical when:

Interaction is infrequent
Interaction involves specifying many parameters (meaning the use of command-line tools would be normal anyway)
There are limited resources available

Menu-based

A menu-based OS is graphical, but it is not a true GUI OS.

In a GUI OS, the user can freely select what item to action, and can move items, query them by right-clicking, minimise and switch between active applications by clicking on their windows.

Consider a mobile phone: these are clearly not text-based OSes, but they lack the flexibility and freedom that a true graphical OS would afford.

A menu-based OS is one where the interaction is graphical in nature, but is guided through a choice of menus. Think about selecting an app to launch on a phone:

Function: navigate to home screen
Input: swipe to view next page
Function: launch application

It is very prescribed; they make the system easier to use by only presenting valid choices at any time. The user is never left in a position of wondering whether ‘x’ is an option.

However, as you are more than likely aware, this reduces the flexibility of the OS, because the user is no longer able to interact in whatever way they wish.

Factors affecting the choice of operating system

The choice of operating system ultimately comes down to:

What are the priorities for the system?
What hardware is the system running?
What software is the system running?

The second and third points are easy to understand: not all hardware can be used with all operating systems. Clearly, if you have certain hardware to use, the choice of OS must be one which can support that hardware.

Similarly, with software: not all software is available across all platforms. You can’t buy Logic X for a PC for example. If you need to use certain pieces of software, you need to select an OS on which that software can run.

The first point is much more complex.

There are considerations such as:

Is any particular certification required? Unsurprisingly, aircraft do not run Windows to control the flight systems. For a start, a real-time OS is required. Secondly, an OS which is certified to be error free is required. While an error-free OS sounds like a goal that should be relevant to all OSes, in practise this requires a trimming down of features and reduction in the amount of supported hardware in order to guarantee results.
How much interaction will there be? Could a command line be a better option than full GUI?
What is the experience level of the users?