An Investigative Analysis of Different Computer Operating Systems

1. Introduction

1.1. Purpose and Objectives

The primary purpose of this report is to examine how kernel architectural design shapes functionality, performance, and dependability in contemporary operating systems. The kernel is the intermediary between hardware and user applications, and it establishes core processes such as scheduling, memory allocation, device management, and I/O operations.

This report aims to: examine the basic concepts of the kernel architectural classes — monolithic, microkernel, hybrid, and exokernel; discuss how these designs affect OS performance, scalability, and security; and contrast how these architectures are implemented in practice, pointing out their benefits and drawbacks. The investigation aims not only at a conceptual understanding, but at the practical implications of how architectural decisions determine the design trade-offs encountered in real-world computing.

1.2. Overview of Operating System Architectures

Kernel architectures have developed extensively over the past fifty years. Monolithic kernels, used in AT&T's first edition of UNIX and other early systems, supported all core functions — memory management, process scheduling, I/O services, and inter-process communication — inside a single privileged image. The design is efficient, but services are strongly coupled, so modularity suffers and a single defect can compromise the whole system.

The microkernel school of thought originated in the mid-1980s and favoured a minimalistic kernel: only essential features such as CPU management, IPC, and memory handling remain in kernel space, while other services migrate to user space. Fault isolation, security, and modularity improved, but the additional context switches imposed real overhead. Hybrid kernels attempted to provide the best of both worlds — certain services were moved back into kernel space for performance without entirely abandoning the modular design. The Windows NT family and macOS (XNU) take this approach. Exokernels, finally, are an experiment in exposing raw resources and pushing nearly everything into user space.

1.3. Importance of Architectural Design in Modern Computing

The design of a kernel is not just an academic matter; it has very real implications for safety, scalability, and security. With the rise of cloud infrastructure, virtualization, and container-based systems, an OS's effectiveness at running parallel workloads and isolating performance concerns is driven directly by its kernel design. High-throughput domains such as servers favour a monolithic kernel because of the cost of IPC, while safety-critical domains such as avionics and automotive control leverage microkernel characteristics such as fault isolation.

Moreover, security concerns usually originate at the kernel. A monolithic kernel allows cascading failures, where the compromise of a single driver or service can cripple the system, whereas modular designs can contain damage to individual subsystems (Heiser & Elphinstone 2016). Kernel architecture therefore has a direct and immediate effect on both the efficiency and the trustworthiness of current computer systems.

1.4. Scope and Selected Operating Systems

This investigation concentrates on three systems that represent the prevailing kernel paradigms: Linux, an instance of the monolithic model used on everything from embedded devices to supercomputers; Windows NT, the canonical pragmatic hybrid underlying modern Windows; and QNX, a commercial real-time OS that remains one of the most influential pure microkernels. The report treats the subsystems of CPU scheduling, memory management, device drivers, file systems, and security frameworks, and considers how architecture affects the operation of each.

2. Foundational Concepts of OS Architectures

2.1. Monolithic Kernel Architecture

In a monolithic kernel, all OS services — process and memory management, file systems, system calls, networking, and device I/O — run within the same address space and protection domain. Conceptually the kernel acts like one large, closely inter-related program running in kernel mode, while user applications run in an isolated space and must transition to kernel mode via system calls. This integrated design originates in early UNIX and remains popular in general-purpose OSs.

Communication requires no message passing: interactions occur through direct function calls and shared in-kernel data structures. A user process performs a system call (a software trap) to enter kernel context; from there, routines simply invoke other kernel functions directly with essentially no overhead. The result is high throughput and low latency — fast enough for servers and high-performance computing. The price is poor fault tolerance (a bad driver or module may take down the entire system), a larger trusted computing base, and a kernel that becomes harder to maintain and formally verify as it grows. Modern systems mitigate this with loadable kernel modules.

/* User space */
int fd = open("data.txt", O_RDONLY);   /* libc wrapper */

