Changelog

0.84-da3

A focused release on the same 0.84 base. Video recording got much faster and became tunable at runtime, the application finally carries its own icon on every platform, and the mount policy accepts more locations.

Video capture

Rendered recording without the slowdown. Recording the rendered display used to tax the emulation at larger window sizes. The encoder now compresses far more efficiently, and the compression level is configurable per capture mode: capture_video_compression for raw and capture_video_compression_rendered for rendered recordings. Both can be read and changed at runtime through the new compression endpoint between recordings. Recordings stay standard ZMBV and play everywhere they did before.

Application icon

The gear shows up where it should. The window now identifies itself properly to Linux desktops, so the taskbar and window title show the dosbox-automation icon instead of a generic placeholder or another program's icon, and the desktop integration files install under the application's own name. The Windows executable already carried the icon.

Mount policy

Five allowed base directories. The mount policy now accepts up to five allowed base directories, up from three.

Build

Release builds changed their optimization settings for more consistent behavior across machines.

0.84-da2

The second release. The base moved to DOSBox Staging main with the SDL3 migration merged in, and on top of that this cycle turns the MCP bridge into its own package, adds rendered video capture and a wider REST API surface, and fixes a set of DOS authenticity and rendering issues.

New Additions and Features

MCP bridge

Drive the emulator from an AI agent. The MCP (Model Context Protocol) bridge is now a standalone Python package: dosbox-mcp on PyPI. It wraps the REST API as MCP tools, so MCP-capable clients like Claude Code can read the screen, press keys, and run Lua in the emulator through their normal tool interface. The bridge can spawn and manage its own emulator instance, talks to the same localhost API behind the same token, and speaks a documented, versioned protocol; the security boundary stays in the emulator itself.

Video capture

Record what you see, not just what the emulator computes. Video capture started through the API can now capture the rendered display as seen on the screen, at window resolution and a constant frame rate, in addition to the raw emulator frames. Recording stops cleanly before the capture drive runs out of space (capture_min_free_space_mb), and a write error such as a full disk ends the recording with a playable file instead of a corrupt one. The capture status reports the mode and why the last recording stopped. The single-frame endpoint takes the same mode parameter, so one rendered screenshot needs no recording session.

REST API

New endpoints on the REST API:

Input sequences now reject unknown event fields with an error naming the allowed ones, instead of silently injecting nothing, and events can be timed with a per-event delay_ms for hand-written sequences.

DOS authenticity

Character devices like real DOS. The \DEV\ pseudo-directory resolves character devices the way DOS 2.0 and later does, and the CLOCK$ device is implemented fully: reading returns the DOS date/time record, writing sets the clock. No other DOSBox variant implements it.

What has been fixed (bugfixes)

On-screen display

The automation OSD now renders on the OpenGL backend too; in 0.84-da1 it was only visible with output=texture. Batch files can show their own overlay text with the bundled osd command while automation runs.

Hercules graphics

Hercules text mode renders at the card's true 720x350 with 9-dot character cells and the real 16.000 MHz character clock, instead of the 640x350 it had shown since a 2009 DOSBox change. Box-drawing lines are continuous and mode switches no longer resize the window.

Floppy formats

Early floppy formats (160K, 180K, 320K) mount and boot. These pre-DOS-2.0 disks carry no FAT boot signature and were refused by image validation before; found while booting the 1984 Wizardry I master disk.

Lua fixes

The wall-clock guard no longer counts time a script spent yielded, so long-running scripts with modest per-frame work are not killed at the five second mark.

Web server library

The local API makes the web server this fork's attack surface by design, so its foundation is kept current: 0.84-da2 ships cpp-httplib 0.50.1, the newest release at the time of writing. Compared to 0.84-da1 this carries the library's latest hardening, including CRLF-injection validation for chunked response trailers, escaping fixes against header injection in multipart handling, and two use-after-free fixes. Tracking the library release by release is part of how the security model is maintained.

0.84-da1

The first release as dosbox-automation. Forked from DOSBox Staging 0.82.0, rebased onto 0.84.0-alpha, and continued from there. Everything below is what this fork adds on top of upstream; for the emulator's own history, see the DOSBox Staging release notes.

New Additions and Features

Install recipes

Whole game installations as a single TOML file. An install recipe describes where the disk images are, which installer to run, which prompts appear on screen, and which keys answer them. The automation layer runs the installation unattended, disk swaps included. The source distribution ships a Python sample implementation that doubles as the end-to-end test suite, so every bundled recipe is exercised against every build. Recipes are independent of that implementation: every step maps to a documented Lua function or REST call, so any launcher can consume the same files.

