One question, many answers
Back in the foundations you met the great structural question of kernel design: do you pack every service — scheduling, memory, file systems, drivers — into one big privileged program, or do you keep the privileged core tiny and push services out into ordinary processes? The first answer is the monolithic kernel, fast because everything is a function call away but large and tightly coupled. The second is the microkernel, cleaner and more isolated but paying for every service request with a message that crosses a protection boundary. Linux, which the last guide covered, is firmly monolithic.
Real systems, it turns out, rarely sit at either pole. The dominant design in shipped desktop and mobile operating systems is the hybrid kernel: a pragmatic middle ground that borrows the layered, modular ideas of the microkernel but keeps the performance-critical pieces together in kernel space to avoid paying the messaging tax on every operation. Windows and macOS are both hybrids, arrived at from opposite starting points. Holding the monolithic-versus-microkernel axis in your head is the single best lens for reading the four systems in this guide — each one is really just a different point on that line.
Windows NT: layers under a familiar face
The Windows you use every day runs on a foundation called NT, and its NT architecture is a careful stack of layers. At the very bottom sits the Hardware Abstraction Layer, the HAL — a thin shim that hides the differences between machines (interrupt controllers, timers, bus details) so that everything above it can be written once and run on many kinds of hardware. Above the HAL is the kernel proper, a small layer responsible for the rawest duties: scheduling threads, handling interrupts, and synchronizing across processors.
On top of that kernel sits the Executive, the broad set of core services — memory management, processes and threads, security, I/O, and the object manager that names everything in the system. Higher still, and crucially, are the environment subsystems: separate personalities that present an operating-system interface to applications. This layered, subsystem-flavoured design is exactly what makes NT a hybrid kernel — it carries the modular spirit of a microkernel, with a HAL and clean layers, while keeping the Executive and kernel together in privileged space so the common path stays fast.
macOS and iOS: a Mach core wrapped in BSD
Apple's macOS and iOS both run on a kernel called XNU, and its story is a different route to the same hybrid destination. XNU's innermost core is Mach, one of the original research microkernels, which handles the deepest primitives: scheduling, virtual memory, and message-based inter-process communication. Wrapped around Mach is a layer derived from BSD, a member of the Unix family, which supplies the things programmers expect from a Unix system — processes, signals, the file system interface, and the networking stack. The familiar Unix tools on a Mac are talking to that BSD layer.
Here is the subtle and important part: although Mach was designed as a microkernel, XNU does not run it the textbook way. In a pure microkernel the BSD half would be a separate user-space server exchanging messages with Mach across a boundary. XNU instead compiles Mach and BSD together into a single kernel-space program, so a Unix system call does not pay the message-passing cost of a real microkernel. That fusion is precisely why XNU is classed as a hybrid kernel: microkernel bones, monolithic packaging. Windows reached hybrid by layering a small kernel; Apple reached it by fusing a microkernel with a Unix layer — two roads, one pragmatic middle.
Android: the same Linux, a different world above it
Android makes a point that is easy to miss: the kernel and the user space above it are separable choices. Underneath every Android phone sits the very same Linux kernel you read about in the last guide — monolithic, doing the scheduling, memory management, and driver work exactly as it does on a Linux server. What makes Android feel nothing like a Linux desktop is everything stacked on top: a managed runtime that runs app code in a controlled environment, and a rich application framework that defines how apps are built, sandboxed, and permitted to talk to each other and the hardware.
This is a genuinely clarifying example. We tend to say 'an operating system' as if kernel and user space were one inseparable thing, but Android is proof they are not: take an unchanged Linux kernel, bolt a completely different user space on top, and you get a system that feels like a separate species. The same lesson runs the other way too — much of what you experience as 'using Android' is application-framework policy, not kernel behaviour, which is why two phones on identical kernels can behave so differently.
Real-time and embedded: when on time beats fast
All four systems above optimize, in the end, for throughput and responsiveness on a general-purpose machine. The last family inverts the priorities entirely. A real-time operating system, or RTOS, is judged not by how much work it does per second but by whether it does the right thing at the right moment, every single time. The crucial distinction is hard versus soft real time: a soft system would merely prefer to meet its deadlines, while a hard system must meet them — a missed deadline in an airbag controller or a pacemaker is not slow, it is a catastrophe.
Because of this, an RTOS prizes a property general systems happily sacrifice: predictability over raw speed. A desktop scheduler is delighted to make the average case fast even if the occasional task waits a long, unpredictable while; an RTOS must instead guarantee a tight, knowable upper bound on how long any critical task can be delayed. This is why real-time scheduling leans on deadline-driven algorithms with provable timing rather than the throughput-maximizing tricks of a general scheduler. Slower-but-always-on-time beats faster-on-average-but-sometimes-late, when late means harm.
Real-time systems usually live inside an embedded operating system: the tiny, often invisible software running on a microcontroller inside a thermostat, a drone, a car's engine, a washing machine. Here the constraints flip again — there may be only kilobytes of memory and no disk at all, so the OS must be minuscule, and the same code may run untouched for a decade with no user to reboot it. Footprint and reliability outrank features and flexibility. An embedded OS does less on purpose, and that smallness is the whole point.
Reading any OS by its trade-offs
Lay the five systems out and a single map appears. Linux is monolithic, optimized for throughput and breadth of hardware. Windows and macOS are both hybrid, reaching that middle from opposite directions — NT by layering a small kernel under an Executive, XNU by fusing the Mach microkernel with a BSD Unix layer. Android shows the kernel and user space are independent choices by putting a wholly new world on top of an unchanged Linux. And the RTOS abandons throughput entirely for guaranteed timing in a tiny footprint. None is simply 'best' — each is the right answer to a different question.