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.
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.
In the early-ish days of Linux (2001 or so), I had a friend who wanted to use certain scanners and modems and things that didn't have any support. I used to always tell him 'just write a driver for it', not realizing how complicated it would be.
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.
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.
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.
Warp on, I didn't have video driver issues. I had a personal machine as well as a work machine (actually ran win32 and win16 builds onthe work machine) that never really had an issue.
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
>"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!"
5MB of Asm sounds like they really didn't know what they were doing, given that MenuetOS/KolibriOS is also 100% Asm and contains quite a lot more than a display driver, more like an entire OS, in a fraction of that size.
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.
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.
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.
In the early-ish days of Linux (2001 or so), I had a friend who wanted to use certain scanners and modems and things that didn't have any support. I used to always tell him 'just write a driver for it', not realizing how complicated it would be.
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.
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.
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.
Warp on, I didn't have video driver issues. I had a personal machine as well as a work machine (actually ran win32 and win16 builds onthe work machine) that never really had an issue.
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
>"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!"
5MB of Asm sounds like they really didn't know what they were doing, given that MenuetOS/KolibriOS is also 100% Asm and contains quite a lot more than a display driver, more like an entire OS, in a fraction of that size.
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.