Hangover: running Windows x86_64 and i386 apps on ARM64 Linux with selective emulation

Only the application code is emulated, not the entire Wine installation

Hangover runs x86_64 and x86_32 Windows applications on aarch64 Linux by drawing the emulation boundary at the Win32 syscall level rather than around the entire Wine stack. When a Windows application makes a system call, such as NtUserCreateWindowEx (the example the README gives), execution leaves the emulator and continues natively on the ARM64 host. Everything Unix-related is never passed through the emulator.

Most alternative approaches emulate Wine itself in x86 mode, so every Wine internal call passes through the emulator along with the application code. Hangover avoids that cost by running only the application instructions in the emulator and letting Wine operate as a native ARM64 process. The project's benchmark notes describe this difference as especially visible when comparing Hangover with Wine running under Box64, since the overhead in that configuration accumulates on both the application and the Wine layer.

For 64-bit applications, Hangover uses the ARM64EC ABI combined with the FEX emulator. ARM64 applications run without emulation entirely, so a native ARM64 binary like ARM64 7-Zip passes through with no emulation overhead at all. Running ARM32 Windows applications on x86_64 Linux is also in scope, though the stated main focus is x86_64 and i386 on aarch64.

HODLL and HODLL64 select which emulator DLL processes each application

Two environment variables control which emulator handles a given run. HODLL64 picks the 64-bit emulator DLL, and HODLL picks the 32-bit one. libarm64ecfex.dll, the FEX-based library, is the current default for 64-bit applications, which means no variable is needed for most x86_64 binaries:

$ wine your_x86_64_application.exe

For 32-bit applications, wowbox64.dll (the Box64-based library) is the current default, so the command is the same. Switching to the FEX-based 32-bit emulator requires setting HODLL explicitly:

$ HODLL=libwow64fex.dll wine your_x86_application.exe

The xtajit64.dll option for HODLL64 is a Wine stub DLL rather than a functional emulator. wow64cpu.dll for HODLL enables what the README calls native i386 mode on x86_64 hardware, a different path from the ARM emulation path. The README advises that if the default emulator produces problems with a specific application, trying an alternative emulator through these variables is the recommended step before assuming the application cannot run. Each DLL name in the variables is a concrete choice with its own behavior, not a generic switch.

Debian and Ubuntu .deb packages attach to each GitHub release

Prebuilt .deb packages for Debian 11, 12 and 13, and for Ubuntu 20.04, 22.04, 24.04 and 25.10, attach to each GitHub release. Raspbian and Armbian users can install from those same Debian packages. After downloading the release archive, the install command is:

$ sudo apt install ./hangover*.deb

Termux packages are available through the Termux Repository at x11-packages/hangover-wine in the termux-packages repository, which the README links to rather than bundling a separate Termux release.

Building from source is documented in docs/COMPILE.md, but the README gives no commands from that file. Anyone building for a distribution not in the list above, or modifying the source, starts from docs/COMPILE.md at the repository root. The latest release is hangover-11.16, published on 2026-08-30, which followed hangover-11.9 from 2026-05-17 and hangover-11.4 from 2026-03-15. Three releases in a single calendar year indicates the project is tracking Wine upstream rather than releasing on a fixed schedule of its own.

DXVK requires Vulkan 1.3 and five native DLL overrides in winecfg

Running DirectX applications through Hangover requires DXVK, which in turn requires a Vulkan 1.3 driver with specific capabilities. The README notes this may not be available on a lot of ARM64 hardware, which is a meaningful constraint for single-board computers and phones running ARM64 Linux rather than server-class ARM64 systems.

Placing the DXVK binaries follows a specific layout. The x32 binaries go into $WINEPREFIX/drive_c/windows/syswow64. The arm64ec, aarch64 or x64 binaries go into $WINEPREFIX/drive_c/windows/system32, with the specific choice depending on the application type and the hardware. For x86_64 applications, the README says to try arm64ec first since it should perform best, then fall back to x64 if arm64ec fails.

