Why Change the Graphics Architecture?

In all previous Windows NT releases, GDI (and USER) were the Graphics Subsystem, which was a user-mode process like every other application. The kernel gave this process special security privileges to perform various operations that normal processes could not perform, such as communicating directly with the hardware. With this architecture, every GDI call was basically an inter-process call. In order to execute a graphics operation requested by an application, such as a bit-block transfer, the system marshalled the operation in the context of the calling process and sent it to the Graphics Subsystem process using an inter-process communication mechanism. The Graphics Subsystem unmarshalled it and performed the operation. This was a complicated and often slow task.

The pre-4.0 architecture did have its advantages. GDI (and USER) ran in a separate process (address space), protected from all other applications and processes. Because it was in user mode, GDI interacted with the kernel using well defined user-mode APIs, and was guaranteed to not affect the kernel.

In order to increase performance, reduce memory usage, and decrease the complexity of the code in Windows NT 4.0, GDI (and USER) have been moved into the kernel address space. This means that GDI (and USER) are now in the same privileged kernel-mode address space as the Windows NT executive (the kernel, memory manager, and I/O system), the file system, and all other drivers.

The advantages of the new architecture include eliminating LPC calls from applications to the Graphics Subsystem, reducing the number of threads in the system, and the ability to access data directly from the address space of the calling process. The new architecture also means that GDI and graphics drivers can overwrite data structures belonging to the file system, disk driver, or memory manager, possibly causing data corruption. Because of this, the quality of graphics drivers becomes even more critical to the overall reliability of the system.