search

AndreRH / hangover

Hangover runs simple Win32 applications on arm64 Linux
GNU Lesser General Public License v2.1
1.26k stars 93 forks source link

Please work with Raptor CS to port this to the POWER9 (ppc64le) architecture #20

Closed volkertb closed 3 years ago

volkertb commented 5 years ago

Wow, what an amazing project! 😃 This will grow in importance as more people start using ARM-based laptops (and possibly desktop systems?).

But there is also another interesting architecture to consider for Hangover: POWER9. This architecture supports both big-endian and little-endian (ppc64le) modes. Since Raptor CS has been offering completely open POWER9-based desktop solutions, particularly their new Blackbird motherboard, which is quite affordable as far as high end desktop systems go, having the possibility to run popular Windows games on such systems would suddenly make them even more compelling to a lot of people.

Would you be wiling to consider porting Hangover to POWER9/ppc64le? Perhaps you could reach out to Raptor CS for cooperation on this? Maybe they'd even be willing to donate development hardware to you for this purpose.

Thank you for considering this and regardless, great work!

madscientist159 commented 3 years ago

@AndreRH Do you know if the Wine developers had specific objections to merging support or if it's just a lack of resources to review / merge?

Regardless, nice job. I'll be checking this out shortly.

volkertb commented 3 years ago

Great work! A big thank you to those who've been working on this. :relaxed:

Would it be a good idea to update the README of this project as well? It still only mentions AArch64 support.

AndreRH commented 3 years ago

@AndreRH Do you know if the Wine developers had specific objections to merging support or if it's just a lack of resources to review / merge?

Regardless, nice job. I'll be checking this out shortly.

@madscientist159 End of August on IRC:

julliard: Andre_H: i really don't want to add an extra platform to maintain at this point

The point is that there are huge changes at Wines core right now (partly as a side-effect of the conversion to PE files) and that the same areas are touched that an architecture-port touches. Which causes the added effort on my side with rebasing PPC64 patches, and would cause extra work on the maintainers side if it would be upstream. I hope that the development on those core parts will cool down in a couple of month to try again upstreaming it. Having improved patches and more users of them until then would increase our chances...

Great work! A big thank you to those who've been working on this. relaxed

Would it be a good idea to update the README of this project as well? It still only mentions AArch64 support.

@volkertb Exactly, will do so soon

madscientist159 commented 3 years ago

@AndreRH If you would like to keep access to the development system for a possible future attempt at upstreaming, that's OK with me, just let me know if that's something that would be of use to you.

Thanks!

AndreRH commented 3 years ago

Definitely, still using it. Also there are improvements to do, e.g. exception handling is in a bad shape.

madscientist159 commented 3 years ago

Sounds good!

ghost commented 3 years ago

I just attempted to run and compile this on Gentoo PPC64LE and it segfaults for me. I am using a 4K page size kernel.

Here is the command I ran after building /home/djames/_dev/hangover/build/wine-host/loader/wine /home/djames/_dev/hangover/build/qemu/x86_64-windows-user/qemu-x86_64.exe.so /home/djames/_dev/hangover/build/wine-guest/programs/cmd/cmd.exe

stefand commented 3 years ago

Try to run wine-guest/programs/notepad/notepad.exe . cmd.exe doeesn't work for me because of an unimplemented ucrtbase.dll thunk.

ghost commented 3 years ago

@stefand That also segfaults.

AndreRH commented 3 years ago

Normally u would run with /home/djames/_dev/hangover/build/wine-host/wine But you could run gdb /home/djames/_dev/hangover/build/wine-host/loader/wine then r /home/djames/_dev/hangover/build/qemu/x86_64-windows-user/qemu-x86_64.exe.so /home/djames/_dev/hangover/build/wine-guest/programs/notepad/notepad.exe and see what gdb tells you

shawnanastasio commented 3 years ago

I'm also receiving segfaults on fedora ppc64le w/ 4k pages. Here's the gdb backtrace from running notepad:

Program received signal SIGSEGV, Segmentation fault.
0x000000007b08fbc8 in IsWow64Process (process=<optimized out>, wow64=0x7bcf4ce8)
    at ../../../../wine/dlls/kernelbase/process.c:962
b962        if (!status) *wow64 = !!pbi;
Missing separate debuginfos, use: dnf debuginfo-install glib2-2.64.6-1.fc32.ppc64le libgcc-10.2.1-5.fc32.ppc64le libstdc++-10.2.1-5.fc32.ppc64le pcre-8.44-1.fc32.ppc64le zlib-1.2.11-21.fc32.ppc64le
(gdb) bt
#0  0x000000007b08fbc8 in IsWow64Process (process=<optimized out>, wow64=0x7bcf4ce8)
    at ../../../../wine/dlls/kernelbase/process.c:962
#1  0x000000007b06e7d0 in DllMain (hinst=<optimized out>, reason=<optimized out>, 
    reserved=<optimized out>) at ../../../../wine/include/winbase.h:3095
#2  0x000000007bc71140 in MODULE_InitDLL (wm=<optimized out>, 
    reason=<optimized out>, lpReserved=0x21fd68)
    at ../../../../wine/dlls/ntdll/loader.c:1334
#3  0x000000007bc7178c in process_attach (wm=0x12530, lpReserved=0x21fd68)
    at ../../../../wine/dlls/ntdll/loader.c:1418
#4  0x000000007bc71594 in process_attach (wm=0x11850, lpReserved=<optimized out>)
    at ../../../../wine/dlls/ntdll/loader.c:1386
#5  0x000000007bc7912c in LdrInitializeThunk (context=0x21fd68, 
    entry=<optimized out>, unknown3=<optimized out>, unknown4=<optimized out>)
    at ../../../../wine/dlls/ntdll/loader.c:1389
#6  0x00003ffff7b41480 in attach_thread (
    entry=0x3ffff71af6f0 <__wine_spec_exe_entry>, arg=0x67fff000, 
    suspend=<optimized out>, relay=0x7b661bd0 <__wine_start_process>)
    at ../../../../wine/dlls/ntdll/unix/signal_powerpc64.c:1238
#7  0x00003ffff7b3f118 in signal_start_thread ()
   from /home/shawnanastasio/opt/hangover/build/wine-host/dlls/ntdll/ntdll.so

It almost looks like the TOC pointer in r2 is being incorrectly calculated, perhaps because one of the thunks isn't properly setting r12 to the address of the target function's entrypoint before calling it? I'll try to do some digging, but if you could point me towards where you think the issue lies, that could speed things up.

AndreRH commented 3 years ago

From your comment it's not clear what you did. Was qemu involved or was that host-wine running host notepad? Which notepad did you run in case qemu was involved? which bitness that notepad was?

Still you could run in build/wine-host: gdb loader/wine then inside gdb: r ../qemu/x86_64-windows-user/qemu-x86_64.exe.so ../wine-guest/programs/notepad/notepad.exe This way you should be able to debug it

If there's an obvious problem you could consider opening a new bug for it.

shawnanastasio commented 3 years ago

Sorry for not being clear. From the hangover root directory, I ran the following:

gdb build/wine-host/loader/wine
(gdb) r build/qemu/x86_64-windows-user/qemu-x86_64.exe.so build/wine-guest/programs/notepad/notepad.exe

This resulted in the backtrace seen above.

It does seem like an issue with the TOC. I'll create a new issue for it.

owlshrimp commented 2 years ago

Hi,

Just checking in so see what the status of this is like. I have noticed that there has still been a small trickle of PE conversion work in wine, so it may not yet be time for another attempt at rebasing and upstreaming?