Support of the next version of macOS

[qparis]

This is a memo to find a solution so that our wine builds work for 32bits programs in the next version of macOS.

It seems that there are no official solutions yet. If have tried use this repository https://github.com/AndreRH/hangover. By tweaking a little bit their solution, I'm able to cross compile it but I'm unable to run binaries (A lot of DLLs are missing)

[Gcenx]

It’s able to build everything using that’s version of clang it will really help, I know it’s a pain but having it pre-built will save time when rebuilding but the environment.

If it’s not possible to get it fully working then just build it and we’ll use it for building wine only (not ideal but it’s better then nothing)

I’ll definitely get the WineCX repository update today as I have it ready offline.

Do you have discord/reddit/hangouts somewhere we can ensure is a private conversation?

[qparis]

I have not but I can subscribe. You can also contact me on whatever social network / whatsapp / mail or Slack

Up to you :)

[Gcenx]

@qparis winecx-19.0.0 is now committed and release is marked.

Not sure if you've had any luck with llvm/clang so I’ve left updating the other components alone for now.

[Gcenx]

Really don’t feel like making another issue for this since it’s related.

In regards to building wine32on64, I’m not sure how it will be handled within Phoenicis.

I’ve built CrossOver19 in the following configurations;

• macOS Catalina wine32on64
• macOS Catalina wow64 (wine32on64/wine64)
• macOS 10.8 & macOS Catalina (wine/wine32on64)
• macOS 10.8 & macOS Catalina wow64 (wine/wine32on64/wine64)

The advantages of being macOS Catalina only is you still have a “wine” executable (64Bit) along with wine32on64 so no real backend changes would be required.

Now for a mixed build, you will have a 32Bit “wine” executables and wine32on64 executable so on macOS Catalina it would require wine32on64 to be used.

The mixed builds size can be reduced bundle linking all PE executables from /lib into /lib32on64, I’m sure we check this in some manner, I’ve done the quick option of only making symlinks from /lib/wine .dll/.exe I rock /lib32on64/wine

[qparis]

Hm I don’t know yet how we are going to handle it but we have three solution:

• A mixed build that is seen as a 32bit build by phoenicis ; and that detects what operating system is running when started
• A mixed build that is seen as a 32on64 (new kind of architecture) by Phoenicis ; the OS detection and architecture compat mapping is done by phoenicis - this was my initial plan
• The same but with a 32on64 only build.

What solution would you suggest?

Concerning clang ; I’m still on it but it’s giving me hard time. How did you compile it?

[Gcenx]

As I’m providing then Engines for use in Wineskin/PortingKit I’ll be providing mixed engines to cover as many uses as possible and to save on storage space.

For llvm/clang I’d only build llvm/clang so merged then together as required and built into an Xcode toolchain using ninja to speed up then compile, ignoring all the failed tests.

[qparis]

Then let’s go for mixed engine. Do you think that phoenicis could cover portingkit/wine skin features?

[Gcenx]

Currently it doesn’t, Wineskin/PortingKit output app bundles that includes everything and on launch it’s loads the selected application.

But I guess the you could add app building if you wanted

[plata]

Not exactly sure how you do it but I'm pretty confident that it could be implemented as scripts.

[qparis]

This could be done ; in fact this has been done before with POMv2.5

I think it would be a great feature to support

[Gcenx]

Oh I wasn’t aware that’s POM ever had that feature previously.

I’m assuming it would be simpler to make a script to convert a Bottle/Engine/Selected Executable into an app bundle.

Wineskin handles this different, you first use Winery to select you desired Engine along with using the current master wrapper it builds you a wrapper.

Now you do all your configuration/installation/etc via that wrapper, also provided s a built in winetricks GUI menu and when tournament done select your desired executable + flags.

Wineskin also uses actual winetricks via a GUI wrapper so that saves some additional work.

PortingKit is closer to PlayOnMac in that it uses scripts to automate installations/winetricks/configuration/Engine selection etc, it uses Wineskin as the wine backend for macOS. But it’s much more user friendly then Wineskin.

[plata]

Maybe we should move this discussion to a separate thread? In general it probably makes sense to concentrate forces if several tools have the same goal in my opinion (so that we can achieve the best possible product for our users given the limited developer resources).

[Gcenx]

@plata agreed.

I do have some questions;

• is PlayOnMac signed/notarized?
• Does it already can support launching wine32on64 over wine for macOS Catalina?
• does PlayOnMac launcher wine and a subprocess?

[qparis]

@plata agreed.

I do have some questions;

