Boxedwine: running 32-bit Windows binaries through an emulated Linux and Wine

The architecture is a Linux kernel, a CPU and a Wine on top

Boxedwine runs Windows applications by running a 32-bit version of Wine and emulating the Linux kernel and CPU beneath it. The project describes it as written in C++ with SDL and supported on multiple platforms, and the GPL v2 licence is stated up front.

The layering is the whole design, and it explains both the reach and the ceiling of the project. A 32-bit Windows program does not talk to the host kernel directly, it talks to a Windows kernel that Wine reimplements. Wine in turn is a normal Linux program, so it needs a Linux kernel, which Boxedwine provides by emulation, along with the CPU the kernel expects to run on. Each layer adds translation work, and a program that expects precise timing, direct hardware access or specific driver behaviour is where the arrangement starts to strain.

The supported feature set is listed plainly: 16-bit and 32-bit Windows programs, operation on Windows, macOS, Linux and the web, the ability to run multiple Wine versions from 3.1 to 11.0, and support for applications and games using OpenGL, Direct3D and Vulkan. That last point is what makes the project more than a curiosity for old business software, because games are the demanding case and they do work.

The repository layout is a native C++ project rather than a wrapper script. There are `include/`, `lib/`, `source/`, `platform/`, `project/`, `resources/` and `tools/` directories, a `platform/` tree that presumably holds the per-platform pieces, and a `docs/` folder with the build and debugging guides.

The 26R1 release is a performance and compatibility push

The most recent release, 26R1 from 2026-04-22, is described in four bullets. It is 50% faster for all platforms except WASM, and it uses 20% less memory for 64-bit builds. It added Wine 11 support. It added OpenGL on top of D3D12 for the Windows ARM64 build, and it improved audio for Web builds, while noting the result is still not perfect.

Those four lines tell you where the effort went. Speed and memory are the perennial costs of emulation, and the memory figure matters most for the 64-bit hosts where the emulated guest and the host runtime compete for the same RAM. Wine 11 support extends the range of guest software that will run at all, since a Wine version is often a hard floor for what a program needs.

The OpenGL over D3D12 line is the ARM64 story. A native Windows ARM64 machine has Direct3D 12 but the applications it wants to run may expect OpenGL, and the translation layer is what makes those run.

The release before it, 25R1, was tagged on 2025-09-13, so the two releases are roughly seven months apart. The last push was on 2026-10-15 and the repository is not archived, so the tree is being worked on between releases.

The project's own list of what does not work yet

The TODO list is more useful than most changelogs, because it states the failure modes in the project's own words rather than a reader discovering them.

The Web build is the weakest point. The Emscripten and Web version of Boxedwine is described as still slow, with a JIT identified as what needs implementing, and the multi-threaded build stutters with sound. A JIT would replace translating each guest instruction with running precompiled native code, which is the standard answer to slow emulation, so its absence is the direct cause of the performance gap.

The second entry is a specific platform bug: OpenGL on Mac does not work with frame buffers. Frame buffers are how OpenGL offscreen rendering is done, so anything that renders to a texture rather than to the screen is affected on that platform.

The third is the compatibility ceiling: games after the year 2010 have limited success at running. Given that Wine support and CPU emulation both improved over the years, the limit is not one thing but the accumulation of guest expectations, from threading models to graphics APIs that predate D3D12 and Vulkan.

The fourth is .NET, where newer versions do not work.

The fifth is a plain feature gap, joystick support. So before promising someone a game will run, check that it is a 32-bit title from before roughly 2010, and treat the platform-specific notes as real constraints rather than caveats.

The published benchmarks are relative, and that is the point

The project publishes performance figures with Wine 10 in the README, and they are structured in a way that is more informative than a single headline number.

The Cinebench 11.5 multi-core figures put native Windows 11 on an i7-14700 x64 at 10.02, a Mac Mini M4 Arm64 running macOS at 4.71, a Snapdragon X at 4.14, an x86 build of the i7-14700 at 3.90, and Asahi Linux on a Mac Mini M1 Arm64 at 2.67. The single-core numbers are lower and the ordering is similar: 1.01 for the x64 i7-14700 under Boxedwine, 0.84 for the M4, 0.66 for the Snapdragon X, 0.50 for the M1 under Asahi Linux, and 0.42 for the x86 build.