After placing the binaries, winecfg must be opened to the Libraries tab, and native DLL overrides added for 5 names: d3d8, d3d9, d3d10core, d3d11 and dxgi. Skipping any one of them means that DirectX version falls back to Wine's built-in implementation rather than DXVK.

Wayland is not enabled by default, but can be activated alongside X11 with:

$ wine reg.exe add HKCU\\Software\\Wine\\Drivers /v Graphics /d wayland,x11

QEMU removed, Blink not yet integrated, and PPC64le ended before 0.8.x

Three emulator situations are documented as absent or incomplete. QEMU was once listed as an integration and is now marked Removed in the emulator status list. Blink has been started as an integration but is not yet part of the main repository, so projects that need Blink support cannot get it through the current master branch.

PPC64le support ended before the 0.8.x series. The README states PPC64le will not be added back in the near future, and users needing it are directed to releases before 0.8.x. This is a firm architectural decision rather than a deferred item, and the note's phrasing makes the distinction clear.

RISC-V 64-bit Linux support exists as a separate branch named riscv64 rather than part of master. The author specifically mentions planning to invest more time on the RISC-V port, which sets it apart from PPC64le in terms of development direction. The project's version history is tracked through distinct branches: Hangover-Classic covered 0.4.0 to 0.6.5, and Hangover-WOW64 covered 0.8.1 to 9.19, each representing a different architecture for the emulation boundary.

Patreon ended; the author will deliver releases but with less time invested

The README contains a direct statement on development resources. The author has ended activities on Patreon and similar platforms. New releases and updates will continue, but with less time invested in the project overall, with the stated exception of the RISC-V port. That is a concrete change in commitment, and it shapes expectations for issue response time and feature additions.

A Discord server is available for contributors and previous financial supporters, offering advanced user support and development discussions. Users who were not financial supporters are not mentioned as a target audience for the server, which means the main user communication path for the general public is the GitHub repository itself.

Hangover was started by André Zwing and Stefan Dösinger in 2016, making it a decade-old project by any measure. The version numbering follows Wine's release cadence rather than an independent scheme, so the jump from 9.19 to 11.4 reflects Wine's own versioning rather than a reset of the project version. The last push to the master branch was on 2026-08-30.

LGPL-2.1 licence, submodule structure, and what redistribution requires

The licence is LGPL-2.1. Wine itself also carries LGPL-2.1, so the licensing is consistent across the stack. Anyone who distributes a modified Hangover build must satisfy the LGPL-2.1 requirements, and the LICENSE file at the repository root is the text to read before doing so. Providing legal advice on what LGPL-2.1 permits is outside the scope of this article, but the licence file is short and explicit.

The repository root lists three submodule pointers: fex, box64 and wine. Those point to the upstream emulator and Wine codebases at specific commit hashes rather than carrying full copies. A build from source pulls each submodule at the commit pinned in .gitmodules. Staying current means updating submodules when upstream emulator releases arrive, which is a maintenance cost that grows with the gap between updates.

The repository is not archived. The .github/ directory at the top level holds CI and workflow configuration. Both docs/ and benchmarks/ sit at the top level as separate directories, with benchmarks/readme.md being where the performance comparisons referenced in the README live.

Editorial conclusion

Hangover fits ARM64 Linux users who need to run a specific x86_64 or i386 Windows application where no native alternative exists. Install from the Debian or Ubuntu .deb packages on the GitHub releases page. Before relying on DirectX applications, verify the hardware supports Vulkan 1.3, since that is the floor for DXVK. If the default emulator fails for a specific application, try switching HODLL or HODLL64 to an alternative DLL. PPC64le and QEMU support are gone, and RISC-V lives on a separate branch. The LGPL-2.1 licence applies to any modified build you distribute.

Frequently asked questions

Official sources

1. AndreRH/hangover on GitHub
2. Issues
3. License: LGPL-2.1
4. README
5. Releases