Not surprisingly, the display driver model of Windows 1.x/2.x/3.x and OS/2 1.x/2.x was quite similar. This was in sharp contrast to the drivers for just about every other device; while disks or network adapters already had existing drivers in DOS, the drivers for Windows GDI had to be written from scratch. When the Presentation Manager was created, Microsoft recycled much of the existing Windows driver model.
Both in OS/2 and Windows, displays and printers both used the same basic driver model. The driver model was designed with a C-callable interface, but traditionally only printer drivers were written in C, while display drivers were written in assembler.
Viewed from a modern perspective, the Windows and OS/2 driver model was byzantine, overly complex, with drivers being difficult to write and nearly impossible to fully debug. The drivers could implement nearly the entire graphics engine, and even the most basic driver had to implement significant functionality. This included rendering memory bitmaps (device contexts), which seems bizarre in hindsight.
The design of the driver model assumed that future accelerated hardware might have very varied capabilities and giving the drivers the option to hook out so much of the graphics engine would take full advantage of the acceleration. In reality, hardware with support for arcs, circles, or polygon fills was extremely rare to nonexistent, and all modern GUI accelerators derived from the 8154/A and XGA (which included S3, ATI, and just about every other accelerated graphics card) had relatively modest capabilities—bit blits, line and rectangle drawing, and perhaps bitmapped text rendering.
To make matters worse, the drivers were more or less fixed to a single graphics mode, and the mode switching services were not separated from drawing. That made some sense in DOS, where the BIOS was the display “driver”, but not in OS/2. In OS/2, the VIO subsystem already included mode switching support independent of the BIOS. Instead of leveraging this support, the Presentation Manager drivers contained their own mode setting routines.
The similarity between OS/2 and Windows drivers was more than superficial. The drivers shared significant chunks of code. Looking at the EGA/VGA drivers in the OS/2 1.1 DDK, one finds that most of the source files were originally written for Windows, some as far back as 1983-1984. The primary author was Walt Moore, with many contributions from Bob Grudem, Wes Rupel, and others. The same authors and much of the same code appear in the Windows 3.1 DDK. The ROP (raster operation) mechanics are the same, and on the whole the drivers are far more similar than different.
On the Windows side, the driver model didn’t change much between Windows 1.x, 2.x, and 3.x. New capabilities were added, especially for dealing with higher color depths, but the basic architecture was unchanged. With Windows 95, the Windows 3.x style drivers were still supported, but a new display minidriver based model was preferred. In the minidriver model, just about all rendering could be done by the DIB engine. The overall structure of a minidriver very closely followed the old model, but the driver could now fall back on the DIB engine for most operations.
On the OS/2 side, the original display model remained the only choice up until OS/2 Warp. For the PowerPC version of OS/2, IBM developed a new display driver model called GRADD. This model was brought back to the Intel platform in OS/2 Warp 4 (although it was almost completely unusable in the initial release) and in later OS/2 Warp FixPacks. The GRADD model was very different from the old Presentation Manager drivers, much cleaner and simpler. Similar to the Windows 95 minidriver, a GRADD driver could fall back on the graphics engine for all drawing operations. That made the unaccelerated yet very useful VESA GRADD possible.
The evolution from complex to simple was unusual, but entirely logical.