The Wine program for running Windows games/applications on Linux and other platforms can run on a number of different architectures, but Wine doesn’t handle the emulation of running Windows x86/x64 binaries on other architectures like 64-bit ARM or PowerPC. But that’s what the Wine-based Hangover is about with currently allowing those conventional Windows binaries to run on AArch64 (ARM64) and 64-bit POWER too.
Hangover started out with a focus on Windows x64 binaries on ARM64 in looking at the possible use-case of running Windows software on ARM mobile devices and more. This year with the help of Raptor Computing Systems there has been Hangover support added for IBM POWER 64-bit.
It would be really amazing if Linux on POWER could make use of WINE like regular x86 Linux users can. It’s a long way off, still, but progress is being made.
Thom Holwerda,
Do you know that for sure or is that an assumption?
I see a lot of posts suggesting running wine from an emulated x86 linux environment on ARM, which has been possible for a long time. Granted, full system emulation is not quite the same thing, but it makes me wonder if qemu’s user mode emulation works with wine/win32 binaries? It’s trivial to run x86-64 binaries on ARM assuming the needed dependencies are available (the x86-64 binaries need x86-64 libraries) – I did it just now on an odroid ARM server and it just worked. It’s possible windows applications would work this way as well although I’ve never had any reason to, has anyone else tried?
I downloaded the source off github since I was curious what changes he had made but it looks like most of the directories are missing. It looks like he’s invoking qemu from wine rather than wine from qemu. That’s a weird approach and it seems more complex to try and do it that way. I wish he were here to discuss his choices.
https://wiki.winehq.org/Emulation
This is where hangover starts.
>> Granted, full system emulation is not quite the same thing, but it makes me wonder if qemu’s user mode emulation works with wine/win32 binaries?
Yes qemu’s user mode emulation does but its not without it issues. Using qemu usermode you end up needing a full system in the user mode so not small and not that performing.
>> It looks like he’s invoking qemu from wine rather than wine from qemu. That’s a weird approach and it seems more complex to try and do it that way. I wish he were here to discuss his choices.
The link above kind of covers it. The hangover route is faster than the normal qemu usermode as you are jumping out to user mode to native mode a lot sooner. So you have less emulation over head. You don’t need like a full copy of glibc/mesa/samba… in the qemu usermode part so this makes hangover route lot more disc effective. When you add up wine dependency list for what you need to put in qemu user mode so wine fully works things get insane.
Hangover route basically does make sense even that its not that simple todo. Heck with Linux distributions wanting to get rid of 32 bit binaries wine thunking from 32 bit to 64 bit that hangover is doing could come very useful there as well so that drivers can be all left to distribution.
oiaohm,
That is wrong. With user mode emulation you just need the binary’s dependencies and not a full system. Don’t take my word for it, you can test this yourself by copying just an x86 binary and it’s dependencies. You COULD provide all those dependencies with a full system, but it’s not needed.
Thanks for the link. It’s certainly a different approach and I’d honestly like to see a benchmark if you’ve got one. I’m not sure why you’re mentioning things like samba? It’s unusual for programs (either windows or linux based) to depend on samba. Regardless, emulating the dependencies in their native instruction sets might incur some overhead, but performance isn’t everything and the more direct QEMU approach can provide some immediate benefits. It does not require that you first port the dependencies before you can run x86 binaries on ARM and you can run foreign binaries for which you don’t have source code (which might be significant for windows software). If you had the source code and it’s worth the effort to port the dependencies, then you’d be better off porting the executable all together and forgoing the use of QEMU at all. It seems that hangover’s approach is to port dependencies from the wine source, which is is the best they can do, but another con of that approach is that porting software to a new architecture potentially introduces more bugs and maintenance burden than just emulating already working code as is. The point being while x86 emulation may be slow, it may be more important to a user that the code runs correctly. Consider that niche software has a significantly better chance of running correctly under windows emulation than under wine even though wine is faster and doesn’t use emulation.
I don’t say this to put down the project in any way, but just to provide a different perspective.
I gave it a quick try on my Blackbird and it works. Not always, not for all binaries I tested, but far better than I thought it would be working: http://vivapowerpc.eu/20201102-2130_Hangover
Apparently macOS support is in the works too.
I guess that might be useful in the near future