search

Gcenx / macOS_Wine_builds

Official Winehq macOS Packages
461 stars 23 forks source link

Setting crypt32 DLL to builtin-then-native crashes wine-stable 6.0.1? #28

Closed AgentRG closed 2 years ago

AgentRG commented 2 years ago

Hey @Gcenx . I'm maintaining a guide on how to install Star Wars: The Old Republic using Wine. Recently, WineHQ's wine-stable version 5.0 cert has expired, so Homebrew won't install the "official" Wine anymore. Luckily, I have used your builds a couple of months ago when working with Catalina, so I know your reputation precedes you. Unfortunately, I seem to have ran into an issue with the latest wine-stable. By the looks of it, changing a DLL in winecfg to builtin-then-native seems to crashing the application. Here is the backtrace file generated by Wine. backtrace.txt

Is it possible this is happening because the prefix gets created in win64? (WINEARCH=win64 WINEPREFIX=~/"SWTOR" wine wineboot). It was working great with wine-stable 5.0, so it's just something new that I have to figure out with 6.0.1.

If you don't know what might be causing this, could you give some pointers to figuring out the problem?

PS: Running on macOS Mojave

Gcenx commented 2 years ago

This might be something with secur32 not using gnutls backend by default on macOS until wine-6.11 https://github.com/wine-mirror/wine/commit/4940d2ada276a5c6e9f855177ef54ce23490d36e, have you attempted to instead use wine-6.18?, if it's just secur32 that's the issue I could try to use the listed commit to force it to use gntuls.

It should be possible to install the wine-stable package using the following package;

brew install --cask --no-quarantine wine-stable

Might need to manually XQuartz as it didn't seem to install XQuartz.app into /Applications/Utilities/ when I tested this, you could manually install it if needed.

AgentRG commented 2 years ago

Running the staging version indeed worked. The launcher launched successfully under wine-6.18.

Screen Shot 2021-10-03 at 7 45 50 PM

Using --no-quarantine sadly doesn't stop the expired certificate from being ignored by Homebrew. It will tell the user to use -allowUntrusted instead, and then again throw Error: ambiguous option: -allowUntrusted when using said argument. Disabling Gatekeeper entirely will still throw the same cert error for the current official cask of Wine.

No idea what keeps you going supporting Wine on Mac, but know there are people on the sidelines cheering you on. I'll go ahead and close the issue since it's resolved.

PS: If possible, please let me know if you make the change to wine-stable to force to use gntuls.

Gcenx commented 2 years ago

I’m happy to see it’s now working by for you, usually you should try using devel before staging as it’s simpler to cherry pick commits.

The option brew mentioned doesn’t have a command line option it accepts from what I’m reading of there documentation, this needs to be added into the cask .rb but that’s not accepted in official brew casks. Not sure how useful a third-party tap providing the depreciated Winehq packages would be though….

I use macOS as my daily driver so having a usable version of wine is ideal to avoid Windows. Any support is appreciated and hopefully we’ll be done working on the “official” Winehq macOS packages soon.

I’ve added the secur32 patch from upstream to https://github.com/Gcenx/macports-wine/commit/d3898c3d59ec9f7bc2e41f8d129ac785b1a19a30 however it need to test the build to verify this was the cause. But that patch is still desirable anyway to avoid the dead macOS code paths within wine.