/* Kernel space — reached via trap */
long sys_open(const char *path, int flags)
{
    /* Direct call into the in-kernel VFS: no IPC, no
       context switch — and no isolation either. */
    return vfs_open(path, flags);
}

2.2. Microkernel Architecture

A microkernel limits the kernel to a minimum set of primitives: low-level address-space management, IPC, and basic scheduling. Higher-level services — file systems, drivers, even network stacks — run in user space as independent server processes. This rigid partition propagates isolation: services cannot interfere with the kernel or with each other directly.

Message-passing IPC is the primary means of invoking any service, so implementations place significant emphasis on optimising IPC latency and throughput. The rewards are fault isolation and modularity — failed servers restart in isolation — and a trusted computing base small enough for formal analysis, as demonstrated by seL4. The costs are IPC and context-switch overhead relative to monolithic designs, and the added complexity of reliable message-passing semantics. Contemporary L4-family microkernels have shown that careful engineering can achieve near-monolithic performance while permitting formal verification for high-assurance systems.

/* Kernel provides only IPC primitives */
int send_message(pid_t server, Message *msg);
int receive_message(Message *msg);

/* File-system server (user space) */
void fs_server(void)
{
    Message req, res;
    while (receive_message(&req)) {
        if (req.type == OPEN) {
            res.fd = do_open(req.filename);
            send_message(req.client, &res);
        }
    }
}

/* Application */
int main(void)
{
    Message req = { .type = OPEN, .filename = "data.txt" };
    send_message(FS_SERVER_PID, &req);

    Message res;
    receive_message(&res);
    int fd = res.fd;                 /* two IPC hops later */
}

2.3. Hybrid Kernel Architecture

Hybrid kernels represent a compromise between the two models: more services live in the kernel than in a pure microkernel — usually the performance-critical ones — but a distinction remains between which functions run in supervisor mode and which do not. The goal is to balance performance against modularity and maintainability.

Hybrids combine direct in-kernel calls with message-based or loosely coupled interfaces, and the separation between kernel-space and user-space servers is looser than in a pure microkernel. The result is a realistic trade-off between throughput and modularity that suits off-the-shelf desktop and mobile OSs, at the cost of a more complex architecture and a bigger trusted computing base — and partial modularity can hide subtle fault and security exposure. Windows NT and Apple's XNU are canonical hybrids: they adopt microkernel structure where appropriate but keep performance-sensitive components kernel-resident.

2.4. Alternative and Emerging Architectures

Exokernels expose only low-level hardware-multiplexing primitives to applications; resource-management policy is enforced at user level inside library operating systems. This yields high specialisation and performance for niche applications but moves complexity onto application developers — the MIT Exokernel project is the classic study of these trade-offs.

Unikernels package an application together with only the OS components it needs into one tailor-made bootable image. They optimise for cloud and IoT use-cases with very narrow attack surfaces and very efficient resource usage, at the expense of generality and operational complexity: application and OS live in a single image with no syscall boundary at all.

The current trend is toward correctness and assurance. seL4 demonstrates that a microkernel can be formally verified — its implementation mathematically proven to match its specification — while maintaining competitive performance, eliminating entire classes of bugs and vulnerabilities (Klein et al. 2014).

/* seL4-style IPC call */
seL4_MessageInfo_t msg = seL4_MessageInfo_new(0, 0, 0, 1);
seL4_SetMR(0, OPEN_FILE);
seL4_Call(fs_endpoint, msg);   /* formally verified IPC path */

2.5. Core Components and Interactions

Regardless of paradigm, an operating system is arranged into cooperating parts that determine how applications reach hardware. Kernel space is the memory in which the core of the OS executes: privileged mode (ring 0 on x86), direct control of hardware, centralised for performance — and consequently the place where a single fault can bring the whole system down. User space is where applications live: unprivileged (ring 3), each process in its own address space, so a crash stays in user mode and cannot directly harm the kernel. When a text editor saves a file, it cannot write to the disk directly; it asks the kernel to perform the I/O.

