I think the Windows NT kernel is a very underrated piece of technology - the reason it was unstable in the beginning is due to a corporate top-down decision: the hardware of the time was limited so they included GDI stuff in the kernel (crappy code not written by Cutler's team).
Err, no. The reason it was unstable in the beginning were choices like having a "MUST SUCCEED" kernel memory pool which caused a bugcheck if the system could not allocate from that pool. Random kernel components allocated from this pool and if you opened too many handles (sockets for example), you'd get a bluescreen because an unrelated driver was trying to allocate memory for some other activity.
There were probably other similar choices that I don't remember now. It has been 25+ years.
And let's talk about the NT Driver I/O model. The most highly complex, over-designed POS I have ever seen. And this design was "polluted" for performance out of the gate (Fast I/O path, for example). It took Microsoft years to reliably and safely cancel pending I/O in the kernel. Remember the days when a random peripheral driver could hold on to an IRP and cause bluescreens all over the place because the process it was doing I/O for exited ? It was hard for internal Microsoft people to write good drivers, let alone OEMs in the wild with a fraction of the learning resources at their disposal.
NT was based on the microkernels that were fashionable in those days (e.g, Mach from Rick Rashid et. al). As with most academic ideas, when microkernels met the real world they had to be adapted.
Win32K came about because GDI performance in NT was crap. There were other things that were similarly pushed into the kernel already. I believe a classic microkernel would also have networking modules in user mode, for example. DirectX in the kernel (hated by the purists back in the day) is inarguably responsible for NT being able to supplant Win9x in the consumer PC market.
The NT kernel evolved over the years to be something that actually met the needs of Microsoft's customers. I would argue that's the real achievement, and not all of that can be laid at the feet of "Cutler's team".
I second the recommendation for "Show Stopper" :-)
We should give credit to the early architectural decisions made by Cutler which allow for niceties like the Windows Subsystem for Linux (WSL) that came about recently.
I third the recommendation for "Show Stopper" as well. :-)
i think most - 99.999% - credit here goes to Linus :) Given the modern power of Linux the WSL would have happened anyway - independently of whether early NT architectural decisions help it or preclude it.
For the POSIX, Win32, and OS/2 subsystems that existed at the birth of NT, the kernel capability was all Cutler, and Linux was in no position to contribute.
Showstopers explains the NT kernel personalities.
In particular, I really admire the people who worked on that project, because they had a lot of field-tested reasons for the things they were doing.
But the whole subsystems concept basically cleaved the logical domains in a way that was obviously, even at the time when I read it, not going to extend well in the future. While the POSIX and OS/2 stuff can be seen as a kind of hubristic base-covering (the one kernel to end all kernels), it should not have made the cut in a disciplined engineering organization.
Which is not really surprising , considering that Dave was one of the main architects of VMS.
On a personal note: Best OS I ever worked with. Rock solid stable and a few conecpts and tools, which are still unmatched. At to that the arguably best documentation I've ever had the pleasure to work with in any environment.
Documentation for everything was a lot better in the 70s.
DEC, however, was in some respects really above the pack. Documentation being one of them.
I'd throw in DECnet and VAX Clustering as other examples.
At least I have seen the GPU driver crash on Windows 7 machines - the screen went blank for a second or two, then it showed the same desktop as before, with a popup that rougly said, "The GPU driver crashed, so I restarted it."
The scripting in CMD.EXE has been described as a "serial killer," and they really would have been better off implementing a Bourne shell for Windows.