Wine project developers Stefan Dösinger and André Hentschel have made the announcement of the first public version of the Hangover emulator, which allows running 32-bit and 64-bit Windows applications designed for x86 and x86_64 architectures in Linux and Android environments based on the ARM64 (Aarch64) architecture.
Unlike running Wine with minimal system environment using QEMU in emulation mode at the system call level (using the same kernel as the main system).
About the Hangover emulator
The project Hangover allows the user to be able to have a significantly higher performance. The acceleration of this project is achieved by transferring the emulation layer to the Win32 / Win64 API level, instead of emulating regular system calls with Win32 / Win64 API post emulation based on them.
Currently, the project allows the user to run only simple applications and games that use the Win64 and Win32 APIs.
For Linux, support for Direct3D has been implemented, which is not yet available for Android due to incomplete support for OpenGL ES in Wine.
Debugger support is non-existent and exception handling has known bugs. Due to these reasons, the copy protection and anti-cheat systems are likely to be in worse shape than in the regular versions of Wine.
In general, 64-bit applications can be expected to be in better shape than 32-bit applications because no data structure of any kind is required.
To guarantee the work, a regular installation of Wine is used, supplemented with various libraries and DLL layers.
In a Linux environment, Windows applications run automatically when QEMU is in the Wine directory ("C: \ x86 \ qemu-x86_64.exe.so").
Whereas, on Android, it is proposed to use the cmd utility to perform the execution.
Address space is limited to 4GB when reserving each address below 4GB.
Most major Wine libraries are previously loaded above 4GB to keep the above space below 4 GB as free as possible. The downside to this is that starting a new process takes about 2 seconds.
Hangover a Wine for ARM64
Wine sees each process as a 64-bit process, so its WoW64 layer is not active. This will work fine for pure 32-bit or pure 64-bit applications, but will cause problems for mixed applications that expect a distinction between, for example, C: \ windows \ system32 and C: \ windows \ syswow64.
Regarding the release of 32-bit (x86) Windows applications, are processed at the translation level of the structures transmitted between the application and Wine (The LLP64 model on Windows preserves the basic compatibility of frameworks between 32-bit and 64-bit WinAPI).
To run 32-bit Windows applications, 64-bit Wine assemblies are used and each process is first treated as 64-bit.
On the host side, only ARM64 and x86_64 architectures are supported, but the code is unified, allowing the project to be moved to other architectures in byte order from youngest to oldest (little-endian) without much effort.
There is still a lot to polish
Hangover's performance at the moment leaves much to be desired. Since eThe main bottleneck is the performance of the code that QEMU generates.
However, when running on a TV device with Android Nvidia Shield. The performance is sufficient to run games from the 2000s.
Applications tested at Hangover include Notepad ++, ANNO 1602, Age of Wonders, Warhammer 40k: Dawn of War, The Settlers II 10th Anniversary, Prince of Persia 3D, Worms 2, and Worms Armageddon. The DirectX 9 SDK examples also run at acceptable speeds.
The release is based on the Wine 4.0 base code, which is reflected in the Hangover 0.4.0 version number. The emulation layer is based on the QEMU project.