In contrast, I worked on a driver about 4 years earlier and the amount of labour was utterly crazy. A Windows 3.1, 95, or OS/2 system needed, at a minimum, these drivers:
- The base BIOS necessary for booting
- A VESA implementation in the BIOS (optional, but would mean the below code could be copy-and-pasted far more easily from a generic SVGA driver)
- (OS/2 only) a "BVH" driver which would set full screen modes, although the default VGA/SVGA was usually enough. Windows 3.1 and 95 would just use the BIOS.
- A 32-bit "virtual" device driver to handle DOS sessions which want to talk to the display adapter, basically making a working VM environment for that specific hardware. The codebase for this was different on Windows 3.x, Windows 95, and OS/2, even though the actual function would be nearly identical. (A Windows 3.x virtual driver could in theory be used on Windows 95, but these usually had odd stability problems.)
- A 16-bit Windows 3.x display driver (could be re-used for OS/2)
- Another 16-bit Windows 3.x display driver for sharing the display between a Windows and the OS/2 desktop, known as "seamless" - these were notoriously difficult to write
- A 32-bit Windows 95 and/or 32-bit OS/2 display driver for the main session... except in the OS/2 2.0 era, the OS/2 display driver would have to be 16-bit, even though the rest of the OS was 32-bit. Windows 95 could use the 16-bit display driver, albeit at reduced performance.
Another frustrating quirk was that the display driver (for both Win 3.1, 95, and OS/2 before version 4.0) would require an implementation of pretty much all of the graphics primitives, even ones that just rendered to a buffer in memory. Most people would write their display driver by taking Microsoft's Video 7 sample code and re-use the primitives in there.
a basic driver did almost nothing except provide a dumb framebuffer and indirectly let SOFTDRAW do all the work.
An accelerated driver could hook out certain operations that hardware could do much faster than software, such as screen-to-screen copies, hardware cursors, or bit blits with color conversion. Anything the driver didn’t explicitly ask to handle was done by SOFTDRAW."
[...]
"To give a sense of the complexity of the drivers, the 16-bit VGA driver was over 5 MB of assembler code, heavily macro-ized. The 32-bit VGA driver was over 6 MB of assembler, again using lots of macros. The 32-bit accelerated driver was about 1.5 MB of assembler and 3.6 MB of C code.
In contrast, the accelerated S3 GRADD driver was a little over 200 KB of C code, and the generic unaccelerated GRADD driver was only 30 KB of C code!"
dfe•4d ago
I think the unfortunate answer is that two if not three drivers are going to have to be written to support the differing generations. GRADD to satisfy Warp 4 (and 3 w/ FixPack) is probably the easiest and most useful.
The way I see it, if I want to have some Workplace Shell nostalgia, but with modern amenities, I'm ok being limited to at least Warp 3 + FixPack. OS/2 2.1 and 3 are hardly different. A few colors changed for the better, and you gain the application's icon instead of the circle. Warp 3 still has the floating launcher thing introduced in 2.
Having to track down all the FixPacks to make the system work on hardware even slightly newer than what was available when that OS/2 version first shipped is part of the nostalgia. Put a 28.8k modem simulator in there, and we can really party like it's 1994.
Along those lines, if I really want OS/2 version 2 nostalgia, how badly do I want modern amenities like high-res, high-depth graphics? Whereas for OS/2 version 3 or 4 nostalgia, I would like to experience what those might have been like on newer hardware.