UNISA Chatter – Operating System Concepts: Part 2 … System Structures

See UNISA – Summary of 2010 Posts for a list of related UNISA posts. In this post we briefly cover the system structures of a typical operating system.

Clipart Illustration of a White Character Kiking A Soccer Ball Up While Playing A Game Life begins with the boot strap loader

The life of the operating system starts with the system boot, typically with a small piece of code (bootstrap loader) stored in ROM or EPROM waking up, fetching a more complex boot loader from disk which in turn loads the operating system kernel from disk. Once the kernel materialises, the operating system starts its initialisation process and prepares the ecosystem.

Soccer game also starts with the boot

Operating System Services

The operating system ecosystem typically includes the following services:

image… typical operating system services 



User | System Support


Keep track of who does what



Communication between processes (local and remote)


Error Management

Detection and management of errors, traps and exceptions to create a consistent, stable and safe environment.



Secondary storage management, such as file and directory I/O.



Management of devices, such as DVD, Tape, Keyboard and Mouse.


Program Control

Loading, running and management of programs.



Resource allocation and management.



User access control and data protection.


User Interface

A combination of graphical user interface (GUI), command line interface and batch interface.


As shown in the illustration and table above we have a base set of services a typical operating system kernel is responsible for. The User | System support column indicates whether the service is perceived as a direct help to the user, or is concerned with the efficiency of the system itself. These services are typically implemented by the kernel and execute in kernel mode, as user mode environments cannot be trusted to deliver these services in a secure, reliable and operating system design adherence manner.

Systems Calls … the kernel gateway

A strong theme in operating system design is the quest for example for reliability, performance, quality and security. Can the user programs be trusted to deliver these characteristics? Possibly … but not guaranteed, which is why the operating system creates a boundary of trust using the user and kernel mode as mentioned in UNISA Chatter – Operating System Concepts: Part 1 … Introduction. When you call an API, such as CreateFile, in user mode you may get the impression that you are literally creating the file with the call. In reality the user mode call makes a call to a system call, which in essence switches to kernel mode and calls the kernel mode counterpart as shown:

System Call

The following snippet from MSDN shows that there are two versions of CreateFile, one that runs in user-mode NtCreateFile and one that runs in kernel mode ZwCreateFile. This illustrates the concept of user mode and kernel mode system call territory and invocation.


System Programs

System programs are a collection of system utilities that provide a useful environment to the user and which typically ship with the operating systems. Examples of system programs include:

  • File Management
  • Status Information
  • File Modification, such as text editors
  • Development and Debugging support
  • Communications among processes, users and computers

Operating System Structures

The following table summarizes the four common type of structures, whereby an operating system can be a hybrid combination of these types. We could have included a discussion on virtualization, but the bus trip is not that long this morning 🙂

Type Notes Advantages Disadvantages
Simple Structure is not well defined, typically a result of an evolutionary operating system or a prototype that ended up in production.  
  • Services, responsibilities, features and other operating system structures tend to become ill defined, which impacts performance, security, reliability and maintainability.
Layered Operating system is broken into smaller and more focused.
  • Clear Boundaries (layers) of responsibility and interface points.
  • Implementation freedom within layer
  • Simpler construction
  • Simpler debugging
  • Ability to control access / security at layer interface
  • Difficulty in defining appropriate layers
  • Need for careful design for top-down communication
  • Performance impact by cross-layer calls.
Micro Kernel Provide essential system services only and defer all other services to system and user programs.
  • Compact
  • Easier maintenance
  • Ease of extending operating system
  • Performance impact due to message based communication
  • Maintenance shifts to system and user programs
Modular Core kernel, which links in additional services, encapsulated in modular components, during boot or run-time.
  • Object-oriented, modular kernel
  • Ease of extending operating system

The following rough sketches illustrate the four types:

SimpleSimple Structure LayeredLayered Structure
MicrokernelMicro Kernel ModularModular Structure

That’s the summaries for today. The next post of this series will cover Process management.

Acronyms Used
| I/O – Input/Output | MSDN – Microsoft Developer Network | ROM – Read Only Memory | EPROM – Erasable Read Only Memory |

Comments (0)

Skip to main content