Will Kling
Milford, NH
"4.0 Isn't for Everyone" was informative, but you make too mu
ch commotion about the kernel-mode issue. Although moving the graphical device interface (GDI) into the NT Executive gives it the potential to crash the OS, this does not seem likely. The current GDI/Window Manager subsystem is highly stable and rarely faults. The move to kernel mode only simplifies its design, making it easier to debug. Since version 3.1, all of NT's other low-level device drivers (disk device drivers, SCSI controller drivers, etc.) have operated within the Executive with a high degree of reliability. There is no reason to suggest that the graphics subsystem need be any different. If, in NT 3.51, CSRSS.EXE faults for any reason, the whole OS shuts down, as it is considered a critical process. What is the practical difference if the graphics subsystem crashes and the OS subsequently shuts down, or if the graphics subsystem crashes and takes the OS with it?
Rene Gollent
100642.1147@compuserve.com
The GDI issue involves the potential for OS failu
re due to reengineering of NT. The claim that the NT 3.5 kernel is inherently stable does not automatically carry forward to the next instance of the OS, considering the changes that Microsoft has made. At the beta stage (Build 1234), it was unclear how moving GDI to Ring 0 might affect stability in the final release -- we were not able to crash the beta system. However, as with other operating systems that exploit Ring 0, the trade-off is stability for performance. Microsoft is selling NT as an OS that is more stable than Windows 95 and as an OS reborn for the client. The changes made to NT to sell it as a high-performance client could jeopardize its traditional use as a server OS. That's why I made an issue of it. As I write, Windows NT 4.0 is just leaving beta. We'll know who's right about the GDI issue very soon. -- David Linthicum
"NT and the Net" (July) provides a good overview of Microsoft's strategies surrounding its Internet Information Server (IIS). The discussion of the benefits of the Int
ernet Server API (ISAPI), however, failed to give credit where credit is due. The interface now known as ISAPI was first developed as a proprietary interface by Process Software (
http://www.process.com