Closed scottyhardy closed 2 months ago
brandonros
commented
1 year ago Shall we retest this (with or without hangover) now that M1 has been out longer?
https://gigazine.net/gsc_news/en/20220607-create-macos-linux-virtual-machines/
I think this might help?
scottyhardy
commented
1 year ago Might be worth a try with Ventura or perhaps an M2 Mac when released. Qemu was the main sticking point as far as I can tell though so I'm not gonna hold my breath.
brandonros
commented
1 year ago I'm down to retry what we tried before now that about 6 months have passed (from when we last tried in December, 2021)
I'm sure some fixes have been made in Docker on Mac OS X by now. It's 4.9.0
What shall I try? docker pull what version of your docker-wine and what exact command line to try to run Notepad++?
brandonros
commented
1 year ago What's the benefit of using hangover if we can just run wine amd64 (on arm64 processor) and let Mac OS/Docker handle the virtualization part? Was the intention performance workaround or something?
stefand
commented
1 year ago The intention was three fold:
1) Sometimes there is no host system able to take care of the emulation. Most notably graphics drivers for ARM systems might not have a x86 userspace version plus the ability to talk to their ARM kernel counterpart
2) Some speed gain of pulling code out of emulation, and figuring out how much it matters. Again, graphics drivers and graphics/sound codecs are the big ones
3) We originally approached hangover as x86-windows on arm-windows, where using Wine as the implementation of "arm-windows" was just an accident. This was before Microsoft's x86-on-arm64 emulation was publicly announced. Now in practice we never ran hangover on ARM windows, and for a few reasons it would not work as is.
You might have noticed the lack of activity on hangover in the past year or more. Wine is currently undergoing big restructuring that will make it possible to include a CPU emulator similarly to how it works on Windows. The big goal here is to run 32 bit Windows programs in a 64 bit Linux process, eliminating the need for 32 bit Linux libs, but it will also make x86 or x86_64 on arm64 much easier. It has actually progressed enough to write a "hangover 2" in the form of a xtajit.dll that works in conjunction with wow64.dll like their windows counterparts. That should eliminate the need for all those thunking DLLs since Wine is / will be able to do the thunking itself.
scottyhardy
commented
1 year ago @brandonros here's what we tried and why:
I suspect very little has changed with Rosetta 2's QEMU - I think trying out Ventura's implementation or M2 when released would be more prudent but I'd be very surprised if it actually works.
To test each version:
./docker-wine wine notepad./docker-wine --arm64 wine notepad./docker-wine --tag=hangover wine notepadbrandonros
commented
1 year ago @scottyhardy
do you want to push a fresher arm64?
scottyhardy
commented
1 year ago The arm64 builds have been failing for months and I hadn't bothered fixing it since it has a limited use case. Just try the latest version in the repo for now and I'll take a look at why the builds have been failing later. Right now I'm trying to get box86 and box64 up and running
brandonros
commented
1 year ago Just try the latest version in the repo for now
to clarify, try the x86_64 latest tag and let docker do the x86_64 -> arm64 translation?
brandonros
commented
1 year ago 
Not sure if you want to close this, Notepad++ runs fine?
Problems Description
I'm trying out using Hangover for my own little docker-wine project. In particular, I've been looking at alternatives for Apple M1 Macs as using the current x86 (linux/amd64) docker image fails with a segfault when trying to run anything at all (see https://github.com/scottyhardy/docker-wine/issues/109).
I myself have an Intel Mac so I've been getting assistance with testing from @brandonros. The issues we're seeing appear to be related to Docker Desktop for Mac's QEMU implementation used to emulate an x86_64 processor on ARM hardware. My first attempt was to build Wine from source code which worked, but overall was a failure as other than running notepad and other built-in apps there weren't any readily available 64-bit Windows binaries compiled for ARM.
So, the thought is that if we use a native ARM image with a newer/better version of QEMU it could solve our problem, which is when I came across Hangover.
In short, I've successfully built hangover using
Dockerfile.cross_arm64(see https://github.com/scottyhardy/docker-wine/pull/139), then I tar the entire/root/hangoversource and build files and useADDto untar the lot into/usr/local/lib/hangoverwithin a Dockerfile that includes all the other packages I normally use in my docker-wine image.build_hangover_for_arm:
Dockerfile.build_from_source (minus parts in original for building wine from source code):
The base image
scottyhardy/docker-remote-desktop:latestusesubuntu:latestfor it's base, which is currently Ubuntu 20.04 focal.I can successfully run
wine notepadwhich is my normal test to confirm wine is working, but I'm getting errors when I attempt to run a copy of notepad++ portable (tested with both 32-bit and 64-bit versions):Here's a more detailed log, using a fresh install where I hadn't already initialised the wine config by running normal notepad:
EDIT: I have no issues running the same commands on my normal x86 image (which just downloads package from winehq) and Notepad++ just runs:
I'm guessing the issue relates to the error
00d4:err:secur32:SECUR32_initSchannelSP TLS library not found, SSL connections will fail. I've seen a similar error whenwinbindisn't installed, but that isn't the case here. I've tried installing pretty much every TLS related package I can find but that hasn't resolved my issue.This could also be related to the fact I'm using an ARM image on an Intel Mac, so there's first Docker's QEMU then Hangover's QEMU being run, but I'm not seeing segment faults like I normally see when problems related to QEMU occur.
Any ideas? Although
wine notepadworks, I don't want to merge this into my master branch until I can at least get one of the programs listed to work on your readme to also work for me.