Frame capture and video recording

The screen, on request. Grab the current video frame over the API as PNG, JPEG, or raw pixel data, or record the emulated screen to a lossless ZMBV AVI. Frame captures are clean emulator output, so they are stable enough to hash in automated tests.

Input recording and replay

Deterministic by design. Recordings carry dual timestamps (PIC milliseconds and frame number), and the settings that decide whether a replay diverges are pinned at record time and re-applied at replay: both CPU cycle rates (real mode and protected mode) and the guest keyboard layout travel inside the recording. A recording made on one machine types the same keys on another. Keyboard and mouse input injection supports PIC-tick or frame-based timing.

Disk swapping and mounting disk images

The emulator decides what the guest may see, not the script. Drive swap serves multi-disk installs, with image validation, and a one-way mount lock freezes the drive configuration until restart. System directories are blocked outright (on Linux: /etc, /proc, /usr, /dev, /boot, and friends; Windows equivalents likewise). Every mount, boot, and drive-swap path is canonicalized, symlink components are rejected, and disk images must pass structural validation (ISO 9660, FAT, known floppy sizes, CUE syntax). Directory mounts and image roots are whitelist-restricted (mount_allowed_bases, mount_allowed_image_roots), and the whitelists are read from the primary config only, so a bundled game config cannot widen them. The details are on the security page.

Sandboxed Lua scripting

A sandboxed Lua 5.5 engine on the emulation thread. Scripts run as coroutines with frame-synchronous waiting, screen text reading across CGA, Hercules, Tandy, and VGA text modes, memory access, mouse input, OSD control, and video capture control. Typed input (type()) paces itself against the i8042 keyboard buffer, so nothing gets dropped.

Sandboxed means sandboxed. No filesystem or process access. Bytecode is rejected at the C level and load is gone at the Lua level. Dangerous globals are removed (dofile, loadfile, require, the metatable and raw accessors, collectgarbage, string.dump). A pattern complexity guard, a configurable instruction limit, and a wall-clock ceiling on yielding operations stop runaway scripts - the ceiling is enforced even when the frame clock stalls.

Emulator control

The machine's internals, over HTTP. The memory endpoints give cheat and "Action Replay" style access to the running program: read and write RAM with segment addressing, compare-and-swap writes, and allocation and deallocation in conventional memory, UMA, and XMS. Alongside that:

REST API

Local control over HTTP, locked down by default. The web server listens on localhost only and every request needs a bearer token: fresh per start, never fully logged, compared in constant time. There is no default credential and no way to disable authentication. Host header validation blocks DNS rebinding, no CORS headers are set, request bodies are capped at 10 MiB, and remote binding requires an explicit opt-in (webserver_allow_remote).

Self-documenting. The API serves its own OpenAPI specification at /openapi.json and ships a bundled offline Swagger UI explorer: the whole surface is browsable and testable in the browser, without a token, while the API itself stays locked. The REST API reference covers the full surface in the manual.

On-screen display

You can always see when the machine is not yours. An overlay shows script, recording, replay, and input injection activity, on by default whenever the web server runs (webserver_osd). Scripts can draw their own messages with color, size, position, and auto-expire. The OSD lives on the window present path: visible in the live window and screen recordings, never in frame captures - those stay clean emulator output.

Bundled tools

  • DOS utilities on the Y: drive, available on PATH (setmode.com, unzip.exe, zip.exe, debug.com, deltree.com, xcopy.exe)
  • HTML tools: Memory Monitor, Memory Scanner, Memory Viewer, and a JavaScript API wrapper with TypeScript definitions
  • The high quality FluidR3 General MIDI SoundFont, bundled and enabled by default. Configs migrated from other DOSBox variants that still point at the old default.sf2 fall back to the bundled font instead of losing MIDI output.

Upstream bug fixes

Inherited bugs found and fixed along the way:

  • The unit test suite silently ignored its own test configuration and ran against whatever config the developer had. Tests now run fully isolated from user configuration.
  • Loading a keyboard code page early could corrupt DOS structures in low memory and hang the emulator. Fonts are no longer written before the video BIOS is ready.

Other changes

  • Rebranded to dosbox-automation throughout (binary, config directory, window title, version string)
  • Config directory moved to ~/.config/dosbox-automation/

For changes prior to the fork, see the DOSBox Staging release history. The upstream project maintains detailed changelogs for versions 0.75.0 through 0.83.0.