DOSBox-X update expands CONFIG.SYS control, debugger tools, and device support

DOSBox-X’s latest update gives stubborn DOS boots a lot more room to breathe. If a finicky game only starts when CONFIG.SYS loads drivers in a certain order, or a device-dependent installer needs a cleaner boot path, this build moves DOSBox-X closer to the way a real PC actually comes up.

That matters because DOSBox-X has never been just a game launcher. It is a fork of DOSBox built to run old MS-DOS software on modern systems, but its own project goals go well beyond games, stretching into Windows 3.x, 9x and Me emulation and even pre-2000 DOS and Windows 9x hardware scenarios. The project’s documentation also makes clear that its [config] section already understands a long list of CONFIG.SYS-style commands, including COUNTRY, DEVICE, DOS, FILES, INSTALL, LASTDRIVE, NUMLOCK, SET and SHELL.

The newest changes push that model further. DOSBox-X can now break into the command flow through DEBUGBOX when a debug-break flag is set, and it respects the echo flag so startup commands can be shown on screen. The debugger side grew a DOS DEVS command that lists guest MS-DOS device drivers, while the emulator now tracks the guest device-driver chain more carefully. That is a meaningful step for anyone trying to diagnose why a boot disk hangs, why a driver refuses to load, or why a piece of software only behaves on a very specific hardware layout.

The update also adds parsing for CONFIG.SYS device entries and introduces a new [devices] section, tightening the way DOSBox-X handles low-level startup structure. A bug that could corrupt the MCB during guest OS boot was addressed as well. On top of that, the shell gained a RUN directive, the CONFIG shell can be told when to run, and file-handle cleanup was refined so standard devices like CON, AUX and PRN stay available in the expected DOS way. A neverclose flag was added to keep those default handles alive, and close-by-name handling was corrected to use the proper DOS_CloseFile path.

For power users, the payoff is practical: better boot disks, more faithful device-driver testing, and fewer weird edge cases when emulating software that expects a real DOS environment instead of a simplified launcher. The timing also shows how active the project remains. The most recent official release before this development snapshot was 2026.05.02, published on May 2 and fixing issues ranging from MSCDEX device-name padding to savestate restore crashes, mouse cursor display in DOS/V mode and INT 13h LBA detection. Fresh builds for Windows, Linux, macOS and HX-DOS were stamped May 6, and the GitHub repository has crossed 21,000 commits, a milestone that says plenty about how deep this emulator’s plumbing has become.

DOSBox-X’s path keeps separating it from DOSBox Staging and DOSBox Pure in the same way its docs describe: less about hiding the machine and more about reproducing it. For anyone chasing a boot sequence, a driver chain or a recalcitrant old app, that distinction is the whole story.