Roadmap to v3.00

📅 2025-08-13  · ✍️ Bas v.d. Wiel  ·  🏷 announcement

The roadmap to DOSContainer v3.00 is an ambitious one for a project that’s only maintained by a single person in part-time. A number of features is on the cooker right now, which will take quite a lot of time before completion. Here they are in some more detail.

Support PC-DOS 3.00

PC-DOS 3.00 is just another version of the IBM-branch of DOS. Supporting that, in and of itself, is not that much of a problem. It’s a matter of adding boot sector binaries, system files, and to make branches in the code where data structures get serialized into OS-specific on-disk bytes. The most work goes into figuring out whether or not those on-disk bytes are different at all, for which IBM’s docs are not the most reliable source.

Support FAT16

Supporting FAT16 is a different kettle of fish. It’s the first time DOSContainer grows a new filesystem that’s mostly separate from FAT12. This required a massive rewrite of the filesystem crate, which I renamed to ‘fat’ in the process. As I went along with this, the operatingsystem crate also got a thorough refresh. The filesystem itself is not that complicated. It’s mainly the allocation table itself that changed, and the algorithm for that is now in place. Testing all these permutations and the selection logic that allows DOSContainer to choose the right filesystem for an OS-version versus a disk type is the most work.

Add a “bootflop” command

DOSContainer is currently equipped, in its core, to spit out simple empty boot disks without any application or game payloads. That could be super useful to end-users of the project, but also as a testing tool for the project itself. The CLI will grow a “bootflop” subcommand to quickly and easily spit out bootable disks with no further configuration.

Support AT-era hard disks and custom disk sizes

As we move into the territory where “the PC” got support from oodles of third-party equipment vendors, the current limited list of XT-sanctioned hard disks is not enough anymore. DOSContainer needs a completely generalized method of defining hard disks, and to support their creation in a way that’s still spot-on historically accurate as to how DOS would treat those disks. The effort in this goes into figuring out how to calculate a BIOS Parameter Block from nothing but a CHS geometry and a sector size, and testing that against how original DOS versions used to deal with this. Once that’s done, the ergonomics of exposing this feature through the TOML file format becomes an issue.

Support local payload storage and payload caching

Manifest files pull in ZIP files for their payloads across the network now, either over HTTP(S) or FTP. This isn’t always optimal. DOSContainer should be able to handle locally stored payloads as well as cached payloads, reducing the number of trips to the network for manifest downloads. Having ‘file://’ URI support in the manifest file format is one thing. Caching previously fetched ZIP’s is another. I’m pondering whether HwSpec files should be expanded in scope to be a more generic DOSContainer local configuration format that includes more than just settings for the emulated hardware because I’m hesitant to include yet another configuration file, which also won’t be very cross-platform.

Sweep up older DOS versions and support them

As I pushed for DOS 3.00 and FAT16, there’s a growing backlog of older DOS versions that aren’t supported yet. They should be fairly easy to add. Versions like MS-DOS 1.25 and PC-DOS 2.10 come to mind, but there’s also a plethora of other OEM-versions of DOS. I’d say that as long as 86Box emulates the target machine and I have a known-good disk image of the DOS version in question, I’m up for supporting it. This includes platforms like the Tandy 1000 and PCJr, which also brings with it some interesting graphics and sound hardware that I’ll need switches for in the compatibility matcher.

As you can see, there’s plenty of ambition. I’m going at these tasks one at a time, improving the product slowly as I go along. Apart from this roadmap I’m also eyeing the option of introducing a DOSContainer GUI app in the near future, but since I’m by no means a frontend expert that’s something for the longer haul. First things first, and that’s to get release v3.00 out the door.