Box64: an x86_64 userspace emulator for ARM64, RV64 and LoongArch Linux

What Box64 solves, and which machines it targets

Box64 enables running x86_64 Linux programs, including games, on non-x86_64 Linux systems such as Arm. The README states that a 64-bit little-endian host system is required. The project targets ARM64, RV64 and LoongArch Linux devices, and the repository carries dedicated source trees for Android (x64android, x86android) alongside the main src directory.

The intended user is not someone who wants to emulate a whole PC. Box64 is a userspace emulator: it translates x86_64 function calls and uses the host's own libraries where it can. The README names libc, libm, SDL and OpenGL as native system libraries it uses, and describes the result as ease of integration and surprising performance in many applications. That design choice is the whole point. A full system emulator would have to emulate the kernel, the drivers and the GPU stack too. Box64 only has to bridge the instruction set and the library boundary.

The practical consequence is that Box64 is a tool for people who already have a working Linux system on unusual silicon: a Raspberry Pi, an Ampere Altra developer platform, a SpacemiT or SOPHGO board, a Radxa or StarFive device, a LoongArch desktop. The README's hardware acknowledgement list reads like a map of that ecosystem. If your host is x86_64, Box64 has nothing to offer you.

DynaRec, native library calls and the DynaCache file layout

Box64 has two execution strategies. The interpreter walks x86_64 instructions one at a time. DynaRec compiles blocks of them ahead of execution. The README states that with DynaRec for Arm, RISC-V and LoongArch platforms, Box64 achieves a speed boost 5-10x faster than the interpreter alone. That figure is the project's own claim, not a measurement anyone can reproduce from this page.

The second mechanism is DynaCache, which the README says is now enabled by default, with compression. It writes generated code for executed binaries and libraries into ~/.cache/box64 so that launch time can be greatly reduced on the second run. The files are compressed and will take up to 2Gb by default. That is a real disk cost on small SBCs with eMMC or an SD card, and it is the first thing to check if a device runs out of space after installing Box64.

DynaCache can be put into read-only mode, or disabled, through an rcfile. The README gives this example, which belongs in ~/.box64rc:

[*]
BOX64_DYNACACHE=2

A value of 2 means read-only, so Box64 uses an existing cache but does not write new entries. The README notes that 0 disables it completely. Read-only mode is the sensible setting for a device with limited or frequently rewritten storage, at the cost of never benefiting from a cache built on a previous run.

Installing Box64 and running a first x86_64 binary

The README does not carry install commands inline. It points to three documents: Compilation Instructions in docs/COMPILE.md, Bundle x86 Libraries in docs/BUNDLE-X86-LIBS.md, and Wine Installation for Box64 in docs/WINE.md. The repository also ships packaging material: a debian directory, pkgbuilds, a postinst script, CMakeLists.txt and a cmake_uninstall.cmake.in. There is no distro package command quoted in the README, so treat the source build as the documented path.

Once box64 is on the PATH, the basic invocation is one line. The README gives it as:

box64 ./program [args]

That runs an x86_64 Linux program with its arguments. The README also documents two companion commands. box64 -k kills all the emulated processes, which matters because a hung emulated process can otherwise be awkward to clean up. box64-bash gives you an x86_64 bash environment, useful when a build script or installer assumes an x86_64 shell.

One trap is worth knowing before you start. The README warns that some shell scripts, such as the GOG game installer, may rely on uname -m to determine the current architecture. Run them as box64 script.sh so Box64 can take over instead of the script detecting the real host CPU and taking the wrong branch.

Configuration lives in two ini files, /etc/box64.box64rc and ~/.box64rc. The README states the priority order explicitly: ~/.box64rc wins over /etc/box64.box64rc, which wins over the command line. That is the reverse of what many people expect, so a setting placed on the command line can be silently overridden by a user rcfile. If you do not want the system file, copy it to ~/.box64rc first.

Where Box64 fails: 32-bit code, OpenGL 3, and library gaps

