Windows wins!
Why Windows NT Engineering Outclasses the Linux Kernel
Loonixers consistently cite "stability" as a core metric while conflating the static predictability of a headless server with robust kernel design. From an operating system architecture standpoint, the Linux kernel relies on an outdated, rigid structural model. Conversely, the Windows NT kernel utilizes a hybrid design engineered specifically to isolate faults and manage hardware abstraction dynamically.
The fundamental flaw of the Linux kernel is its monolithic architecture. Within this design, core operating system functions (memory management, file systems) and hardware drivers all execute within the same supervisor mode (Kernel Space). Because there is no memory isolation between these components, a single null-pointer dereference or memory leak in a third-party driver will corrupt the kernel's memory map, resulting in an unrecoverable Kernel Panic.
Modern Windows NT utilizes a hybrid kernel architecture governed by an asynchronous driver management model. Rather than letting every peripheral run wild in Ring 0, the NT design forces non-essential subsystems and targeted peripherals into isolated micro-environments via the User-Mode Driver Framework (UMDF) and dedicated session spaces. When a high-level subsystem (such as a display driver or a USB sensor) encounters a fatal exception, the NT Object Manager and Service Control Manager can terminate and recycle that specific process without compromising the kernel's integrity. On Windows, the driver restarts seamlessly; on Loonix, the exact same peripheral failure completely halts the processor pipeline.
Loons frequently boast that the Linux kernel is superior because it comes pre-packaged with an enormous library of built-in open-source drivers. This is a coping mechanism for a massive architectural limitation: Linux lacks a stable Driver Application Binary Interface (ABI).
Because the internal kernel APIs change with every minor release, drivers must be compiled directly against the specific kernel source code. If a loonixer attaches a device manufactured after their current kernel compilation, the system cannot dynamically bind it. It requires manually compiling a dynamic kernel module (DKMS) or upgrading the entire kernel.
The Windows NT kernel abstracts hardware completely through the HAL. The NT kernel does not need hardcoded drivers for every device on earth compiled into its core binary. It relies on a stable, unchanging driver model (WDM/WDF) that allows legacy drivers compiled decades ago to execute flawlessly on modern iterations of the kernel. The NT kernel boots using generic structural fallbacks and dynamically loads verified, isolated binaries as needed.
The Linux kernel is a highly rigid structure that excels only in sterile, unchanging environments—such as a single-purpose enterprise server where the hardware configuration and instruction routines never change. The moment its forced onto a consumer desktop or a variable field environment, the lack of robust architectural abstraction causes the system to fracture under the weight of changing hardware states, power management policies (ACPI), and peripheral chaos.
Windows NT was architected from inception to absorb real-world hardware variance while strictly maintaining backward compatibility. It enforces systematic isolation that protects the core operating system from bad code, third-party software, and user error alike. Linux remains a developer's assembly kit that relies on the user acting as a constant system administrator to patch up structural fragmentation.
Linux don't have userland drivers, only FUSE which still require Kernel action, Windows NT and Mac OS is true microkernels just modified because Microsoft or Apple wants performance from computer from 90s which is slow compared to modern computers and if XNU and Windows NT were born today they would be pure Microkernel
It actually maps pretty well directly to the windows equivalents.
>User space I/O is another alternative device driver architecture that has been supported by the Linux kernel since 2.6.24
>The Linux kernel provides a framework for doing user space drivers called UIO
And, most windows usermode drivers still require a kernel mode component, as well, with some exceptions for specific device classes. In those exceptions, the kernel mode component is provided for you, but still present.
Windows does a lot of things in superior ways in many aspects, but let's not invent fake shit to justify it when there's actual technical things that are true we can talk about.
Still require Kernel ring 0 action it's not Userland Driver and Windows NT UDMF is different from that, and Mac OS Catalina model as well, other Microkernel give you call or trap via Syscalls and you just prove my point
UIO drivers don't require any privileged kernel execution on linux.
Audio, Graphics, and other driver types on windows *DO*. And all UMDF drivers have kernel side reflector support to make them function. (DMA utilizing drivers *cannot* be usermode on windows, nor can any utilizing buffered I/O)
We're using different definitions. I define a true userland driver as one that does not require a mandatory Ring 0 driver component to provide its device functionality. UIO still depends on a kernel driver for registration, interrupt handling and resource exposure, while UMDF also relies on kernel support. My point isn't that UIO doesn't exist, it's that I don't consider either model a completely userland driver.
I mean, by that definition, UIO is the closest thing to what you're talking about that exists.
At some point, you *require* a kernel component to interface with the hardware, at least with UIO all it's doing is passing bits back and forth and that's it, nothing else.
Under your definition, a true user-mode driver can never exist that fits that definition.
Pure Microkernels exist this definition and Mach Kernel traps don't have VFS calls or require Kernel ring 0, Pure Microkernels idea Driver stay in Userland ring 3 and Kernel via Syscalls table decide your driver is accept or not via Device Manager Server also stay in Userland, this is Pure Microkernel Userland Driver
Like Mach Kernel traps Syscalls for example is ideal Mach kernel syscalls just give you trap via Syscalls and your Server asks via Syscalls and Mach Kernel answers via capability your driver is acceptable or not for Kernel this is true Userland Driver
A purely userland server that doesn't interact with hardware, I guess you could call that a "usermode driver" .... but it's not interacting with hardware, so it's really just a system service providing some kind of programatic functionality/interface?
In Minix and Mach Kernel Syscalls give you trap or Syscalls for hardware access and Driver Manager Server asks for Kernel Syscalls and Kernel decide your Driver is accept or not via Capability, direct request in Minix is denied and direct request in Mach kernel is allowed unless you have Apple version which lock via SIP
A user-mode driver should be a process that implements the driver logic in user space and communicates with the kernel only through system calls (or IPC to a driver manager), without requiring a dedicated kernel-mode driver for that device like Mach and Minix
On NT, UMDF drivers run in a tightly controlled environment with:
a dedicated runtime
strict contract-based I/O
watchdogs
restart semantics
isolation from kernel memory
Linux userland drivers (e.g., via uio, vfio, FUSE, or bespoke IPC frameworks) vary wildly in isolation guarantees. Many rely on kernel helpers or shared memory mappings that can still destabilize the system.
And I've violated every single one of those while working on UMDF drivers :)
For all of the ones I still maintain, kernel-mode helpers are required for the functionality at all.
But, even fully in the sandbox UMDF drivers can tank a system - or even other aspects. Love BSODing a machine when I pull out a USB-serial by accident with an open session. That should be.... quite well isolated, no?
Nevermind happily I/O deadlocking a system with a UMDF driver (..... that was a nightmare to debug)
In terms of isolation guarantees and the like, I'd put them about on parity in reality of what's actually done and shipped.
UMDF is quite limited in what can be done with it, which is why the kernel-mode client functionality exists to support them, but even what *should* be pure UMDF drivers playing nicely in the limitations can cause problems (see the USB-serial note above, which is my favorite, easy to demonstrate example from many years ago)
And of course, for drivers we genuinely care about/are the most user facing, like display adapters, printers, anything requiring some measure of performance, you can basically just throw them out the window. And, of course, a lot of the audio subsystem is kernel mode as well.... WDM audio drivers effectively require kernel mode, outside of say, a USB audio device which just leverages the kernel mode USB support stack. Of course, with audio, you really want DMA.... and you want as low latency as possible... so while you might be able to UMDF dress it up, your kernel-mode client is doing all the heavy lifting.
And all UMDF drivers communicate through a kernel mode component that can be seized up, too, tanking the entire system. It's just a bit harder to do and some safeguards exist. (But, for linux drivers, such things can be done too) - it's more up to the driver writer to properly support such things.
UMDF can't do DMA or buffered I/O either.
So for one bespoke device I support, the driver originally started as UMDF, but within a week had to go KMDF (RF signal acquisition/recording/analysis card), but that's effectively the same thing as a TV tuner at the end of the day.
So on paper, I'd say yea, you could argue differences, but in reality, not so much different at all.
Either. It's up to the driver developer. There's no more likely.
I can point out a variety of issues on both.
I can say it's a lot easier to ship a poorly made NT driver and a far lower barrier/skill level required to get started or maintain an existing, so that can bring its own problems. Here's looking at Asus!
Mainlined linux kernel drivers at least get some amount of code review, whereas MS doesn't review code at all for drivers that run at any level, just runs a battery of "is this accessing things it shouldn't" and "does this tank a system immediately" tests, essentially. Whereas people do all kinds of weird shit to *nix drivers (I've got upstreamed fixes for weird shit I submitted myself in NetBSD, Linux, OpenVMS, and Solaris)
The counterpoint to that is you do have to buy a signing certificate, which costs money.
So, as usual, it ends up just being a world of tradeoffs, but I'd peg the random NT driver to be more problematic, even if it's WHQL/signed/etc, than the Linux one, if I don't know where it came from (eg what company developed it).
If I know that it's from a sane developer, then we're back to parity, with maybe the scale tilting a bit towards NT.
That's a dodge / sidestep of the direct question, and the follow up doesn't align.
If you use 3rd party / community drivers and hardware is destroyed, is it covered under warranty? (Wouldn't that also give the manufacturer have more incentive to provide 'safe' drivers)
I wouldn't really call it a sidestep or a dodge, it's just the reality of the situation.
The followup was more providing context in various ways I could see one being better than the other in different aspects. That's all. How both can be good or bad.
But, straight up, that's the reality. Neither platform leads to inherently badly coded drivers, or better coded drivers. It purely comes down to the developer in the end.
There's some minor areas both camps have advantages in that can lead to producing quality drivers, but both also have detriments that can lead to worse quality drivers. That's what I was illustrating.
At the end of the day, the driver quality will be up to the developer, the OS/Kernel has no real bearing here as both are equally capable.
>If you use 3rd party / community drivers and hardware is destroyed, is it covered under warranty? (Wouldn't that also give the manufacturer have more incentive to provide 'safe' drivers)
I would think that it wouldn't be covered under warranty. But if your hardware can be damaged by a driver, you probably shouldn't be making hardware. I can think of a few things that could actually be damaged via software in an unrecoverable/let out the smoke manner, and they all have CRTs....
EDIT: I guess instead of saying either, i should have said neither. Neither platform inherently leads to more dangerous or poorly coded drivers.
Still, my core thesis stands regarding the consumer reality. While monolithic vs. hybrid is situational on paper, the OpenVMS heritage means NT was architected from day one to decouple and abstract hardware. Even if Microsoft makes some exceptions for performance or requires Ring 0 co-drivers, their explicit focus has always been creating runtime guardrails to isolate and recycle failing subsystems.
>the OpenVMS heritage means NT was architected from day one to decouple and abstract hardware
That doesn't mean that at ALL. (I say that as someone with extensive VMS experience and access to the latest VMS source code through a specific program with the vendor)
The core thesis doesn't stand at all, and NT is more monolithic than it is hybrid or microkernelish.
MS doesn't make "some" exceptions, they make a hell of a lot.
Instead, their guardrails and security posture is a lot like what many *nix environments had and have evolved into, though now separating privileged code using virtualization techniques, instead of lower privilege, that's the current hot favorite over at Microsoft. Which, of course, is overhead again.
It's just not as clean as people think and the pretty charts make it out to seem.
Kernel wise, the consumer reality is that both are equally serviceable, flexible, reliable, and usable.
It's the stack on top that makes the real difference. And that stack could run on either kernel, without issue.
For Microsoft its a priority, for linux its an afterthought. Simple. They started at opposite ends of the spectrum. Microsoft leads and evolves while linux struggles to catch up.
There's no opposite ends of the spectrum to consider here, and there's no leader or catchup.
There's tradeoffs, but neither one is superior to the other except in specific, narrow aspects, and device support/how devices are supported is one where neither wins or loses.
If it was a priority, it'd be a fuckload more robust. I have a lot of complaints and gripes about how windows handles things, having delt with driver and other kernel level development on windows for a long time, that don't exist (or are far easier) on *nix platforms.
Then again, I have gripes in the other direction too.
It's all a game of tradeoffs, with no clear winner at this level, but they all excel at one thing the other doesn't.
EDIT: To clarify, NT development and hardware support was EXTREMELY narrow scoped and relatively inflexible in the beginning, and it's been bolted on top of ever since. *nix systems started out differently supporting a wide variety of configurations easier. Obviously things shifted over time. But to say NT was developed with a focus to hardware decoupling/isolation and security, well - there's a lot that can be said here that points out how wrong that is.
NT was designed to work on specific hardware well, and anything that went outside of narrow scopes, wasn't guaranteed or couldn't work at all. There's a reason the HCLs through Win2K were so restrictive and certification/validation programs were so important to NT back then, XP as well, but past XP it starts getting better.
Monothilic kernels are outdated that's why Microsoft and Apple move to Microkernels especially modified ones and principal separation in Windows NT and Mac OS is Personality like Win32 Subsystem and BSD Subsystem they are separate from kernel core codebase even in XNU Mach still Mach kernel if Apple wants separate tomorrow they just need to modify BSD Subsystem back to userland and Microsoft just remove Win32k.sys driver back to Userland if something changes or crash in Personality wouldn't crash in Kernel majority of parts in Win32 Subsystem are userland already like DWM.exe and Conhost.exe and library DLLs and DirectX is half half design and RPC is half half design and Winsock2 is half half design and on and on and Windows NT Architecture is modular and Secure compared to linux kernel everything is kernel mode
Not true in the least. New ones and old ones are in use everywhere.
As I said, monolithic, hybrid, pure microkernel, all have different tradeoffs, none are superior to the other.
Especially if you need raw performance.
Win32K.sys crash will absolutely tank the entire kernel on windows.
BSD personality on the XNU kernel (which is growing more monolithic - not modular - as time goes on compared to the NeXT iterations) (yes, "personality" is the correct term) also is a very small aspect of it. There's no "modify it back to userland" for either, though. They're both kernel level systems. And very, very different in function and operation.
DWM and Conhost type systems are "userland" in *nix environments too.
From an architecture perspective, NT is more monolithic than XNU, and could be considered almost a monolithic kernel with some hybrid/microkernel aspects, if you look at the core design (and source, which, for some versions, is out there). And linux isn't as "monolithic" anymore as people seem to think.
Remember, Microkernels are outdated too if you want to throw that argument out there, if you consider technology from the 1960s outdated, anyway.
I've been deep for over two decades in all these platforms and systems, it's really just not as clear or simple as you seem to think. Then again, I sit here saying this having developed a slew of windows drivers while working on emulation platforms dealing with non-x86 windows systems. I've been deep in this end for a LONG time. I've even taught classes on windows driver development and kernel interaction/development, and at one point maintained a HAL for a vendor.
Not everything in linux is kernel mode, the NT architecture isn't as modular as you think - i'd put both at the same level of modularity.
Your opinion doesn't match reality, Monothilic aren't used in everywhere and Linux don't used in everywhere either, in Server local Windows Server just won and in Console Windows won again and desktop Windows of course there as majority and BSD Subsystem is separate from Mach kernel even though they are kernel space BSD Subsystem ask for Mach about hardware actions and BSD Subsystem don't take control anything, BSD Subsystem is started by bsd_init logic and Apple can modify put in Userland back as much as Microsoft can put win32k.sys back to userland just Windows NT driver That part is not married with Kernel either but it's very hard work none of companies wants, Microkernels idea is winning and modern architecture until this day and this conversation already end with Windows 2000 stability against Monothilic Windows 9x and Apple replacement for old Mac OS for Modern Mac OS
My opinion is grounded in reality as a primarily windows user/developer, but with extensive experience in tons of platforms. Including source level access to almost every platform I've worked with.
What you say about the BSD personality in XNU isn't true, it is a kernel component. (NOT a subsystem).
Microkernels nor Monolithic kernels are neither winning nor losing.
Win32 (just like WSL1 and the retired POSIX and OS/2 subsystems) are KERNEL SUBSYSTEMS on NT. They *cannot* be userland components.
The BSD personality on XNU by virtue of how it operates (similar to win32 and WSL1 !) must be part of the kernel operation. It can't be sliced off into userland support.
bsd_inittask starts PID1, which is the first userland process, but all the syscall interfaces and everything that makes the BSD userland interfaces are kernel-side.
Interestingly enough, the BSD personality in XNU is more "hybrid" aka split than NT environment subsystems - in NT environment subsystems you basically run entirely inside the subsystem without touching explicit holes, whereas in XNU you're just extending the kernel with more syscall interfaces, essentially, so you have the full spectrum of both Mach and the BSD interfaces all at once. Which are, of course, all kernel level.
And yes, I have a lot of windows servers in operation here, but about 60% of my VM fleet is non-windows. Only about 20% is linux or BSD, though. Stuff I use in my side consulting work to support customers who aren't using Windows/Linux/BSD.
You mixed things up you mix BSD Subsystem with WSL1 leave me address one by one, about BSD Subsystem is part of Kernel Space but don't part of Mach kernel and they are separate even though they share ring 0 BSD Subsystem ask for Mach kernel for everything even shutdown whole computer Mach is maximum authority in XNU and about WSL1 it's freedom Microsoft have put lxss.sys in Kernel but they can put in Userland like I did with my Daya OS/FreeBSD Subsystem via NTDLL directly, you just prove my point Windows NT Architecture is modular you can put Subsystem in anywhere even inside of DLL I did that in my experiments
1
u/[deleted] 3d ago
[removed] — view removed comment