[HN Gopher] The OS/2 Display Driver Zoo
___________________________________________________________________
The OS/2 Display Driver Zoo
Author : kencausey
Score : 48 points
Date : 2025-10-14 18:35 UTC (9 days ago)
(HTM) web link (www.os2museum.com)
(TXT) w3m dump (www.os2museum.com)
| dfe wrote:
| This was an especially interesting read, having lived through
| using these versions of OS/2 on varying hardware.
|
| 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.
| Mountain_Skies wrote:
| Device drivers are the sanitary sewage systems of modern
| computing. They're a stinky mess to design, build, and maintain,
| but modern civilization/computing would be near collapse without
| them. They're also something the average person doesn't want to
| ever have to think about directly. Those who ensure it all works
| correctly aren't given enough credit for their essential role.
| trollbridge wrote:
| They're way, way easier than they used to be. In the example
| from that article, by the time we got GENGRADD, writing a
| driver was easy enough that I did it (I wanted to make a
| display driver that made everything green since at the time I
| heard everything-green is easier on the eyes, and it was a few
| hours of work to cook up a driver that did that).
|
| 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.
| peter_d_sherman wrote:
| >"GRADD [display] drivers worked the other way around and
|
| _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!_ "
| starik36 wrote:
| I've also lived through that era and used OS/2 extensively.
| Display drivers were always the weak point of the system.
|
| 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.
___________________________________________________________________
(page generated 2025-10-23 23:00 UTC)