[N3WBI3]

Seeing as video drivers can do things like, well, set the clock speed of the gpu and ram I'm having a hard time understand how you would prevent them from impacting stability.

Because the drivers should not live in Kernel land (use Kernel Memory Space) short of s Bus going drivers should not touch the core of the system. If a video driver fails I should lose my monitor and get a ton of crap put out to an error log.

But the whole reason you have a driver is the O/S by itself doesn't know how to interact fully with a piece of hardware.

What they understand is that a Turing machine teaching you the essentials of an OS. Other than the system Bus, Memory, Processor, and maybe some storage you should not *need* anything else to keep a system running. If the monitor, mouse, keyboard, speakers, Ethernet, .... go the system itself should not crash.

Something along the lines of... well, we can add another layer of abstraction and keep the system more stable, or we can not and have faster video. Seeing as there are a lot of people who rely on NT to deliver good performance on applications such as Microstation, they chose the latter.

NT was there shot at a server environment, people run web servers, database servers, mail servers and the lot on them. It was a long time from designing NT to releasing an NT Kernel intended for the desktop. So when putting together a server whats more important fast flashy graphics or stability (Hint on my *nix servers I rarely even install X).

Maybe I'm naive, but I have a feeling this was a hotly debated topic inside Microsoft. Maybe it was a wrong decision, but if you want to debate it you can't ignore the impact it would have on performance.

Sure we can, with Video cards themselves having so much memory all MS needed to do with another layer is provide a solid API (I know well documented API's are hard to get out of Redmond) so they can let the card do all the work.

SGI puts video performance in its own layer and I think they are kinda known for something to do with graphics..

[Paridel]

Other than the system Bus, Memory, Processor, and maybe some storage you should not *need* anything else to keep a system running.

OK, so you need the memory, processor, and system bus to keep the system running? The Accelerated Graphics Port (AGP) is attached directly to the primary system bus (unlike older PCI cards which where on the PCI bus, separated by a bus bridge between the primary system bus). The AGP controller also has a direct line into the memory controller. (I'm not quite sure of the workings of PCI-express so I won't going into that).

But at least with AGP clearly a layer of abstraction was removed with the switch from PCI to AGP cards. AGP based video cards can view the main memory and video memory as one dynamic pool.

What I'm trying to get at is that you are claiming that removing drivers from Kernel land could in some way prevent a system going down from a driver error. In that claim you are making one big assumption, and that is that the hardware is as encapsulated as you feel the software is / or should be. That may be true, but I don't think that is necessarily will be in a general case. Adding that abstraction may add complexity to the hardware design, and that will have to be paid for either in transistors or speed. There is always a trade-off.

Maybe there is a very good separation in hardware in between the AGP card and the system bus which will prevent a problem no matter what crap the AGP cards starts to spew... but I haven't heard of it. I will be perfectly honest, now days I mostly deal with DSP hardware, so it is perfectly possible that I just missed out on that. The important thing isn't whether there is or not, it is whether or not you instinctively make that assumption or verify.

But in any case that is what I meant by my comment about the CompSci vs CompEng or EE view. There are just as many engineering trade-offs taken in hardware as there are in software.

If the monitor, mouse, keyboard, speakers, Ethernet, .... go the system itself should not crash.

Sure, that's why I pointed out driver problems can be mitigated to a degree, certainly a bad mouse vs a bad video card hardware or driver are two very different.

MS needed to do with another layer is provide a solid API

I think this overlooks a lot of the vendor specific portions of the drivers, and assumes MS would have a lot more information on the video card than is realistic.

-paridel