t of work to prove what we already know from analysis: NT 4.0's stability will not be substantially affected by the Ring 0 change.
The real issue is -- and always has been -- unruly or buggy device drivers. Essentially, they have always been part of the OS and have had low-level control of the CPU. Bad ones will crash NT 4.0, just as they've brought all its predecessors to their knees. Microsoft is trying to steer people away from risky behavior by telling them to use only hardware that's on a Microsoft-approved list. A product's placement on the list means that Microsoft has written and debugged its device driver.
Admittedly, this smacks of a smug solution that serves to place the onus on users while requiring them, in some cases, to buy new hardware when they upgrade to NT 4.0. But again, the same was true with previous versions of NT. We think mo
st corporate buyers of NT are not likely to stumble blindly into hardware conflicts, especially with their mission-critical servers.
It's true that when NT's GDI wasn't in the kernel's memory space, a crash theoretically was more likely to freeze only the screen, leaving background processes intact. We haven't heard of this ever happening, however. Besides, rebooting would be inevitable, since at some point the user would need access to screen output.
Finally, some nervousness about the GDI move to the NT kernel derives from a misunderstanding about what Ring 0 status means. It does not mean that a process has carte blanche to write anywhere in memory that it pleases. Rules exist, but poorly written or malicious drivers have always been able to ignore them.