* is PlayOnMac signed/notarized?

PlayOnMac is signed and will be notarized. I have an Apple Developper account so I can do it without any kind of problem. We have some problem regarding the signature but we know what's going on. POM 4 is not supported on Catalina ; not sure it will be

* Does it already can support launching wine32on65 over wine for macOS Catalina?

No, but that's the whole point of this ticket. We will surely support it

* does PlayOnMac launcher wine and a subprocess?

What do you mean?

[Gcenx]

PlayOnMac is signed and will be notarized. I have an Apple Developper account so I can do it without any kind of problem. We have some problem regarding the signature but we know what's going on. POM 4 is not supported on Catalina ; not sure it will be

So POM5 would include Catalina support?

No, but that's the whole point of this ticket. We will surely support it

I was wondering since I’ve added support for wine32on64 but didn’t provide a build yet, I wanted to verify my own test results when’s using POM to see if the results line up.

What do you mean?

When launching apps you can launch them as a new process or as a subprocess to the launcher, this means any entitlements and permissions etc should be passed on from the main application to the launch application. This mean POM in this case will own all wine processes.

[qparis]

PlayOnMac is signed and will be notarized. I have an Apple Developper account so I can do it without any kind of problem. We have some problem regarding the signature but we know what's going on. POM 4 is not supported on Catalina ; not sure it will be

So POM5 would include Catalina support?

Yep. If POM5 developement is not advanced enough, I will probably repackage POM 4 to support Catalina once we have 32on64 builds

No, but that's the whole point of this ticket. We will surely support it

I was wondering since I’ve added support for wine32on64 but didn’t provide a build yet, I wanted to verify my own test results when’s using POM to see if the results line up.

If the build are universal (ie. we replace wine executable with a script that detects the OS and route the arguments to the right application), this will be transparent for any version of POM

What do you mean?

When launching apps you can launch them as a new process or as a subprocess to the launcher, this means any entitlements and permissions etc should be passed on from the main application to the launch application. This mean POM in this case will own all wine processes.

I wasn't aware that this made a difference but it is very interesting. I think it is a subprocess of the launcher. How could we know?

[Gcenx]

Yep. If POM5 developement is not advanced enough, I will probably repackage POM 4 to support Catalina once we have 32on64 builds

Makes sense.

If the build are universal (ie. we replace wine executable with a script that detects the OS and route the arguments to the right application), this will be transparent for any version of POM

Yeah I tried that and wine64 freaked when finding wine was not a binary, instead I’d added basic detection directly so the correct wine64/wine32on64 or wine binary is called. A wine32on64 build would include a 64Bit “wine” binary burn to make a universal build the “wine” binary needs be the one from a stock 32Bit build.

I wasn't aware that this made a difference but it is very interesting. I think it is a subprocess of the launcher. How could we know?

It didn’t seem then make a difference up-to and including High Sierra but in macOS Mojave it now makes a difference.

If you launch “wine” via PlayOnMac check your running processes you will see “wine” binary will be shown as a subprocess/process of POM. Also on macOS Catalina if a bash script is used it will end up inheriting bash permissions.

[qparis]

Yeah I noticed that for the last point. Technically speaking, how do you differ from creating a sub process and a new process?

[Gcenx]

Technically speaking, how do you differ from creating a sub process and a new process?

This one I’m afraid I cant really help with as I’m not sure myself.

All I’d figure out is the need to use NSTask for the launches (Objective_C on macOS), the how to convert the entire codebase to accomplish that is beyond me.

I’d followed a basic tutorial on NSTask and hard coded “wine explorer” and that’d shown up as a process of “WineskinLauncher”, no environment variables were set or anything.

[plata]

This could be interesting: https://stackoverflow.com/questions/931536/how-do-i-launch-a-completely-independent-process-from-a-java-program. ProcessBuilder (what we use currently) spawns a subprocess according to the docs.

[Gcenx]

I’m currently testing if wine32on64 will build using the current custom build of llvm/clang-7

I haven’t retested my buster changes just yet so it’s still being tested using stretch due to the mingw bug from my last test.

Still need to use a newer version of llvm/clang overall, I’ll make some changes to use one from the llvm repository later if the build succeeds.

[qparis]

Yep, I'm on it :)

[Gcenx]

Not sure how the llvm/clang is coming along on your end but I’m having some annoyances with the mixed build is built, when I’m free again I’ll look into the issue some more and see if it’s just wine that’s affected or also wine32on64

[qparis]

I'm still on it :) Little by little, I am able to build more & more clang components. Not sure how it will work though

