Very old project: driverinf

Thu, Feb 29, 2024 ❝A very old project, used extensively during my teens for retrieving installed drivers (files) on Windows-systems.❞

Contents

I recently found one of the first (useful) programming projects that I wrote. I worked at a small computer-shop in town for a few years as part-time job next to my studies. The one constant was asking .. almost begging .. for people to search for their driver-CDs. They would bring their computers, ask us to solve their problems and if a reinstallation was necessary, then we would need to have a very specific driver for the device, actually even more specifically the exact device identifiers, of that piece of hardware.

This was in a time when the internet was far from prevalent, connections were often slow, device manufacturers would have many iterations and fewer drivers on-line, and only the CDs were (most of the time) guaranteed to contain the driver for at least that one device. These CDs would magically disappear when needed most. Furthermore, early drivers would quite often be problematic in one way or another, so one would need to be careful what driver to choose for some hardware. And if you would need to provide support on location, you often did not have the necessary resources at hand and about 50% chance to find it on the internet in any remotely reasonable time.

So I decided to figure out how the driver-INFs were constructed, the control-flow decisions that were taken from section to section, such as order, precedence, overrides, and write a small tool that could find the files by retracing the steps taken to perform the installation. Starting out by matching device identifiers in the INF-files with hardware that was present, then retrace steps from there copying files where necessary.

This obviously resulted in incomplete driver-packages, but then that wasn’t often an issue. It does not matter that you cannot install every device out of a family of devices. Only that you can manage to collect all files necessary for that one device you need to make work, that you could assume had worked on this operating system installation. And so a 16-bit DOS/32-bit command-line tool was born to perform the look-ups and extract the necessary files.

The tool was written in C, with something like 95% pointer manipulation through a buffer that contained the loaded driver INF-file contents. I haven’t checked, but I have no doubt that memory-safety was not optimal. However, as a short-running, manually executed tool, there is little risk. The tool helped us with recovering drivers that would otherwise taken hours (literally) to search for, and a lot of hoping that one would find the right driver, the right version and with the least amount of bugs. It did not solve everything, but it saved us many many hours of work.

The tool uses little short-cuts like calling DOS-commands for copying files. That was the fastest, most straight-forward way to make it work. Looking at it now, there are plenty of things that could be done better .. but what is “better” really? It did its job fine, and it worked even if the operating system couldn’t even boot; access to the file-system was all it needed. (I kind-of enjoy how crude and effective it.)

Sources at gitlab.com/cobratbq/driverinf.

You should probably sit down before opening up the source-files. inf2 contains all the relevant sources. (It’s all pointer-manipulation to jump through the buffer containing the whole driver-INF file. 16-bit unicode was supported by dropping the second byte, determined by the BOM.) inf3 was a start at refactoring that didn’t get far when priorities changed.