Static recompiler that runs Windows x64 on Apple Silicon

The static recompiler lifts original Windows machine code to LLVM Intermediate Representation (IR) before compiling it specifically for macOS, eliminating the need for instruction-level emulation during execution. This approach has been successfully demonstrated with several Windows applications, including PuTTY Plink 0.83, which runs natively on Apple Silicon with performance significantly better than traditional compatibility solutions.

Testing shows the recompiled PuTTY Plink runs at 6.20× the speed of the original binary under Wine + Rosetta (42.31 ms vs. 262.23 ms) while using 68.9% less memory (5.51 MB vs. 17.74 MB RSS). The tool has also successfully recompiled and run PuTTY's GUI interface, jq 1.8.2, and ripgrep 14.1.1, with output matching the original applications byte-for-byte.

Performance Gains

The recompiled applications demonstrate substantial performance improvements over compatibility layers. For SSH connections using Plink, the lifted version runs approximately one and a half times faster than Wine + Rosetta when the server is already running. Memory usage, however, is 1.6 to 2 times higher for hosted programs, though the developers note this hasn't been fully investigated yet.

The tool handles complex Windows features including runtime DLL loading with LoadLibrary, named exports, callbacks, thread-local storage, and proper unloading. It can lift Wine's own Windows-side DLLs like ntdll, kernelbase, ucrtbase, user32, gdi32, comctl32, and ws2_32 as ordinary guest DLLs, providing a more complete compatibility solution than simple translation.

Current Limitations

The recompiler is not yet a general solution for running any Windows binary. GUI and network programs require hosted mode, which still needs a Wine 11.0 installation and Wine prefix, with Wine's wineserver running under Rosetta. The tool also doesn't produce standalone .app bundles yet.

Certain CPU extensions like AES-NI, SHA extensions, carry-less multiply, and AVX are not currently lifted. Some code still runs through a fallback x86 interpreter for runtime-generated code and indirect jumps that the lifter couldn't recover. Direct3D support is also not implemented, and ripgrep currently runs only in single-threaded mode through the launcher in diagnostic mode.

Development Challenges

The project documentation reveals numerous technical challenges overcome during development, including indirect branch discovery, TLS callback initialization issues, Windows API-set virtual DLL indirection, and memory protection translation between Win32 and POSIX systems. Each required specific solutions to maintain compatibility with Windows runtime behavior.

The developers have created a comprehensive test suite that exercises 11,121 arithmetic and control-flow instruction permutations, atomic operations, data relocations, and console tests. They've also provided detailed instructions for setting up the development environment, running regression tests, and reproducing specific milestones like recompiling Plink and building jq for ARM64.

While promising, the tool represents an ongoing project rather than a complete solution. Future development will likely focus on expanding CPU support, reducing memory overhead, and potentially creating standalone application bundles that don't require Wine dependencies for certain types of programs.