Research toolkit that automates the process to derive real-world behavior from DOS disk utilities like FDISK and FORMAT. DOSContainer doesn't rely on folkore, it relies on hard fact.
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-08-15 19:38:05 +02:00
.roo Initial commit 2026-08-15 11:13:00 +02:00
bootdisks Add a whole bunch of boot disks 2026-08-15 19:38:05 +02:00
original media DR-DOS 6.0 and Novell DR DOS 6.0 2026-08-15 19:22:38 +02:00
plans Capture third PC DOS 3.00 FDISK evidence screen 2026-08-15 16:35:41 +02:00
src This commit was made mid-process because I ran out of Codex credits for the week. 2026-08-15 17:55:10 +02:00
tests This commit was made mid-process because I ran out of Codex credits for the week. 2026-08-15 17:55:10 +02:00
.gitignore Initial commit 2026-08-15 11:13:00 +02:00
AGENTS.md This commit was made mid-process because I ran out of Codex credits for the week. 2026-08-15 17:55:10 +02:00
Cargo.lock Add guest-console readiness and profile-driven FDISK dialogue 2026-08-15 12:00:56 +02:00
Cargo.toml Add durable attempt lifecycle persistence 2026-08-15 14:55:01 +02:00
README.md Initial commit 2026-08-15 11:13:00 +02:00

Disk research

This is a Rust-based tool that brute-forces old DOS disk utlity behavior due to a lack of formal documentation. The process:

  1. Create hard disk images of every conceivable geometry.
  2. Boot Qemu i386 into DOS from a boot floppy.
  3. Run FDISK through a Qemu i386 emulation and choose the default to use the whole disk.
  4. FDISK requests a reboot. Just stop the process here.
  5. Spawn a new Qemu process that picks up the freshly partitioned disk image.
  6. Run FORMAT on the new partition.
  7. Shut down Qemu.
  8. Pull as much relevant metadata as possible from the BPB and partition table and put that in a database along with the 512-byte raw boot sector and some information on this specific run-attempt itself: did we succeed? Where did things break (if appropriate)? What parameters were used for the disk image creation, particularly geometry? Which OS and boot floppy were used?

This should run in parallel on as many cores as the host machine has, because it'll take thousands upon thousands of disk images. To not destroy the host SSD, we should also put the hard disk images in a tmpfs storage area.

The result is a SQLite3 database with a whole slew of disk metadata for how FDISK and FORMAT behave on every conceivable disk geometry. This gives an authoritative answer to the question how these tools behave on different disks and for different operating systems without reverse-engineering the tools themselves.