Hacker News new | ask | show | jobs
by Mountain_Skies 237 days ago
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.
2 comments

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.