Stable driver APIs (WDDM for graphics, IFS for in-kernel file systems, and others for other areas) are one of the big differences between NT's (micro-)kernel and Linux' (rather monolithic) kernel with no API commitment.
Of course, "stable" may vary. Microsoft introduced a new kernel graphics API with every OS after NT4 (XDDM, XPDM, WDDM 1.0, 1.1, 1.2, 1.3, 2.0; I wonder which ReactOS uses?) because of how significantly GPU capabilities changed over the years; while Linux changes its APIs more often than that, the changes are usually minimal enough that neither Nvidia nor AMD are complaining significantly about it. (The X¹¹ API, on the other hand…)
My understanding is that NT is more of a hybrid kernel than a true microkernel. Is that still true or has it moved more towards a micro kernel in recent years? I remember reading an interesting article about the influence of Mach on NT, but that they ended up having to put a lot of stuff (including the Executive) into kernel space for performance.
It's hybrid indeed, but far more modular. The driver code is running in kernel mode to avoid costly switching from kernel to user mode and back. This imposed requirements on driver code quality as it is critical for the entire system, but it can be replaced (with another version) as a component. For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing.
> For a monolithic kernel like Linux changing a driver like the one for video card means recompiling the entire thing.
Not necessarily, Linux has loadable kernel modules as well and most drivers are built that way and loaded on demand. The Nvidia proprietary drivers for instance are a loadable kernel module, though they are tied to a specific kernel version. BSD does basically the same thing.
There are somewhat more subtle differences: Not only are modules not tied to a particular kernel, they are also (to varying degrees) isolated against the rest of the kernel.
WDDM in particular can recover from a driver crash and restart hardware and driver (which you can trivially demonstrate on an AMD card by waiting for an hour or two…), while Linux (and Windows XP with its older driver model, and probably BSDs) will panic the entire kernel on problems like this.
Yeah, that's what I thought with NT, which is that drivers are much more isolated. If I understand it correctly drivers can still cause a kernel panic, but Microsoft requires that signed drivers pass a formal verification, which has greatly cut down on blue screens. I'm just an armchair observer though, so I'm not an expert.
I was always greatly impressed by Windows' recent ability to recover from something like a display driver crash with hardly a hiccup. That's pretty impressive voodoo.
Of course, "stable" may vary. Microsoft introduced a new kernel graphics API with every OS after NT4 (XDDM, XPDM, WDDM 1.0, 1.1, 1.2, 1.3, 2.0; I wonder which ReactOS uses?) because of how significantly GPU capabilities changed over the years; while Linux changes its APIs more often than that, the changes are usually minimal enough that neither Nvidia nor AMD are complaining significantly about it. (The X¹¹ API, on the other hand…)