How do Box64 and FEX-Emu enable x86 Windows games to run on ARM Linux hardware?

Running x86 Windows games on an ARM64 Linux device (such as a Snapdragon-powered laptop, Raspberry Pi 5, or Apple Silicon Mac running Linux) requires solving two translation problems simultaneously:

1. The Operating System Barrier: Translating Windows system calls (Win32 API, DirectX) into Linux system calls.

2. The CPU Architecture Barrier: Translating x86/x86_64 Intel/AMD CPU instructions into ARM64 (AArch64) CPU instructions.

Box64 and FEX-Emu handle the CPU Architecture Barrier, working hand-in-hand with Wine/Proton (which handles the OS Barrier) to form a complete execution pipeline.

The Complete Gaming Translation Pipeline

Plaintext

[ Windows x86 / x86_64 Game Binary ]
                 │
                 ▼
     [ Wine / Proton / DXVK ]         <-- Translates Win32 & DirectX calls to Linux & Vulkan
                 │
                 ▼
     [ Box64  OR  FEX-Emu ]           <-- Translates x86/x86_64 instructions to ARM64
                 │
                 ▼
  [ Native ARM64 Kernel & GPU Driver ] <-- Executes natively on hardware at full speed

1. Box64: Dynamic Recompilation + Library Wrapping

Box64 is a userspace emulator designed to run x86_64 Linux executables on 64-bit ARM systems. Its performance relies on two key technologies:

A. DynaRec (Dynamic Recompiler / JIT)

Instead of interpreting x86 instructions line-by-line (which is extremely slow), Box64 uses a Dynamic Recompiler (DynaRec). As the game runs, DynaRec translates blocks of x86_64 machine code into native ARM64 machine code on-the-fly. Translated blocks are stored in a memory cache so subsequent executions run instantly at near-native hardware speed.

B. "Library Wrapping" (Box64's Core Secret)

Emulating an entire Linux system environment on top of translating instructions creates severe CPU overhead. Box64 bypasses this through Library Wrapping:

• How it works: Box64 monitors when an x86 program makes calls to standard Linux libraries—such as libc, libm, libSDL2, libGL, or libvulkan.

• When it catches one of these calls, Box64 interrupts execution, translates the call's parameters, and forwards the work directly to the native ARM64 system library on the host OS.

• The Impact: When a game renders graphics using Vulkan or OpenGL, the rendering pipeline executes natively on the ARM GPU driver (e.g., Mesa Turnip or Panfrost) without running through x86 CPU emulation.

2. FEX-Emu: Custom IR Recompilation & Deep Wine Integration

FEX-Emu (Fast Execution Emulator) is an x86/x86_64 emulator built specifically to target high-demand Linux gaming workloads.

A. Custom IR Engine & Advanced ISA Support

FEX-Emu uses a custom Intermediate Representation (IR) compilation pipeline. Instead of a quick direct translation, it ingests x86 code into a clean IR, applies compiler optimizations, and generates highly efficient ARM64 machine code. This architecture enables FEX-Emu to emulate advanced vector instruction sets like AVX and AVX2 efficiently.

B. WoW64 / ARM64EC Backend for Wine

Instead of forcing Wine to run inside an emulation container, FEX-Emu integrates into Wine as a modular execution backend. In this setup, Wine runs as a native ARM64 application and uses FEX-Emu strictly as a translation service when executing x86 game code blocks, reducing duplicate system translation layers.

C. Syscall Forwarding & Thunking

Similar to Box64, FEX-Emu uses "thunking" layers. When an emulated Windows game requests graphics rendering through DXVK, FEX routes the Vulkan API calls straight to the native ARM64 Vulkan host driver.

3. Solving the Memory Model Challenge (TSO vs. ARM)

One of the hardest technical hurdles when running x86 code on ARM is handling memory ordering:

• x86 CPUs use Total Store Ordering (TSO): Memory reads and writes occur in a strict, predictable order across CPU threads.

• ARM CPUs use Weak Memory Ordering: To save power, ARM CPUs allow instructions to complete out of order across threads.

If a multi-threaded x86 game expects TSO but runs on a weak-memory ARM CPU, subtle thread race conditions and crashes occur.

• Software Fallback: Box64 and FEX-Emu insert memory fence instructions into translated code to force ARM memory operations to behave like x86 TSO, though this adds minor CPU overhead.

• Hardware TSO Acceleration: Modern ARM chips (such as Apple Silicon and processors supporting ARMv8.7+ memory extensions) include a hardware register flag that switches the CPU core into x86 TSO mode. When present, Box64 and FEX-Emu enable this flag, eliminating the performance penalty for multi-threaded games.

Architectural Comparison

Feature	Box64	FEX-Emu
Core Strategy	Aggressive host library wrapping for fast execution.	High instruction accuracy, custom IR optimizer, deep Wine integration.
32-Bit Support	Handled via separate Box86 companion project.	Native 32-bit (x86) and 64-bit (x86_64) support in one emulator.
Vector Instructions	Focuses on SSE/SSE2/SSE4 extensions.	Full AVX / AVX2 instruction set translation.
Primary Use Cases	Single-board computers (Raspberry Pi, RK3588) and general ARM Linux desktops.	High-end ARM Linux gaming setups, handhelds, and Proton integration.

Share on Google Plus

About Giampaolo Rossi.

Fond of computer and video games. Stay informed of the latest news on games for Linux and Android. The future of gaming is in Linux. All you need to know about How to play Windows games on Linux.