Catalina and the future of Wine on Mac

Questions about Wine on macOS.
Maximara
Level 2
Level 2
Posts: 14
Joined: Wed Jun 26, 2019 8:01 am

Re: Catalina and the future of Wine on Mac

Post by Maximara » Fri Nov 13, 2020 10:27 pm

Well the ARM Macs are here. Now what? Is Wine effectively dead on those Macs or will some form of x86 emulator/translator have to be included in the package? (I'm assuming ARM on Windows is a no go for licensing reasons)

Gcenx
Level 6
Level 6
Posts: 565
Joined: Mon Dec 25, 2017 12:11 pm

Re: Catalina and the future of Wine on Mac

Post by Gcenx » Sat Nov 14, 2020 8:42 am

Your asking on the forums you’d be better asking this question via the mailing list so wine developers can see the question.

CodeWeavers are still working on Apple silicon support but can’t really make too much more progress until they have an actual M1 system as the DTK is different. So expect an update to crossover sometime after release that supports Apple Silicon.

As for Winehq releases they haven’t competed the PE transition that needs to be completed before even attempting to deal with crating spec files for the reanimating items that need to be trunked without requiring a custom compiler

Maximara
Level 2
Level 2
Posts: 14
Joined: Wed Jun 26, 2019 8:01 am

Re: Catalina and the future of Wine on Mac

Post by Maximara » Thu Nov 19, 2020 12:07 am

CrossOver Allows x86 Windows Apps to Run on Apple M1 Macs. Hopefully what they are doing gets passed to the open source community. Surprised it was this fast though.

Gcenx
Level 6
Level 6
Posts: 565
Joined: Mon Dec 25, 2017 12:11 pm

Re: Catalina and the future of Wine on Mac

Post by Gcenx » Thu Nov 19, 2020 12:12 pm

Maximara wrote:
Thu Nov 19, 2020 12:07 am
CrossOver Allows x86 Windows Apps to Run on Apple M1 Macs. Hopefully what they are doing gets passed to the open source community. Surprised it was this fast though.
The reason this functions is due to wine32on64 is being used via Rosetta2.

As for wine32on64 Julliard won’t allow the current patches into upstream wine as it’s considered a hack and requires a custom compiler, maybe after the elf > pe transition is complete where a custom compiler is no longer required but a .spec file.
But I’d guess by the time that completed Apple will drop Rosetta2

TECH198
Level 1
Level 1
Posts: 8
Joined: Tue Aug 23, 2016 11:54 am

Re: Catalina and the future of Wine on Mac

Post by TECH198 » Mon Dec 28, 2020 11:24 pm

What strikes me as odd no "32-bit code on Catalina".. However newer wine engines CX19.0.1 work just fine (PortyingKit for instance...)

i've often many older games pre-2006 to work no problem, but not one spefiic one Prey (2006)..

It's a Wine engine issue, so what makes older engines incompatible with Catalina exactly ? The game in question cannot be so unique, it just can't run, yet older games before 2006 i'm just fine.. I'm trying to pinpoint, why it doesn't work, when i believe it should.

Gcenx
Level 6
Level 6
Posts: 565
Joined: Mon Dec 25, 2017 12:11 pm

Re: Catalina and the future of Wine on Mac

Post by Gcenx » Tue Dec 29, 2020 12:04 am

TECH198 wrote:
Mon Dec 28, 2020 11:24 pm
What strikes me as odd no "32-bit code on Catalina".. However newer wine engines CX19.0.1 work just fine (PortyingKit for instance...)

i've often many older games pre-2006 to work no problem, but not one spefiic one Prey (2006)..

It's a Wine engine issue, so what makes older engines incompatible with Catalina exactly ? The game in question cannot be so unique, it just can't run, yet older games before 2006 i'm just fine.. I'm trying to pinpoint, why it doesn't work, when i believe it should.
Upstream wine doesn’t run on macOS Catalina and later due to Apple no longer providing 32Bit libraries and setting 32Bit code execution to disabled by default. (Can be enabled with a kernel boot arg but not much point)

The reason PortingKit/Wineskin function on macOS Catalina and greater is I provide a custom wine built from crossover-wine-19.

Currently the patches used to get this working are blocked from being merged into upstream as there considered a hack. (Requires a custom version of llvm/clang to build)

TECH198
Level 1
Level 1
Posts: 8
Joined: Tue Aug 23, 2016 11:54 am

Re: Catalina and the future of Wine on Mac

Post by TECH198 » Tue Dec 29, 2020 12:49 am

So, really the same reason for ALL patches equal a hack is actually the problem.... It goes deeper than that

'Depends on how its used' factors in too. And this is for the good. not for the bad. Its just more convenient to not go between the trees

a patch used for good, is still good. and is not a hack by any means if its restricted to the developers only.

After most of the DLL's are fake in Wine,, ? Would hat also be a hack Wine developers approved of by the way.. There is no difference here either,

Gcenx
Level 6
Level 6
Posts: 565
Joined: Mon Dec 25, 2017 12:11 pm

Re: Catalina and the future of Wine on Mac

Post by Gcenx » Tue Dec 29, 2020 10:26 am

TECH198 wrote:
Tue Dec 29, 2020 12:49 am
So, really the same reason for ALL patches equal a hack is actually the problem.... It goes deeper than that

'Depends on how its used' factors in too. And this is for the good. not for the bad. Its just more convenient to not go between the trees

a patch used for good, is still good. and is not a hack by any means if its restricted to the developers only.

After most of the DLL's are fake in Wine,, ? Would hat also be a hack Wine developers approved of by the way.. There is no difference here either,
It doesn't depend on how its used as HACKS don't be added into upstream wine these get stuck in Staging.

Wine implements Windows api calls on top of Unix. So while technically you "could" consider the entire wine project a large "HACK" you need to keep in mind that it's possible to compile WineD3D for example and use that on Windows.

Everyone is free to contact Julliard and ask him to explain his stance on these things, would I like to see the patches in upstream wine already?, of course I have the infrastructure already in place to build wine32on64 with all possible options and would be more than happy to open as many bug reports as needed for incompatible or broken features.

There's not many wine maintainers that own or have access to a mac, most are on Linux and while it's possible to cross-compile wine for macOS that doesn't mean they'll be able to test it. Some commits have compiled without issue but wine failed to function and this was macOS specific.

The current state of 32on64 would cause a huge headache for wine maintainers since to build it you're forced to ignore build errors (multiple build errors even for normal builds), multiple internal functions need to be changed to special versions that change depending on the arch that's being compiled etc.

Post Reply