The hardest boundary is bit width. Box64 requires 64-bit libraries on the host system, because it directly translates x86_64 function calls. For 32-bit binaries the README directs users to Box86 or Box32. Box32 is described as still experimental, though the README adds that it is pretty stable now and can be used. Anyone whose workload is a 32-bit game or a 32-bit Windows application is therefore on a secondary, less settled path. The README notes that Wine64 and Proton are supported, and that 32-bit components require Box86; systems with both Box64 and Box86 can run 32- and 64-bit Windows programs. Wine's WOW64 build can run x86 Windows programs in a Box64-only environment, which the README calls experimental but working in most cases.

The second failure mode is graphics. The README states that many Unity games require OpenGL 3+, which may be challenging on ARM and RISC-V SBCs. This is not a Box64 bug; it is the host GPU driver. The README offers two workarounds. For Pi4 and Pi5 users, set MESA_GL_VERSION_OVERRIDE=3.2 together with BOX64_DYNAREC_STRONGMEM=1 to prevent freezes and enable strong memory mode. For Panfrost, set PAN_MESA_DEBUG=gl3 to force higher OpenGL profiles, which the README says helps if a game starts but quits unexpectedly before showing any content.

The third limit is simply that translated code is not native code. The 5-10x DynaRec figure is a comparison against Box64's own interpreter, not against running the same binary on x86_64. A CPU-bound application that is already marginal on the host will not become comfortable under translation.

Box64 against FEX and full system emulation

The most direct alternative in the same niche is FEX-Emu, which also translates x86_64 userspace code to ARM64. The difference is architectural emphasis. Box64's README frames the project around native system libraries (libc, libm, SDL, OpenGL) and around DynaRec plus a compressed DynaCache in ~/.cache/box64, and it publishes a game compatibility list at box86.org/app. FEX is not described in the Box64 documentation, so the honest comparison stops at the fact that both occupy the userspace translation slot and that Box64's documented tuning surface is the .box64rc ini files and the environment variables in docs/USAGE.md.

A second alternative is running the workload on an x86_64 machine, or under a full system emulator such as QEMU in system mode. That approach emulates the whole machine, so it does not depend on the host having 64-bit libraries or on the application's library set being bridgeable. The cost is that everything is emulated, including the kernel and the graphics path, and the README's stated advantage for Box64, ease of integration and use of native libraries, disappears. Box64 is the lighter option precisely because it refuses to emulate what it can borrow.

A third path, for Windows software specifically, is Wine64 or Proton on top of Box64, documented in docs/WINE.md and docs/STEAM.md. That is not a competing emulator, it is the layer above, and the README treats it as a supported configuration rather than a workaround.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-22. Releases are frequent enough to be worth tracking: v0.4.0 on 2026-01-03, v0.4.2 on 2026-04-20 and v0.4.4 on 2026-08-02. The README links to docs/CHANGELOG.md for version updates, and that file, not the release tag, is where behaviour changes are described. Upgrading means rebuilding from source or using the packaging under debian/ or pkgbuilds/, then re-running your applications, because a new build invalidates assumptions baked into the DynaCache.

Two upgrade costs are easy to underestimate. The first is the DynaCache itself: up to 2Gb of compressed generated code by default, in ~/.cache/box64. On a small device this is a meaningful fraction of storage, and it is regenerated after a version change. The second is the rcfile priority rule. Because ~/.box64rc overrides /etc/box64.box64rc, a per-user file left over from an earlier troubleshooting session can quietly override settings that a package update placed in the system file.

The licence is MIT, per the LICENSE file in the repository root. That is a permissive licence, which in practice means the obligations around redistribution are light compared with copyleft licences. This is a factual note about the licence identifier, not legal advice; if you are shipping Box64 inside a product, read the LICENSE file and any bundled third-party notices yourself, especially given the external/ and wine/ directories.

Editorial conclusion

Adopt Box64 if you are on a 64-bit little-endian ARM, RISC-V or LoongArch host and need to run x86_64 Linux binaries or Wine64 and Proton titles without a full system emulator. Do not adopt it for 32-bit x86 binaries (that is Box86 or the experimental Box32), for hosts without 64-bit libraries, or for Unity titles that need OpenGL 3+ on hardware that cannot provide it. Before committing, verify three things on your own board: that your host has 64-bit libraries, what the first and second launch times look like with DynaCache enabled, and whether your target application appears on the compatibility list at box86.org/app.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. ptitSeb/box64 on GitHub
4. README
5. Releases