System calls are the controlled gateway between the two worlds. An application makes a library call such as open(); a trap instruction switches the CPU from user mode to kernel mode; the kernel performs the requested service and returns control to the user process. Interrupts complete the picture: hardware interrupts are issued by devices (a network card announcing new data), while software interrupts — traps — are raised by programs, system calls included. They let the kernel briefly pre-empt running tasks to service urgent events such as keystrokes or disk-I/O completion.

#include <unistd.h>
#include <fcntl.h>

int main(void)
{
    int fd = open("data.txt", O_CREAT | O_WRONLY, 0644); /* system call */
    write(fd, "Hello OS", 8);                            /* system call */
    close(fd);                                           /* system call */
    return 0;
}

2.6. Evolution and Design Principles

The changing kernel reflects broader shifts in computing priorities. Legacy systems such as UNIX could not adopt microkernel designs because of limited hardware and a focus on raw performance. Microkernels became prominent in the 1980s as fault-tolerant distributed systems, modularity, and separation of policy from mechanism grew important. Performance problems in conventional practice then led Microsoft and Apple toward hybrid systems in the 1990s and 2000s — a practical trade-off between speed and safety.

Four principles recur throughout this evolution. Modularity: breaking the kernel into relatively independent parts eases maintenance, upgrades, and fault isolation — Linux's loadable kernel modules allow features to be added or removed at runtime, and microkernels extend the idea by pushing whole services into user space. Reliability: a defective driver can crash a monolithic kernel outright, while a microkernel restarts the offending user-space server in isolation; hybrids sit in between. Performance: monolithic kernels avoid messaging costs entirely; microkernels historically paid a heavy IPC tax that modern L4-family designs have dramatically reduced. Security: kernel design dictates the attack surface — a large kernel with in-kernel drivers exposes far more code than a minimal, isolated core.

3. Architectural Exploration: Case Studies

To give the theory an empirical basis, this chapter examines three well-known operating systems — Linux, Windows, and QNX — each representative of a major kernel design: monolithic, hybrid, and microkernel respectively. Their inner workings form the foundation for the comparative analysis in Section 4.

3.1. Case Study 1 — Linux and the Modular Monolithic Kernel

The Linux kernel was created by Linus Torvalds, then a computer-science student at the University of Helsinki, drawing on UNIX and the educational system MINIX (Tanenbaum & Bos 2015). An early decision was to license the software under the GNU General Public License, allowing anyone to change, copy, and distribute the code. Rapid development and broad hardware support followed, coordinated through a hierarchy of maintainers with Torvalds at the top. The Linux kernel project is today one of the largest and most active open-source projects in history.

The defining characteristic of its monolithic design is that all core OS functions — process management, memory management, the Virtual File System, the network stack, IPC mechanisms, and drivers — operate in a single large privileged space. Communication among components is extremely efficient because interactions are ordinary function calls (Silberschatz, Galvin & Gagne 2018). The breakthrough that keeps Linux from being a 'pure' monolith is its heavy use of Loadable Kernel Modules (LKMs): device drivers and file-system handlers that can be inserted into the running kernel when needed and removed when they are not, giving the system flexibility and extensibility without recompilation or reboot.

From the command line, administrators can identify the running kernel directly: uname -a reports the kernel version and machine details — essential for managing kernel modules and verifying software compatibility.

$ uname -a
Linux my-server 5.15.0-88-generic #98-Ubuntu SMP \
  Mon Oct 2 15:18:56 UTC 2023 x86_64 GNU/Linux

3.2. Case Study 2 — Windows and the Pragmatic Hybrid Kernel

The Microsoft Windows NT ('New Technology') architecture underlies all modern Windows variants, from Windows 10 and 11 to the server line. Work began in the late 1980s under Dave Cutler with the explicit objectives of a secure, robust, hardware-agnostic OS (Russinovich, Solomon & Ionescu 2017). The design deliberately borrowed the client–server and message-passing ideas of microkernels but eschewed ideological purity in favour of competitive performance.

The architecture is highly layered. At its centre, the kernel proper (ntoskrnl.exe) exhibits microkernel-like restraint — little more than thread scheduling, interrupt dispatching, and multiprocessor synchronisation. But alongside it, in the same privileged space, runs the Executive: a substantial collection of core OS services. Application-facing environment subsystems (such as Win32) run in user mode as clients of the Executive, and the Hardware Abstraction Layer (HAL) provides a standard interface between kernel, drivers, and the platform for portability.

3.3. Case Study 3 — QNX and the True Microkernel

QNX is a commercial real-time operating system and one of the most influential pure microkernel designs. It powers safety-critical systems including automotive platforms, medical devices, avionics for both military and commercial aircraft, unmanned aerial vehicles, and industrial control computers.

The QNX kernel is impressively tiny, providing only what is strictly necessary: CPU scheduling, inter-process communication, interrupt dispatch, and timers. Every other standard OS service — device drivers, file systems, protocol stacks, application services — executes as a separate, memory-protected process in user space. When an application writes to disk, it does not call into a massive kernel; it sends a message through the kernel's IPC service to the file-system server, which in turn messages the disk-driver server.

This architectural cleanliness yields superb fault tolerance. A device driver is an individual user-space process; if it fails, the system can frequently restart it automatically without affecting the kernel or other critical processes — something generally impossible in a monolithic design, where a buggy driver can crash all kernel code. This inherent reliability is why QNX is selected where failure is not an option.

4. Comparative Analysis of Architectural Impacts

The choice of monolithic, microkernel, or hybrid architecture is not academic; it directly shapes the realisation, performance, and dependability of every basic function an operating system performs. This section compares Linux, Windows, and QNX across four core OS processes.

4.1. Process and CPU Management

In Linux, creating or managing a process (fork(), exec()) is a direct, low-latency call into the kernel. The scheduler, as an integral part of the kernel, has immediate access to all process state, enabling highly optimised algorithms such as the Completely Fair Scheduler; context switches are cheap because they occur within a single unified address space. In QNX, process management is mediated by message passing: a service request involves at least two context switches — client to kernel, kernel to server — introducing latency that is accepted deliberately, because the resulting scheduler is simple and highly deterministic, which is exactly what real-time environments require (Hildebrand 2007). Windows NT seeks the middle ground: core process and thread management resides in the privileged Executive, avoiding IPC overhead for common operations, while its priority-based pre-emptive scheduler serves demanding desktop and server workloads (Russinovich, Solomon & Ionescu 2017).

4.2. Device and Driver Management

Driver handling is perhaps the clearest architectural discriminator, because it directly determines stability. Linux drivers are typically loadable kernel modules running with full kernel privileges: minimal latency and maximum performance — a key factor in Linux's HPC success — but no fault isolation, so a faulty driver can corrupt kernel memory and cause a system-wide kernel panic. QNX treats every driver as an unprivileged, self-contained user-space server: if it hits a fatal error, only that process dies, and the OS can restart it, often invisibly — the cornerstone of QNX's reputation in safety-critical control units, paid for with IPC on every I/O operation. Windows largely follows the monolithic model for performance-critical drivers (graphics, storage), which has historically been the primary source of the infamous 'Blue Screen of Death'; in response, Microsoft's User-Mode Driver Framework moves less critical driver classes (such as USB peripherals) into user space — embracing the microkernel principle exactly where performance permits.

4.3. Security Mechanisms

The kernel is the last line of defence, and its design dictates the size and character of the trusted computing base. Linux's TCB is enormous — millions of lines of kernel and driver code — so a vulnerability in any single component, from the network stack to an obscure audio driver, can yield complete control of the system; mechanisms such as SELinux add mandatory access control, but as policy layered over a fundamentally large TCB. QNX's TCB is exceptionally small — essentially the microkernel itself — drastically reducing the attack surface and enforcing least privilege architecturally: compromising the file-system server does not compromise the network server (Heiser 2014). Windows' TCB spans the NT kernel and the entire Executive; Microsoft defends this large surface with Kernel Patch Protection, ASLR, and Virtualization-Based Security, but the architectural premise remains that any kernel-mode vulnerability is critical.

4.4. Memory and File-System Management

The virtual memory managers of Linux and Windows are sophisticated kernel-mode components with direct control of MMU hardware and page tables — the throughput-first choice demanded by resource-intensive applications. A true microkernel moves memory-management policy into a user-space server, gaining flexibility at some cost in page-fault-handling throughput. The same trade appears in file systems: Linux's VFS and Windows' NTFS stack are kernel-mode for performance, turning an application's read directly into block-device operations, while in QNX the file system is a user-space server — enabling several independent file systems to run in parallel, with IPC overhead on every operation. Everyday tools make the split visible: top on Linux and Task Manager on Windows are both user-space applications asking their kernel-mode memory managers for the current state of the system.

5. Practical Implications and Use-Case Scenarios

5.1. Real-World Application Domains

The dominance of each architecture in particular market segments follows naturally from its strengths. Linux's monolithic design has won it the lion's share of high-performance computing, cloud infrastructure, and web serving, where message-passing costs are unaffordable overhead and driver risk is managed through proven hardware and professional administration. Windows' position on the desktop and enterprise server reflects the hybrid's balance of performance and features: it must run performance-critical applications — games, databases — across nearly unlimited hardware and third-party software. For safety-critical embedded systems, the microkernel's fault isolation is the only acceptable choice: QNX's use in advanced driver-assistance systems, avionics, and medical devices is motivated by the requirement that an infotainment driver may fail, but the braking system must not (Koopman 2017).

5.2. Architecture's Influence on Administrative Tasks

Even routine administration carries the kernel's fingerprints. File permissions illustrate the point: on Linux, chmod manipulates a simple, powerful owner/group/other model stored in the inode — a native system call into the monolithic kernel's VFS, and correspondingly quick. Windows uses Access Control Lists managed by the Security Reference Monitor inside the kernel-mode Executive: more granular, and more convoluted — characteristic of the hybrid model's tendency to build complex services as layered overlays.

# Linux — inode mode bits, one VFS syscall
$ chmod 640 report.pdf
$ ls -l report.pdf
-rw-r----- 1 sujan staff 48120 Jul 27 10:02 report.pdf

# Windows — ACL entry via the Security Reference Monitor
> icacls report.pdf /grant "Editors:(R,W)"
processed file: report.pdf

5.3. Strengths, Weaknesses, and Future Trends

The old trade-off — monolithic is fast but fragile, microkernel is robust at an IPC price — is being reshaped by new software paradigms. Containerisation as embodied by Docker and orchestrated by Kubernetes depends on primitives built deep inside the monolithic Linux kernel — cgroups and namespaces — exploiting the monolithic design's efficiency to isolate applications above a shared kernel (Verma et al. 2015).

In the opposite direction, demand for provably secure systems is driving modern microkernel design. seL4's formally verified implementation — its correctness mathematically proven — eliminates entire classes of vulnerabilities, carrying the microkernel philosophy to its logical peak for next-generation critical systems such as IoT and autonomous vehicles (Klein et al. 2014). These trends converge on a future in which kernel architectures are tailored ever more precisely to their use-case, rather than one design fitting every task.

6. Conclusion and Reflections

6.1. Summary of Key Findings

This analysis confirmed that Linux's monolithic nature — a single kernel space — yields superior performance through low-latency communication among core components, at the cost of a heavy trusted computing base and poor fault containment. QNX moves drivers and services into user space to maximise reliability and security, paying for the choice in raw performance through message passing. Windows' hybrid design is the deliberate compromise: monolithic-class performance for the subsystems that matter, with a measure of structural modularity. These philosophies map directly onto each system's success — Linux in high-performance computing, Windows on the general-purpose desktop, QNX in safety-critical embedded systems.

6.2. Overall Insights

