> the people who brought you kernel mode printer drivers and the Blue Screen of Death
the scenarios that result in errors are totally different from the error scenarios in linux. most of the crashes in windows systems are the results of non-MSFT developers who wanted to insert code into the kernel. these kinds of errors happen on linux too, if you use binary nvidia drivers and/or vmware.
> requires such gems as having to intentionally reproduce undocumented historical bugs because legacy applications rely on them.
the "compatibility layer" is actually far more nuanced than this, and only turns on the old and bad behavior if it recognizes that it's being used by an application that requires the old and bad behavior.
> Windows was designed by a committee in a hurry.
NT was designed by the team that did VMS in a 3-month retreat to Hawaii. the design they created has lasted with very minor modifications for the last twenty years. can linux say the same?
It's not necessarily a good design just because it has lasted for 20 years. It might just be that it's too expensive to change any of it. Although I should probably say that I'm not informed enough to judge
Not really. It's more like the Windows problems are a superset of the Linux problems. Most kernel panics are a result of bugs in drivers which happens just the same on Windows. Then you have all the ones based on Microsoft laziness, like getting the INACCESSIBLE_BOOT_DEVICE BSOD instead of the OS trying to load some more drivers if your disk controller died and you replaced it with a different model. And then you have the fallout of Microsoft's attempts to fix legacy software rampaging through kernel memory, which means all the legacy code that used to do that (including the ones that did something useful instead of causing a BSOD) will now just crash the application and break the legacy software, because Microsoft couldn't be bothered to get it right the first time.
> most of the crashes in windows systems are the results of non-MSFT developers who wanted to insert code into the kernel.
The difference is that Unix-like operating systems have always discouraged that behavior so it happens a lot less often (and is a lot more suspicious), and if you have something that legitimately needs to go into the Linux kernel then it generally gets merged into the main tree. But not until you fix what problems the kernel maintainers identify, and then it gets maintained by the people who know what they're doing.
> the "compatibility layer" is actually far more nuanced than this
Sounds unnecessarily complicated and undesirable.
> NT was designed by the team that did VMS in a 3-month retreat to Hawaii.
NT was never the problem. That's like saying ReactOS will be good because it's designed by smart people. The "design" is already cribbed by what came before it and the box it now has to live in, which was set out by DOS and Windows 95. Microsoft now has to live with that legacy, why should the rest of us?
How long does it take to design an OS, once you've already done one, and there are others to use as reference?
I don't think there was ever a similar moment in the history of Linux, because Linus copped the design of UNIX, and he states this freely and matter-of-factly.
The difference is that UNIX was designed by AT&T Bell Labs and largely standardized with POSIX. Whereas Windows was designed by the people who brought you kernel mode printer drivers and the Blue Screen of Death and a working implementation requires such gems as having to intentionally reproduce undocumented historical bugs because legacy applications rely on them.
WINE makes sense because it's transitional. It allows you to switch to a better operating system without having to abandon all vestiges of legacy software at once. It's software you like to exist but you still hope to never have to use.
Which is why a full Windows clone is silly. It's not transitional. Windows was designed by a committee in a hurry. There are plenty of good reasons not to want it completely regardless of the license it's distributed under.