Wine Developers Release Hangover Alpha To Run Windows x86_64 Programs On 64-Bit ARM

[phoronix]

Phoronix: Wine Developers Release Hangover Alpha To Run Windows x86_64 Programs On 64-Bit ARM

Wine developers André Hentschel and Stefan Dösinger have been working on "Hangover" as a means of running Windows x86/x86_64 applications on 64-bit ARM (AArch64) Linux and Android or even Windows for ARM. They are out today with the project's first alpha release...

http://www.phoronix.com/scan.php?page=news_item&px=Hangover-0.4-Alpha-Released

[schmidtbag]

I imagine it'd be easier to just use something like qemu-i386-static to install the x86 version of Wine itself. Though, maybe that would be slower.

[artivision]

OglES should have used from the start. Now they seem like they never went to school. I hope they will find something of use to do on this department.

[microcode]

I imagine it'd be easier to just use something like qemu-i386-static to install the x86 version of Wine itself. Though, maybe that would be slower

Yes, they mention that. They say "The DirectX 9 SDK samples run fairly well because they contain little logic of their own and just call out of the VM into D3D, so all the heavy lifting is done natively.", so there seems to be a big advantage when they call into actual native AArch64 code.

QEMU has a long way to go in terms of performance, it seems that basically everyone who has built a similar JIT in recent times has made something faster than QEMU. QEMU is very portable, but I think there's a lot about dynamic binary translation which is not portable.

[ssokolow]

What do you mean, for example?

Probably to do with explicitly leveraging the similarities between the source and target architectures and actively tuning the binary translation code with the differences in mind and how compilers use them in practice... not to mention minimizing the amount of abstraction that needs to be traversed between input and output sides in a JIT translation as opposed to an AOT translation.

[SteamPunker]

I wonder how many Windows games supported by Hangover would run on a Raspberry Pi 3. It wouldn't be nearly as fast as the Nvidia Shield that one of the developers tried this on, but since it has a 64-bit ARM CPU it should work, at least with games that can run with less than 1GB of RAM.

This is a good example of a project of which the usefulness may not yet be obvious to many people, but which will grow in importance as ARM-based laptops become more popular.

Quoting an interesting part of the README on the Hangover project page on GitHub:

9) Porting to other host architectures
Porting to little endian host architectures should be fairly simple. You will have to replace a few bits of host specific assembler code, the most complicated one is the vararg forward code in dlls/include/va_helper_impl.h. The compiler will make you aware of other places through #error statements in ifdef guards.

This might be particularly interesting to users and developers who use POWER9-based systems from Raptor CS, such as Talos II and Blackbird. According to this tweet from Raptor CS, their systems should be capable of running both little-endian and big-endian VMs, side by side on the same host even. The possibility of running popular Windows games, even more modern 64-bit ones, on such different yet powerful and fully open desktop architectures, might suddently make them a lot more compelling to potential buyers. Also, I really wonder what kind of performance can be squeezed out of a well-optimized POWER9 port of Hangover. We'll see.

[oiaohm]

https://github.com/AndreRH/hangover/blob/master/README

6) 32 bit guest support
The host Wine is always built as a 64 bit application. Hangover handles 32 bit applications by translating structures passed between the application and Wine. The code doing this is hand written because the thunks have to understand in which situation a pointer is valid and in which situation it could point to a random address and should be ignored, and how to handle writes to resulting structures in case of errors etc. The LLP64 model of Windows keeps most structures compatible between 32 and 64 bit, but translating is still a big effort. 9) Porting to other host architectures
Porting to little endian host architectures should be fairly simple. You will have to replace a few bits of host specific assembler code, the most complicated one is the vararg forward code in dlls/include/va_helper_impl.h. The compiler will make you aware of other places through #error statements in ifdef guards.

These to bits from the read me makes me think. You know the Linux distributions that do 64 bit only x86. Port to 64 bit x86 add qemu/kvm support for 32 bit/16 bit support.

One less thing preventing building a Linux kernel 64 bit kernel without 32 bit syscalls.

[ElectricPrism]

Cool, I can't wait to play StarCraft Remastered / BroodWar on a ARM tablet or similar.

[toxicdragon]

So, would this analogously be possible for ppc64le architecture? I'm thinking of Talos II / Blackbird PowerPC configurations that sport the needed power...

[rene]

I imagine it'd be easier to just use something like qemu-i386-static to install the x86 version of Wine itself. Though, maybe that would be slower.

much slower, as you would have a whole system and all of Wine running emulated as well, ..!