- Rust 83.7%
- DIGITAL Command Language 16.3%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Introduce schema-2 inline scalar hardware with field-level hierarchy replacement and per-value provenance while preserving schema 1 unchanged. Select the operating system independently, derive only an evidence-backed complete-image profile from the effective boot medium, reject mixed schema hierarchies, and expose the normalized composition through explanations so hierarchy structure does not become hardware identity. Expand the closed package catalog parser to construct the already modeled attributes, compatibility predicates, capabilities, dependency alternatives, conflicts, preferences, and layer-order edges. Convert domain validation failures into descriptor-path-aware catalog diagnostics so malformed declarative policy fails before resolution without weakening domain invariants. Add hierarchy, canonical-equivalence, profile-mapping, and complete package-metadata tests; update the manifest, package, and roadmap documentation; and retain typed finisher parsing and repeatable hardware components as explicit next increments. |
||
| .roo | ||
| cli | ||
| common | ||
| disk | ||
| docs | ||
| examples/collection | ||
| fat | ||
| generator | ||
| machinespec | ||
| manifest | ||
| operatingsystem | ||
| package | ||
| plans | ||
| .gitignore | ||
| AGENTS.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| Jenkinsfile | ||
| LICENSE | ||
| README.md | ||
Welcome to DOSContainer
DOSContainer aims to provide a command line generator for 100% vintage-compatible floppy and hard disk images for IBM-PC and compatibles. This aims to support my retro computing hobby and the collection building that goes with it.
Development status: the workspace and preview CLI can safely generate one evidence-backed complete PC-DOS 3.00 system floppy from a hierarchical manifest. Validation remains available as a non-writing preflight.
What's the point?
The DOS computing environment consisted of huge numbers of hardware configurations with all kinds of drivers and compatibility quirks. That fact, coupled with the fact that there were thousands of games and applications, accounts for literally a bazillion of possible permutations between all of those moving parts.
In order to help collection builders, DOSContainer aims to facilitate the quick creation of pristine disk image files that make up a collection. You tweak the manifest file that serves as input, then DOSContainer pops out a cleanly generated new disk image that is configured precisely to your specifications:
- File format suitable for use in emulators or for copying straight to old hardware.
- 100% correct boot sector code
- FAT filesystem quirks correspond with the OS version.
- Install bare minimal base OS
- Middleware, drivers, memory management etc.
- Your game or application itself
- Autoboot configuration in AUTOEXEC.BAT
The target model is deliberately similar to image layering without pretending DOS
images are containers. A separately selected machine specification describes hardware
facts and limits. The image manifest requests applications, drivers, or capabilities;
package metadata then selects compatible, SHA-256-pinned ZIP payloads and records the
decision in an explainable build plan. Verified payloads are layered as data, after
which typed finishers compose CONFIG.SYS and AUTOEXEC.BAT before FAT serialization.
Package payloads will not execute code on the build host in the initial architecture.
Use case?
You want all of your hundreds of games to boot with EGA configured and Roland MT-32 sound for the old retro setup you have in the attic? DOSContainer makes it easy to do that. It also makes it easy to do the exact same thing but for VGA and SoundBlaster Pro audio for the MiSTer in your living room. Did the world move on and deliver a new mouse driver? Swap it in across thousands of image files without breaking a sweat.
Current status
Supported now
- Validated PC-DOS 2.00 floppy profiles for 160, 180, 320, and 360 KiB media.
- Validated PC-DOS 3.00 floppy profiles for 360 KiB and 1.2 MiB media.
- Exact BPB and VBR assembly from licensed, hash-recorded historical assets.
- MBR parsing and serialization, inclusive partition validation, CHS/LBA conversion, and stream-backed disk I/O.
- Authoritative FAT12 volume-layout calculation and an in-memory FAT directory and allocation model.
- Complete deterministic FAT12 image serialization for the
ibm-pcdos-300-f525-360kprofile, including version-matched system files. - Schema-versioned TOML hierarchy discovery, explicit merge operations, provenance, source loading, preflight, and atomic library-level publication.
- A preview
doscontainer validate --collection-root <PATH> <MANIFEST>command that preflights a complete request without creating or truncating output. - A safe
doscontainer generate [--force] --collection-root <PATH> <MANIFEST>command with atomic publication, default overwrite refusal, and failure cleanup. - CLI hierarchy explanation and complete-image profile listing, with stable exit categories for automation.
- A copyable hierarchical collection under
examples/collection; its walkthrough incli/README.mdresolves precedence, validates inputs, and generates a bootable image without external files.
Not supported yet
- Separate machine-specification catalogs or schema 2 package requests.
- Remote ZIP package acquisition, a content-addressed cache, compatibility/dependency resolution, locked build plans, or package-aware layering.
- Generated
CONFIG.SYSandAUTOEXEC.BATfinishers; those files can currently be supplied only as ordinary manifest file imports. - Complete-image evidence for accepted profiles other than
ibm-pcdos-300-f525-360k. - Accepted hard-disk compatibility profiles. Partition primitives and MBR bytes are tested, but partitioned generation is rejected until historical fixtures support an exact profile.
- PC-DOS 1.x generation, DOS 3.31 BPBs, FAT32, or arbitrary OS/media combinations.
The next increments complete collection-scale planning, then introduce separate machine specifications and a deterministic package resolver before any network or ZIP handling. Secure acquisition, transactional layering, and typed DOS configuration finishers follow that pure planning boundary. Hard-disk generation follows only after an evidence-backed profile and independent fixtures are available.
Start with the architecture and status guide, which contains the dependency and generation diagrams, invariant glossary, compatibility matrix, API example, and documentation map. Contributors should also read CONTRIBUTING.md, especially before changing licensed binary assets.