It is instructive to compare the OS/2 and 16-bit Windows display driver model with other operating systems. Why NT and NeXTSTEP? NT because it was Microsoft’s third take on a (mostly) PC operating system, and NeXTSTEP because it was an OS with a very different heritage, ported to the PC relatively late in its life, and eventually spawning Mac OS X.
The general NT driver model is unusually complex and over-engineered. However, NT display drivers use a significantly different and much simpler model. Drivers are split into two separate components, a video miniport and the display driver proper. The video miniport always runs in kernel context, while the display driver is a DLL which runs in user or kernel context, depending on the NT version.
The miniport is primarily responsible for hardware initialization and setting modes. If applicable, it also manages the hardware cursor and DAC palettes. The display driver implements accelerated drawing operations and corresponds to the old GDI drivers in its responsibilities, but not in implementation. Both the miniport and the display driver are typically written in C, and assembly code is almost unheard of.
An important feature of the NT driver model is that the display driver is optional. NT comes with FRAMEBUF.DLL, a generic unaccelerated driver. It is thus possible to implement an unaccelerated high-resolution driver with only a modest effort, especially compared to the awful old all-assembly Windows 3.x drivers.
In version 3.1, NeXTSTEP introduced DriverKit, a brand new driver model with drivers written in Objective-C. NeXTSTEP 3.1 was the first version which supported the PC; it was released in 1993 and was thus a contemporary of Windows NT 3.1.
Drivers written to the DriverKit model resembled NT miniports in their complexity (or rather simplicity), but as mentioned above, were implemented in Objective-C instead of plain C. NeXTSTEP offered by far the most comfortable development environment, with driver development fully supported by the Project Builder IDE, including source level debugging.
The NeXTSTEP display drivers were a lot like NT video miniports in that they were responsible for hardware initialization and mode setting. Interestingly, there was no provision for accelerated drawing; possibly because Display PostScript did not easily lend itself to acceleration by hardware geared towards Windows.
The alien-ness of NeXTSTEP was evident from the graphics modes it supported. 16-bit Windows, OS/2, and NT all supported the common 4/8/15/16/24/32bpp modes available in the EGA, VGA, and SVGA graphics cards. NeXTSTEP had no support for 16-color modes at all, and for standard VGA it supported only 4 levels of gray (2bpp). 8bpp modes with 256 levels of gray were also supported. NeXTSTEP also had no direct support for 15/16bpp modes commonly supported by PC hardware—the OS supported only 4,096 color modes (12bpp) which were remapped to 15/16bpp.
Although NT and NeXTSTEP were developed by different companies and had completely different lineage, their display drivers were ironically almost as similar as the display drivers for OS/2 and 16-bit Windows.
Interesting about NeXTSTEP having 12-bit colour mode, and I wonder whether the Amiga’s Hold-And-Modify 12-bit colour modes was in any way related? Personally, I doubt it, but it’s interesting to speculate 🙂
I don’t believe it’s directly related. 12-bit direct color is just a somewhat natural color mode, with reasonably fine-grained color but without requiring too much framebuffer memory. And by “somewhat natural” I mean that 12-bit data maps reasonably well to byte-oriented storage.
The NeXTstation Color (circa 1990) had 12-bit direct color hardware, hence the support for those modes in NeXTstep.