I had the most interesting peek into my past recently, when the Rootstown Water Company asked me to look at a small issue with their billing software. I originally wrote it back in 1986 (19.5 years ago!). They're still using it, unaltered except for one bill-formatting routine which needed to be updated for a new printer some years back.

It's really pretty much in the state I left it, except that the machine is running Windows 3.11 now (it had been running only DOS 2.11 when I was there — I know the version number because they still have the original “IBM DOS 2.11” manual). Yes, they still boot Windows 3.11 every day (with win at the end of autoexec.bat — remember those days?)

My code was written in C and compiled with the Mark Williams C compiler version 3.0.6 (has a copyright date of 1982-1985). You really got a lot with this compiler. It was modern enough at the time to be on 5.25" floppies instead of 8" floppies. Everything came on two 5.25" floppies, including all system header files, the pre-processor, compiler, assembler, linker, all libraries, a debugger, some Unix utilities (make, egrep, banner, etc.), and even an editor — MicroEMACS. In fact, they even had enough room (on the two 5.25" floppies, mind you) left over for the source to MicroEMACS. My, how times have changed.

The problem that had cropped up in the software was reduced functionality in a non-critical reporting area due to some integer overflow. They shouldn't have run into the problem in the first place, but had neglected to run some maintenance programs for a few years. A log file grew unchecked, and its size eventually eclipsed the 16 bits the compiler alloted to an INT. (Had I had the foresight to make it an UNSIGNED INT, the problem would not have shown itself in my lifetime, so I accept some of the blame 🙂 )

The fix — making one variable UNSIGNED — would have been easy except that for whatever reason, the compiler no longer worked properly. They had moved everything to new hardware from backups after a disk crash some years back (to the 333MHz Celeron 64-meg of memory they're using now), and perhaps that has something to do with it. The build process would end with:

LD: \bin\libc.olb(printf.o): bad reloc type 41

Although the compiler's two-volume hardcover manuals have 20 pages covering build errors, I could find nothing about “bad reloc” of any type, much less type 41.

They still had the full backup of the C: drive that I made on 9/6/86, on nine floppies, and in theory I could have pulled the compiler from that, but either the 19-year-old floppies no longer worked, or the floppy drive didn't work. After inserting a floppy into the drive, seeing that the drive reported an error, and pulling it back out, it was hard not to notice the thick layer of dust the process had imparted onto the disk. Even after putting in many floppies, they still came out with somewhat of a layer of dust, making me wonder if the “dust” is really disk material flaking off.

So, I decided to move to a more modern OS where I could use modern tools to rebuild things. They had some Win2K computers for other reasons, so that was good enough. I installed the wonderful DJGPP system (gcc, gmake, and lots of GNU tools like bash and emacs) and recompiled there. Considering that my source was written in pre-ANSI C, and considering that I had written it when I had no considerable programming experience, well, there were a lot of little things to clean up. I used many of gcc's command-line options to turn on a lot of warnings (including -Wall), and so spent a few hours going through everything updating to ANSI-C and cleaning up unused variables and dangerous typecasts.

In doing the heavy linting, a few bugs turned up and were fixed, although I seriously hesitated to change anything about how things worked, since they'd been using it as is for 19 years. My brother suggested PC Lint would be more insightful than gcc, as he says it's unparalleled in its ability to point out “issues”, but the aforementioned desire not to change much — combined with my limited time and energy — caused me to set this idea aside.

It's always a little scary to look at old code, but this is by far the oldest code that I know to still exist. (I wrote some very nifty stuff, in FORTH no less, to control a flow-cytometer during the early 80s when I worked at a medical school, but I don't think it's still being used.) It certainly felt odd to look at it, since I knew I wrote it all (the one formatting routine aside), yet I remembered nothing about it.

In once sense I was pretty happy with the code. Even though it was written in 1986 before “Y2K” was on anyone's mind (or, at least not yet on my mind), I still engineered it to work fine through the end of 2079. The DOS on the system now (likely the version that came with Windows 3.11) isn't so graceful about dates: files I edit today show up with the date “7-20-105”.

In some other senses, I shake my head about some of my programming decisions. The way I grouped things into files was very dorky, particularly WRT header files. Rather than have FOO.C's declarations in FOO.H, I tended to replicate the needed declarations in each file that needed it. And my use of global/extern variables was... unsound.

People tell me “hey, but it works”, and the current issue aside, it has been working quite well for more than 19 years, but “it works” has always been only the most basic starting point to measure success, not the ending point. I would certainly do it quite differently now, but then, I'd charge a lot more than $5/hr to do it!