Posts | DOSContainer

Contribution guidelines published

📅 2025-06-07 · ✍️ Bas v.d. Wiel · 🏷 announcement

So I started my new job at a large ISP this week. While irrelevant for the project itself, this does take quite a massive bite out of the time I have available to spend on DOSContainer. That’s why I finished up the repository service and contribution guidelines and am inviting others to chip in. While it’s annoying that work gets in the way of my hobbies, it’s not money that’s keeping me from DOSContainer so I’m not looking for donations. What I do need is code. So if you’re halfway decent at Rust, please have a look and help where you can!

Code repository moved

📅 2025-06-01 · ✍️ Bas v.d. Wiel · 🏷 announcement

Short service announcement for today: the code repository for DOSContainer moved yet again. Since I’m not seeing any sort of uptake regarding collaboration and I’m still the only developer, I’m choosing to self-host my code. Can I do better than GitHub? Well, yes. I don’t want my code to be beholden to some cloud-behemoth. The code itself is as public as ever at its new address and you can even keep using your GitHub credentials to contribute.

We have lift-off!

📅 2025-05-27 · ✍️ Bas v.d. Wiel · 🏷 announcement

DOSContainer generates bootable PC-DOS 1.00 disk images! So technically that means we have lift-off, and I’d be lying if I said I wasn’t happy about this milestone. However, and there’s always a “but”, we’re not there yet. In fact, I’ve been at this very spot before and even further along. I had bootable PC-DOS running a BASIC game from a generated image but I still started over. Why? Architecture! The code would absolutely not scale at all, and I’m running into similar questions again this time around. Allow me to elaborate, because things are not as dire as they sound.

Defining compatibility as data

📅 2025-05-24 · ✍️ Bas v.d. Wiel · 🏷 design

One major issue for DOSContainer is to figure out the optimum between what you have on your desk and what the software you’re building actually supports. In a previous version of the codebase I had started a convoluted decision tree of if/then/else/unless logic. That stopped scaling after two versions of DOS, while I intend to support dozens so something had to give. The alternative? Modeling compatibility as data!

Currently DOSContainer is gearing up to release 1.00 which will only support PC-DOS 1.00 on the surface. Inside the codebase, however, I’m already working with versions 1.00, 1.10 and 2.00 to prove the design. These three versions already have a few quirks between them and the hardware they run on that will exclude certain combinations. Modeling how to handle this is crucial to the future of DOSContainer.