# DOSBox Staging: a modern DOSBox continuation > DOSBox Staging keeps your old DOSBox configuration working while replacing the toolchain underneath with C++23, vcpkg, continuous integration and per-commit development builds. The dependency table is where the real design decisions are visible. **dosbox-staging/dosbox-staging** — DOSBox Staging is a modern continuation of DOSBox with advanced features and current development practices. - Repository: https://github.com/dosbox-staging/dosbox-staging - Website: https://www.dosbox-staging.org/ - Stars: 1,836 · Forks: 263 - Language: C++ - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/dosbox-staging-dosbox-staging ## Drop-in means drop-in, and that is the whole pitch DOSBox Staging describes itself as a modern continuation of DOSBox with advanced features and current development practices, and the compatibility claim is specific rather than aspirational: it is a mostly drop-in replacement, your existing configurations will continue to work, and you get access to many advanced features. That framing explains the project better than any feature list. This is a fork whose primary user is someone who already has a working DOSBox setup and does not want to relearn it. The migration cost is intended to be near zero, and the upgrade you are buying is the maintenance underneath. The README points first-time users and people migrating from other DOSBox variants at the Getting started guide on the project website, which is the right place for the details it does not carry here. The About page is where the project's own scope description lives. Stable release builds are published for Windows, macOS, and Linux through the project website rather than through GitHub releases, which is a deliberate separation from the development builds. ## C++23, vcpkg, and a development build per merge The developer-facing feature table is the clearest statement of what changed. Version control is Git, the language is C++23, logging is Loguru for C++, the build system is CMake with Ninja or Visual Studio 2022, and the dependency manager is vcpkg. Then the quality rows: CI, static analysis, dynamic analysis, clang-format, development builds, and unit tests. The static analysis entries point at two specific workflows, a clang-analysis one and a PVS-Studio one, and the unit test row links to a `tests/` directory. Development builds are the most unusual item. They are created automatically on every commit merged to the `main` branch, and you need to be logged in to GitHub to download them. That is a different distribution model from tagged releases: you get the current state of the tree within minutes of a merge, in exchange for requiring an account and giving up any stability guarantee. The repository layout backs up the tooling story. There is `.clang-format` and `.clang-tidy` at the root, `CMakePresets.json` so the CMake configurations are versioned, a `vcpkg.json` with `vcpkg-configuration.json` and a `vcpkg-triplets/` directory, `.pylint` and `.mdl-styles` for the Python and Markdown linters the project also runs, and `.lsan-suppress` for the sanitiser. ## Twelve dependencies, eight of them mandatory The dependency table is where the actual scope of this fork becomes visible, because each entry names the feature it provides and whether it is optional. Eight are required. Asio 1.32.0 provides the network API for emulated serial and IPX. FluidSynth 2.5.7 handles General MIDI playback. IIR 1.10.0 does audio filtering. libpng 1.6.58 provides PNG encoding of screen captures. Opus File 0.12 handles CD audio playback for Opus-encoded tracks. SDL 3 at 3.4.16 is the OS-agnostic API for video, audio and eventing, and SDL_image 3 at 3.4.4 does image decoding for many popular formats. SpeexDSP 1.2.1 handles audio resampling. Four are optional. GoogleTest 1.18.0 is for unit testing during development. libmt32emu 2.8.3 gives Roland MT-32 and CM-32L emulation, which matters if you want the sound of those sound chips rather than General MIDI. libslirp 4.9.1 is a general purpose TCP-IP emulator. zlib-ng 2.3.3 covers ZMBV video capture, and there is a footnote stating you can use plain old zlib instead. Two things follow. First, SDL 3 is a hard requirement, which is a real difference from the original DOSBox and a build constraint for anyone on an older system. Second, a general MIDI emulator plus resampling plus filtering plus Opus CD audio is a considerably more complete audio stack than a typical DOS emulator, which is where a large share of the advanced features claim lives. Slirp is handled differently from the rest: it is built separately as a dynamic library via vcpkg and loaded on demand at runtime if available. The dosbox-staging-ext project holds it, and its release comments tell you which version a given build shipped. ## Audio is where the fork is furthest from the original Pulling the dependency table apart by function shows an emulator built around sound. General MIDI playback through FluidSynth is the floor, not the ceiling. Above it sits IIR for filtering, SpeexDSP for resampling, and Opus File for CD audio tracks. The optional libmt32emu entry is the clearest statement of intent about hardware synthesis. Roland's MT-32 and CM-32L were sound modules with distinctive character, and emulating them is a niche requirement that a general MIDI path cannot satisfy. Making it an optional dependency rather than a default keeps the binary smaller for people who do not need it. Screen capture is the other non-obvious area. libpng provides PNG encoding of screen captures rather than something more exotic, and ZMBV video capture comes through zlib-ng, with plain zlib as a documented substitute for anyone who would rather not take the extra dependency. Network play sits on Asio for emulated serial and IPX, which is how the multiplayer support for the era's games gets its transport. With libslirp optional and dynamically loaded, the TCP-IP emulator for higher-level networking is present only when the separate package is available at runtime. ## Three build instructions, and a repository with a website The README defers building to platform specific documents: `docs/build-windows.md`, `docs/build-macos.md`, and `docs/build-linux.md`. It does not reproduce a configure line, a compiler invocation, or a dependency install command, so there is nothing to copy from here beyond the vcpkg and CMake tooling named in the feature table. The repository is arranged as a working project rather than a source drop. There is a `website/` directory, so the documentation site is built from this repository. There is `extras/` and `scripts/`, `resources/` for data files, `cmake/` for the build modules, `cmake/` alongside `CMakePresets.json` at the root, and a `licenses/` directory that sits next to `LICENSE` and presumably accounts for the bundled third-party components. There is also a `.claude/` directory, which suggests the project expects AI coding agents to work in it, alongside a `.muon.ini`. The presence of `.pylint` and `.mdl-styles` is a reminder that not all of the tooling is C++: there are Python scripts and Markdown documentation to lint. The licence badge reads GPL-2.0-or-later, while the repository's licence field records a custom licence that GitHub cannot classify. The badge is the specific statement, and the LICENSE file is where the actual terms are. ## How to choose between stable and development builds The project publishes two kinds of binary and they answer different needs. Stable release builds are for regular users and come from the project website, with a download page per platform: Windows, macOS, and Linux. The recent tags are v0.83.0 dated 2026-08-27, v0.82.2 dated 2025-06-17, and a rolling `dev-latest` tag currently at 0.84.0-alpha dated 2026-10-08. Development builds are produced on every commit merged to `main` and require being logged in to GitHub. There is no stability promise attached to a specific commit beyond the fact that it is what was on main at that moment. The practical rule follows from that. Use a stable build unless you are testing a specific change or contributing, and if you do use a development build, note the commit, because the same download will not be there next week. The repository is not archived and had a recent push, so the project is under active development. The release cadence between 0.82.2 and 0.83.0 was about fourteen months, which is a slow cadence for a 0.x project but consistent with a codebase that size. For comparison, the alternatives in this space are other DOSBox forks and virtualization layers, and the practical difference between them is usually the audio and video stack rather than the emulation core. This fork's dependency list is where you can see which of those two areas it has invested in. ## Conclusion Adopt DOSBox Staging if you are running DOSBox today and want the same configuration file with current audio, video and CI behind it, since compatibility is the project's stated promise and the build tooling is modern throughout. Do not expect a stable release cadence from the development builds, since those are produced per commit and require a GitHub login. Verify which SDL generation you have available, because DOSBox Staging depends on SDL 3 and SDL_image 3. ## FAQ ### Will my existing DOSBox configuration work with DOSBox Staging? Yes, that is the stated design goal: DOSBox Staging is described as a mostly drop-in replacement for older DOSBox versions, so existing configurations continue to work while gaining additional features. The Getting started guide on the project website is the recommended starting point for migrating from other DOSBox variants. ### Where do I download DOSBox Staging, and what is the difference between the two build types? Stable release builds for Windows, macOS, and Linux are on the project website. Development builds are created automatically on every commit merged to main and require being logged in to GitHub to download, so they carry no stability guarantee. ### What are the required library dependencies for building DOSBox Staging? Eight are required: Asio, FluidSynth, IIR, libpng, Opus File, SDL 3, SDL_image 3, and SpeexDSP. Optional ones are GoogleTest for unit testing, libmt32emu for Roland MT-32 emulation, libslirp for TCP-IP emulation, and zlib-ng for ZMBV video capture, where plain zlib is a documented substitute. ## Sources - [dosbox-staging/dosbox-staging on GitHub](https://github.com/dosbox-staging/dosbox-staging) - [Issues](https://github.com/dosbox-staging/dosbox-staging/issues) - [Project website](https://www.dosbox-staging.org/) - [README](https://github.com/dosbox-staging/dosbox-staging/blob/main/README.md) - [Releases](https://github.com/dosbox-staging/dosbox-staging/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dosbox-staging-dosbox-staging