The Quake 2 timedemo figures are the ones that matter for a games project, and they are striking. The M4 under macOS reports 88.9 fps, the x64 i7-14700 reports 72.7 fps, Asahi Linux on the M1 reports 65.7 fps, the x86 build reports 57.4 fps and the Snapdragon X reports 57.3. Quake 2 running above 60 fps under emulation is the clearest evidence in the project that the CPU emulation path is efficient for the kind of work that era of software did.

The contrast between the Cinebench ratios and the Quake 2 numbers is the interesting part. CPU-bound benchmarks lose most of their speed, while a graphics and timing workload from the late 1990s runs comfortably. The older the guest software relative to the host, the more headroom the emulation has, which is the general shape of the ceiling rather than a fixed threshold.

Platform coverage is broad, and each target has a caveat

The platforms being tested are listed as Emscripten for WASM, Linux 64-bit x86 and Arm64, macOS on ARM, Windows 32-bit, and Windows 64-bit for both x86 and Arm64. The repository topics agree, listing arm64, linux, macosx, wasm and windows.

That list spans a very wide range of hardware, which is unusual for a project of this kind, and each entry comes with a reason to read further. The macOS ARM target is new enough that Mac OpenGL frame buffer issues are listed as open. The Linux Arm64 target is the one that makes the project interesting for embedded and single board computers, where running a Windows binary means running it in an emulated x86 or ARM environment rather than natively. The Windows ARM64 target is where the OpenGL over D3D12 work lands, and the 32-bit Windows build covers software that has no 64-bit version at all.

The Emscripten target is the outlier, since it puts the whole emulator in a browser. The project lists the JIT as the missing piece, which is a heavier piece of engineering in that environment than on a native target, and the sound stuttering is a separate problem from the CPU speed.

Build and debugging guidance is split across the documentation. There is a How to Build Boxedwine guide, a separate How To Build OSMesa on MacOSX guide for the software OpenGL path, a Developer Debugging document, a CPU Emulation document, a Troubleshooting Games and Apps document and an Upcoming Features roadmap. There is also a BUILD.md at the top of the repository, a Jenkinsfile for continuous integration, a `buildFlags.txt` and a `commandLine.txt`.

The documentation index itself is a sign of how much there is to know before this runs well on a given target, which is the practical argument for reading it rather than guessing.

What the project is not, and the licensing question it raises

Boxedwine is not a Wine replacement on a normal desktop. Native Wine runs on the host kernel, so it is close to native speed and sees the real drivers. Boxedwine runs Wine inside an emulated machine, so it is portable to platforms with no Wine build and it can run a full Linux userspace without touching the host, at a large performance cost. If you have a desktop and want a Windows program to run well, native Wine is the obvious answer and Boxedwine is the wrong tool.

The interesting use is where native Wine is not an option, on an ARM Mac, a non-x86 Linux board, or inside a browser tab.

That is also where the licensing question appears, and it deserves care. The emulator is GPL-2.0, which is fine for the emulator itself. Running a commercial game inside it is a separate question about what the game and its data files permit, and the GPL terms of the emulator do not settle it. The project's description of running games is not a licence grant from the publishers of those games, and anyone planning to ship or redistribute such a setup needs to check the rights on the specific title rather than infer permission from the emulator's licence.

There is also a practical matter of how you obtain the guest software. Whether you run the program from a local copy or stream it is a decision with legal weight, and it is separate from the technical question of whether the emulation is fast enough.

The final limitation to name is the version window. Wine versions from 3.1 to 11.0 are supported, which is a wide range and a useful one, since it means older titles that need an older Wine can be run deliberately rather than by accident.

Editorial conclusion

Boxedwine fits a developer who needs a specific 32-bit Windows program or game running on macOS, Linux, a Raspberry Pi class ARM board or in a browser tab, since the whole point is that the Wine environment lives inside an emulated machine rather than on the host kernel. Do not expect it to replace native Wine for daily use, since games from after 2010 have limited success, newer .NET versions do not work, and the Web build still stutters with sound because the JIT is listed as unfinished. Before you plan around it, read the licensing position on running a commercial game inside the emulator, since the project is GPL-2.0 and the game is not, and check the build documentation for your platform, since the macOS OpenGL build has known issues with frame buffers. The last push was on 2026-10-15 and the current release is 26R1 from 2026-04-22.

Frequently asked questions

Official sources

1. danoon2/Boxedwine on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases