A Bit of History

This page is part of a larger series: Validating JSON against a 1980s Database.

Next: Parsing DBF

On this page:

Beginnings

In 2019, I started competing in rodeos. I joined the International Gay Rodeo Association (IGRA), started steer riding and roping, met a ton of great people, and was hooked.

But IGRA is an amateur rodeo association. As evidence of that, here’s the data management system they’re currently using:

They’ve been using this DOS-based data system since 1986. While I’m sure this was a major upgrade relative the preceding 10 years, it’s not an ideal state to be in today.

Notably, I’m running the program using FreeDOS and a virtual machine. This is a 16-bit DOS application, meaning the compiled binary is made up of 16-bit opcodes and expects to run in a DOS environment. I have a 64-bit CPU and am running Linux, so the fact I need a VM likely comes as no surprise.

How has the rodeo staff been supporting it over the years? Prior to Windows 3.1, all versions of Windows were 16-bit builds and ran atop MS-DOS, so if they were using Windows at that time, it would have been natively supported.

The first 32-bit build of Windows was Windows 3.1 NT, released in 1993. The 32-bit x86 architecture had the ability to run 16-bit opcodes, so to support those legacy 16-bit DOS applications, Microsoft included NTVDM, a compatibility layer that emulated MS-DOS and the Win16 API, then just executed the relevant 16-bit opcodes on the underlying hardware.

The x86_64 architecture supports 16-bit opcodes, too, but there’s a catch: you can choose between long mode, which uses 64-bit opcodes with 32-bit compatibility, and legacy mode, which uses 32-bit opcodes with 16-bit compatibility. Though you can switch between them, it requires resetting the CPU, and thus restarting the computer. That means running a 16-bit application from long mode requires full hardware emulation, not just a compatible OS. Thus, Microsoft dropped NTVDM in 64-bit builds, and as of Windows 11, no longer supports it at all.

So, the short of it: the rodeo staff has been maintaining systems with 32-bit Windows builds just to run this application.

Into the Future

There have been various other systems IGRA has used over the years. Not long after I joined, they paid a commercial service provider to handle this, but that small company was bought out, and the buyer dropped IGRA as a customer. From what I’ve been told, they’ve been rejected by a number of commercial providers who do not want to provide their services for an LGBTQ+ organization.

At one point in time, they had an online system developed and maintained by an IGRA member, but when that person left the organization, they took their code with them.

In 2023, IGRA hired a software company to develop a new rodeo management system, to be owned in full by IGRA, with the rights to host and modify it as they see fit. The company was tasked with first delivering an online registration system, where people could sign up for a rodeo and pay their entry fees; later, they will extend this to support user accounts, to track results, and in general to replace the functions of the current system.

In the meantime, staff will continue using the old system, which means at some point in this process, they’ll need to take registration output from the new system and input it into the legacy one. Historically, this has been a pain point, as it involved manually typing each entry into the old terminal UI, easily leading to typos. Worse, if registrants made a mistake when entering their details, or if their details had changed since the last time they competed, it was next to impossible to notice.

So my plan was this:

1. Get the application running for myself using a VM.
2. Help the rodeo staff do the same, eliminating their first pain point (maintaining legacy hardware).
3. Determine how the old system maintains its records and find a way to automate the validation process.
4. If reasonable, look into automating updates to the existing system. Ideally it’ll be replaced fast enough that doing so won’t be needed, but noting the history above, I wanted to focus on helping them get the most value out of what they have now.

Getting Started

Going into this, I wasn’t really sure exactly what they did have now. I knew the existing system maintained membership records, tracked registrations, and generated reports during the rodeo with people’s standings and winnings. But I didn’t know how it did these things, so I reckoned the first I should do is get my hands on a copy and run it myself.

Since I knew up-front it was a DOS application, I set out looking for a way to run DOS in a VM. Lucky for me, the good people at the FreeDOS Project have been working on an MS-DOS replacement since 1994 (hey – remember that 1993 release date of NT?), and they even have instructions for installing in a VM.

For the most part, I followed the instructions on their wiki, though after working with it for a bit, with some modifications directly related to running this program.

If you’re looking to do something similar, here are the specifics:

1. Install VirtualBox.
2. Download the FreeDOS FullUSB image and extract it somewhere convenient.
3. Create the VM, selecting the image downloaded above. For resources, I chose 1 CPU, 64MB memory, and 4GB storage; surprisingly, 500MB was too small.
4. Set the Processor Execution Cap to 40% or something similarly low. I needed to disable the FreeDOS built-in power management, as it makes this particular application crawl, but without it, the VM will keep the CPU at 100%. This lets the host handle it.
5. I set up a virtual serial port so I could “print” later on. In my case, I just enabled Port 1 as COM1 and set it to “Raw File” mode to write its content to a regular file. Then I could just open it up and see the reports it sent to the printer.
6. After first boot and installing FreeDOS, I edited C:\FDAUTO.BAT to comment out the LH FDAPM APMDOS (line 59 in my version); this disables the power management I mentioned earlier. I also added MODE LPT1:=COM1, directing printing to COM1. Fun fact: FreeDOS includes vim, so these were easy edits. You can see a screenshot of the edits below.

After that, I turned off the machine and mounted the disk locally so I could copy over the programs I got from the rodeo staff. I considered setting things up for FTP transfers, but booting was fast enough (and transfers rare enough) that I just mounted the virtual disk and copied that way:

mkdir -p /mnt/freedos
mount -o loop,offset=32256 ./FreeDOS/FreeDOS_1.vhd /mnt/freedos

Now it was time to poke around and find out!