[qparis]

Here is a mwine32 clang: https://repository.playonlinux.com/clang8/llvm-8-mwine32-release.tar.gz

Not all the tools are inside, but combined with the images we already have, it should be enough for a first shot

[Gcenx]

I’ll do the basic updated when I get chance for building wine32on64

[lloydgreg]

Hi,

How's progress on this?

[Gcenx]

@lloydgreg its going slowly since my system runs docker like trash.

Outside of docker I’d already built both WineCX19.0.0 & WineCX19.0.1 as mixed Engines.

This means it’s possible to run the same built on OS X 10.8 > macOS Mojave with the stock wine binary on macOS Catalina you would use wine32on64 but SIP needs to be disabled unless the binaries are code signed & notarized

If SIP isn’t disabled or you didn’t code sign & notarize the binaries you’ll get the following error

wine: failed to initialize: failed to set the LDT entry for 32-bit code segment

[gregology]

We appreciate all your work on this 🤗 please let us know if there is any way we can help

[qparis]

@gcenx Can you detail the procedure to build wine32on64? I'll try to do something

[Gcenx]

@qparis

Build winetools using the custom version of clang-8 or everything will fail

Here is the options I’m using to build wine32on64;

--enable-win32on64 --disable-winedbg --without-x --without-vulkan --without-vkd3d --without-gphoto --without-cms --without-gsm --without-gstreamer

I don’t remember if make -k Is really required as the above should disabled all the parts that fail to build

If you can get it to build within docker on your end I’ll explain how to mix the builds, as currently I’m at work and can’t be sure I remember all steps correctly.

[qparis]

So far, I'm getting an error during 32on64 step: ../../../libs/port/fold.c:120:12: error: initializing 'storage32 WCHAR *storage32' (aka 'storage32 unsigned short *storage32') with an expression of type 'unsigned short * ptr64 storage32' changes address space of pointer

[qparis]

Do I need to explicitely set -mwine32 on CFLAGS when building 32on64?

[Gcenx]

@qparis I haven't needed to set -mwine32 on macOS when building setting --enable-win32on64 sets that as needed, winebuild/winegcc will set -m32 for PE files

[qparis]

I have successfully compiled wine32on64, but the binary seems to be a 32bit file: qpmac:bin qparis$ file wine32on64 wine32on64: Mach-O executable i386

any clue?

[Gcenx]

I'm guessing you left in the winebuild wrapper that injects -m32?

If so that would break the build as it should be showing x86_64 for wine32on64

[qparis]

I had -target i686-apple-darwin17 flag left on CC If I replace it with -target x86_64-apple-darwin17 ; now I get another error: /usr/bin/x86_64-w64-mingw32-ld: actxprxy_urlhist_p.cross.o:actxprxy_urlhist_p.c:(.rdata+0x5b0): undefined reference to `IUnknown_AddRef_Proxy'

[qparis]

Seems to be my mistake.

Retrying with something else

[qparis]

Ok, I got wine32on64 compiled. However, when I try to run an app, I get qpmac:bin qparis$ ./wine32on64 /Users/qparis/Downloads/putty.exe wine: Mauvais format EXE pour Z:\Users\qparis\Downloads\putty.exe.

(bad EXE format for putty.exe)

[Gcenx]

If it built correctly it should function could be some cross-compilation weirdness. Here is a working build WineCX19.0.1 you can use the following Runtime

[Gcenx]

@qparis check over the build log I remember seeing an additional injection of -m64 happening within the -mwine32 build.

I think it’s related to -target forcing the triplet -m64 over -mwine32, maybe building osxcross with the custom clang will allow the needed triplet to be used?

[qparis]

You mean that when I'm using -target x86_64-apple-darwin17 ; clang would automatically add -m64 flags which could lead to the current behavior ; is it correct? If so, why building osxcross with this clang version would change?

[qparis]

I think the problems comes from the configure script. If you check out configure.ac ; line 171, you'll see that -mwine32 flags are explicitely disabled when cross compiling is enabled. Trying to disable it

[qparis]

Ok! I think I managed to cross build it

[Gcenx]

You managed to run any 32Bit executables?

[qparis]

Not yet, but I least ; I'm getting the wine: failed to initialize: failed to set the LDT entry for 32-bit code segment error

[Gcenx]

I’d explained this error before you need to disable SIP

[qparis]

Yep. I'm trying to notarize the app to avoid disabling SIP. Would it work?

[Gcenx]

I haven’t done it yet but it should

[qparis]

If so, I'll try to see if we can notarize automatically all our builds