I was always frustrated when we'd try to install Linux on some cheap PC from Best Buy that had a newer integrated video card that wouldn't run X at anything other than 640x480 with 16 colors, if even that.
I knew a little VGA programming from my DOS days but an actual video driver was a mystery. It was probably the guys who used to work on stuff like these OS/2 video drivers who ended up writing those things for Linux.
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.
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.
At one point, after a very prolonged struggle, I managed to get 800x600 resolution working (standard was 640x480). The gigantic sense of achievement I felt at that moment hasn't been repeated in 30 years hence.
From the article, it does look like things got better around then. I do recall running 2.1 as well but was more of a try it out thing. I actually miss OS/2
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!"
Then again, I have seen the Windows example display driver code from roughly the same era, and it's also insanely bloated. I've written a VESA + (Intel) GPU accelerated driver for Windows, and it was only a few KB of Asm.
Hey, if your VESA GPU accelerated driver for Windows is open-source, I'd love to take a look at it.
No worries if it's not... But if it is open source, then I'd love to take a look!
I'm also a big fan of MenuetOS/KolibriOS (and any other small OS that can fit on a 1.44MB floppy! Remember the original Damn Small Linux (DSL) anyone?)
Newer software needs more than this.
