Open scottyhardy opened 2 years ago
is it pushed and ready to retest?
it is.
docker run -it \
--rm \
--hostname="$(hostname)" \
--env="RDP_SERVER=yes" \
--publish="3389:3389/tcp" \
--platform=linux/arm64 \
--pull always \
scottyhardy/docker-wine:hangover-arm64 \
/bin/bash
$PATH isn't working but $ /usr/local/lib/hangover/build/wine-host/loader/wine notepad
is
wineuser@Brandons-MacBook-Air:~$ echo $PATH
/sbin:/bin:/usr/bin:/usr/local/bin
wineuser@Brandons-MacBook-Air:~$ /usr/local/lib/hangover/build/wine-host/loader/wine ~/Downloads/WinOLS_Testversion.64Bit.exe
00d8:err:process:NtCreateUserProcess L"\\??\\Z:\\home\\wineuser\\Downloads\\WinOLS_Testversion.64Bit.exe" not supported on this installation (x86 binary)
starting L"Z:\\home\\wineuser\\Downloads\\WinOLS_Testversion.64Bit.exe" binary with Hangover
00e8:err:hangover:fatal_string Hangover failed: You need to set HOQEMU
wineuser@Brandons-MacBook-Air:~$ echo $HOQEMU
wineuser@Brandons-MacBook-Air:~$ export HOQEMU="/usr/local/lib/hangover/build/qemu/x86_64-windows-user/qemu-x86_64.exe.so"
wineuser@Brandons-MacBook-Air:~$ /usr/local/lib/hangover/build/wine-host/loader/wine ~/Downloads/WinOLS_Testversion.64Bit.exe
starting L"/home/wineuser/Downloads/WinOLS_Testversion.64Bit.exe" with Hangover
0108:err:secur32:SECUR32_initSchannelSP TLS library not found, SSL connections will fail
32 bit environment set up, Large Address Aware: NO.
0108:fixme:qemu_module:import_dll No implementation for ucrtbase.dll.__stdio_common_vswprintf_s imported from L"C:\\windows\\system32\\oleaut32.dll", setting to 0xffffbea64875
0108:fixme:qemu_ntdll:qemu_RtlAddVectoredExceptionHandler Unverified!
0108:fixme:qemu_user32:qemu_GetKeyboardType Unverified!
0108:fixme:qemu_kernel32:qemu_SetDefaultDllDirectories Unverified!
0108:fixme:qemu_kernel32:qemu_SetProcessDEPPolicy Unverified!
0108:fixme:qemu_kernel32:qemu_GetUserDefaultUILanguage Unverified!
0108:err:process:NtCreateUserProcess L"\\??\\C:\\users\\wineuser\\Temp\\is-MVHAM.tmp\\WinOLS_Testversion.64Bit.tmp" not supported on this installation (x86 binary)
starting L"C:\\users\\wineuser\\Temp\\is-MVHAM.tmp\\WinOLS_Testversion.64Bit.tmp" binary with Hangover
wineuser@Brandons-MacBook-Air:~$ Failed to load "C:\users\wineuser\Temp\is-MVHAM.tmp\WinOLS_Testversion.64Bit.tmp", last error 126.
It was worth a shot. :P
@brandonros yeah, that's disappointing. I was really hoping Hangover was going to be the silver bullet, but it is still very early alpha. There's a chance there's also an issue with my build so I'll have a go at replicating some of the programs listed on the hangover readme.
Another option is Crossover: https://www.codeweavers.com/crossover/. It's a paid product, but they also allow open source builds. I'm thinking of giving this a go next, but you may want to give their free trial a go to see if it runs your program?
Hilariously, I set up Windows 11 with Parallels as per your suggestion (I guess I tried it too early when M1 first came out/before Windows 11 arm64 builds were floating around).
It worked flawlessly. Well... pretty sluggish but I'll ignore that.
I went to run the specific program I am trying to run and... it's anti-cheat "debugging detected" kicked off, closing immediately with an error. lol
I guess the x86_64 on arm64, even at the OS level, comes off as if it is using a debugger?
I'm looking forward to future versions of Docker Engine on Mac OS X hopefully bundling a newer version of qemu
so that wine notepad
doesn't error out.
Super grateful for all of your help. You and I should work on something else together. Got any other ideas? :)
Maybe you and I pair to make https://github.com/iximiuz/docker-to-linux work? Build the Dockerfile
into a QEMU operating system qcow2
image, remove the Docker daemon from the equation.
Yeah I've had fun trying to solve this issue - it's annoying not having an M1 Mac for testing but it's been great getting your feedback. I'd originally written off getting docker-wine to work on the new ARM CPUs, so even though it still failed for your use case at least I've got some options for other users to play with. I'll update the doco at some point to explain the various versions and their limitations plus give a breakdown of all the different tags in use now, so thanks heaps for your help!
As for the docker-to-linux project, I'm not exactly seeing it as a viable alternative since it'll still need to be an ARM VM using qemu for x86 emulation and it's this emulation layer where we're hitting walls. Also, if you were wanting to automate the building of VM images, I'd just go with Hashicorp Packer and instantiate with Vagrant or something similar.
If you come up with any more interesting ideas though, I'm happy to give it a go in my spare time 😃
As for the docker-to-linux project, I'm not exactly seeing it as a viable alternative since it'll still need to be an ARM VM using qemu for x86 emulation and it's this emulation layer where we're hitting walls.
I would say I slightly disagree. I think the wall we are hitting is Docker's use of qemu
(obviously some kind of bug). When I was playing around with it, the image docker-to-linux
spat out worked very well. It was the image itself that had some issues, not the qemu
part failing like it does in Docker randomly.
What do you think?
I agree qemu is the key. Docker to Linux seems interesting so I'll have to have a play with it before I make further judgement.
Hey, is there any development or plans to finish this feature?
I am trying to run x86 windows binaries on an Nvidia jetson and thought this could be an option. Currently running into the same segmentation fault error I saw in another issue.
In relation to issue #109 - I'm using the hangover project to bridge the gap for ARM based Macs and other devices, so they can run a native ARM (arm64) docker image that is able to run x86 Intel (amd64) Windows binaries.