The most significant insight of this study is that operating-system design is inherently a set of trade-offs. There is no 'best' architecture — only the right architecture for a set of priorities, which is precisely why such distinct models remain prevalent today. The engineering act is not fixing a weakness but choosing a design whose strengths are what the system needs and whose weaknesses it can tolerate. That principle is why a monolithic kernel remains the right choice for a cloud data centre, and why one insists on a microkernel for a braking system. Architecture is the OS's promise to its user about performance, stability, and security.

6.3. Recommendations and Future Directions

Three research directions stand out. Formally verified kernels: seL4's mathematical proof of correctness for an implemented system marks a departure in methods for high assurance; extending the approach to more of the kernel, and quantifying its performance penalties, deserves further work. Unikernels and library OSs: producing a single-purpose, single-address-space image with minimal OS library requirements promises bespoke, secure, efficient deployment for cloud and IoT — and questions what an OS even is (Madhavapeddy & Scott 2013). Hardware co-design: with heterogeneous hardware — CPUs, GPUs, FPGAs — future kernel architectures must move beyond CPU-centric models toward natively managing diverse processing units.

At a deeper level, this work testifies that kernel architecture is not an exercise in accumulated history but a dynamic, living area of computer science. Performance, security, and reliability cannot be separated, and the balance among them will remain a major source of innovation as new computational demands arise.

References

1. Custer, H 1993, Inside Windows NT, Microsoft Press, Redmond, WA.
2. Heiser, G 2014, 'The role of virtualization in embedded systems', Proceedings of the 51st ACM/EDAC/IEEE Design Automation Conference, San Francisco, CA, pp. 1–6.
3. Hildebrand, D 2007, An architectural overview of QNX, technical documentation, QNX Software Systems, viewed 24 September 2025, https://www.qnx.com/developers/docs/6.3.0/neutrino/sys_arch/kernel.html.
4. Klein, G, Andronick, J, Elphinstone, K, Heiser, G, Cock, D, Philip, D, Elkaduwe, D, Engelhardt, K, Kolanski, R, Norrish, M, Sewell, T, Tuch, H & Chakravarty, M 2014, 'Comprehensive formal verification of an OS microkernel', ACM Transactions on Computer Systems, vol. 32, no. 1, pp. 1–70.
5. Koopman, P 2017, 'Safety for safe autonomous systems', Proceedings of the 2017 Design, Automation & Test in Europe Conference & Exhibition (DATE), Lausanne, Switzerland, pp. 1667–1672.
6. Liedtke, J 1995, 'On µ-Kernel Construction', Proceedings of the 15th ACM Symposium on Operating Systems Principles, Copper Mountain, CO, pp. 237–250.
7. Madhavapeddy, A & Scott, D 2013, 'Unikernels: library operating systems for the cloud', Proceedings of the 18th International Conference on Architectural Support for Programming Languages and Operating Systems, Houston, TX, pp. 435–448.
8. Ritchie, DM & Thompson, K 1974, 'The UNIX Time-Sharing System', Communications of the ACM, vol. 17, no. 7, pp. 365–375.
9. Russinovich, ME, Solomon, DA & Ionescu, AC 2017, Windows Internals, Part 1, 7th edn, Microsoft Press, Redmond, WA.
10. Silberschatz, A, Galvin, PB & Gagne, G 2018, Operating System Concepts, 10th edn, John Wiley & Sons, Inc., Hoboken, NJ.
11. Tanenbaum, AS 1987, Operating Systems: Design and Implementation, Prentice-Hall, Inc., Upper Saddle River, NJ.
12. Tanenbaum, AS & Bos, H 2015, Modern Operating Systems, 4th edn, Pearson Education, Inc., Upper Saddle River, NJ.
13. Torvalds, L 1991, 'What would you like to see most in minix?', online post, 25 August, viewed 24 September 2025, https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/SwRav0sdPw4J.
14. Verma, A, Pedrosa, L, Korupolu, M, Oppenheimer, D, Tune, E & Wilkes, J 2015, 'Large-scale cluster management at Google with Borg', Proceedings of the 10th European Conference on Computer Systems, Bordeaux, France, pp. 1–17.