DOSContainer update Q2 2025

DOSContainer is still progressing, even though I skimped on the updates. Let’s rectify that. There’s a lot that happened over the past months, but unfortunately there still isn’t a stable release to be made. The main effort went into reimagining the configuration file format and structure behind it, and I’m hoping this’ll be the last such major overhaul because it’s no fun writing code that only does boring stuff like config file parsing. I really want to get into the nitty gritty bits of ancient DOS and making sure that gets reproduced as faithfully as possible. Let’s go over the changes though.

Cargo workspace

Initially I had started by writing a whole pile of separate crates that were hosted in a Gitea-based cargo registry. It worked, but it was cumbersome. Now the whole codebase lives in a cargo workspace that’s managed through a single Git repository on Github. This saves a lot of churn in crate version numbers.

Design changes

Configuration file format: TOML

Originally I envisioned using YAML as a configuration format, but that’s not something I really want to inflict on people who don’t work in DevOps every day. I guess that was just some sort of company blindness on my part: not everyone dreams in YAML.

So from here on out, the configuration format will be TOML. It does away with the indentation requirements of YAML and is simpler to manage overall.

Configuration split

DOSContainer is aimed at collection builders primarily. The point being to provide an easy way to build huge collections tailored to the hardware specifications of a particular machine. In order to do that, we distinguish two types of configuration instead of the initial one (the Manifest):

The HardwareSpec is mostly finalized now:

cpu = "8088"
ram = "512k"

[[audio]]
device = "bleeper"

[[audio]]
device = "adlib"

The above defines a generic IBM XT-like computer with an AdLib synthesizer card added to it.

This is just an example of what the final format may look like. Things certainly are not set in stone yet. You’ll find the current docs to the HardwareSpec format in the docs for the hwspec crate inside the project repo.

Fixed the build

So yeah, the build now completes without errors but that’s not to say anything useful comes out yet. I’m still wiring up the new configuration file format changes and other logic, fixing the occasional core bug as I go along and squashing all manner of linting and other errors in a mostly chaotic way.

The initial promise stands: as soon as this version of the codebase is able to take configuration as planned and outputs IBM PC-DOS 1.00 and 1.10 valid disk, I’m releasing the initial version and opening the project up for collaboration. That’ll also be the point when the development process becomes more formal and structured.