Initial macOS Catalina support

[Gcenx]

On request I've added WineCX19.0.1-1 engines for download earlier than I was planning too.

These function on OS X 10.9 to macOS 10.14 without any changes, however for macOS Catalina 10.15 > 10.15.3 will required SIP to be disabled or wine32on64 will spit out the follow error when launched via terminal.

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

While this isn't ideal it will allow people who don't want to wait or are unable to downgrade to a lower version of macOS two working Engines.

macOS Catalina 10.15.4 changes;

Apple now allows access to i386_set_ldt with SIP enabled, this wasn't previously possible. However keeping SIP enabled will block access multiple user directory’s if permission isn’t granted.

Known wine32on64 bugs;

• Audio skipping (winetricks faudio1906)
• Microphone inaccessible (also happens on CrossOver19.0.1)
• vcrun* verbs from winetricks will fail bug 47564 (I’ll try adding the upstream patch) (Hoping the new version with an upstream patch resolved this issue) *PaulTheTall said only vcrun2015 causes him issue, vcrun2019 can be used in place of vcrun2015

[Alex1844]

Awesome, thanks a lot. I will try it out this evening

[orchidflower]

@Gcenx . Thanks a lot for you hard work! Hope you are getting well. :)

About the BundleID generation, I have a question:

For me , I use a tool "MacGesture" to configure some global mouse gestures for macOS. But I need to disabled it for "wrapped" app to enable mouse right button works correctly. MacGesture can support a blacklist defined by the BundleID of apps, but I noticed that the BundleID is changed every time when I start the "wrapped" app.

Is it possible to disable BundleID generation feauture in "wrapped" app?

Thank you!

[Gcenx]

@orchidflower that’s actually not intentional.

The BundleID should only be changing when the wrappers name is changed to ensure a duplicated wrapper has a unique BundleID.

I’ll make the required changes and test them on my end before updating the Pre-Release with the updated version that should correct this issue.

[rfperuch]

Hello @Gcenx

What's still needed in order to that engine from Crossover work on Catalina without disabling SIP? Sorry if this question is already answered above.

Thank you!

[Gcenx]

@rfperuch currently to run WineCX19+ engines on Catalina if running 10.15.4 then a boot argument can be set in recovery mode allowing SIP to remain enabled see my first comment.

The second way will be having an Apple Developer account and then code-signing and notarizing all of the Engine's binaries to allow it to function without workarounds

[rfperuch]

@Gcenx Are you considering to do the second option?

[Gcenx]

@rfperuch thats the plan, however I don’t currently have an Apple Developers license.

Currently I’d like to resolve as many bugs as possible, I’d inherited a lot from the original project while others were introduced during the codebase modernization/refactor/rebasing

[orchidflower]

@orchidflower that’s actually not intentional.

The BundleID should only be changing when the wrappers name is changed to ensure a duplicated wrapper has a unique BundleID.

I’ll make the required changes and test them on my end before updating the Pre-Release with the updated version that should correct this issue.

I got it. Thanks!

[emendelson]

@Gcenx - Is there any chance you could post a sample application, perhaps something like 32-bit Windows Notepad (or some freeware application) running in a wrapper? If this is a lot of trouble, please ignore it. But I haven't been able figure out how to do anything with the new downloads, probably because I haven't been patient or attentive enough.

[Gcenx]

I've updated the Pre-release files. @orchidflower the newer wrapper should function correctly, I might just disable BundleID generation outside wrapper creation but that could be problematic.

@emendelson download and unpack the files place the unpacked Wineskin-2.9.0.6 into ~/Library/Application Support/Wineskin/Wrapper replacing the current version, it's retains the current versions name to avoid "update" check but its really the newer version internally.

Wineskin Winery should function as normal but allows using the additional example engine types, the Winery won't check for updates however.

Place the Engines into ~/Library/Application Support/Wineskin/Engines so Winery can find them, these -no-wine variants will only function using the Pre-release version of Winery

[emendelson]

@Gcenx - Thank you for this. I did exactly as you said. Question: does system protection need to e turned off? I don't have it turned off, and every attempt I make to create a wrapper produces an error message that says the new blank wrapper is damaged and can't be opened. I think that SIP needs to be turned off, but I haven't found any explicit statement about it. Will turn it off later and try again...

[Gcenx]

@emendelson sounds like your using the wrong version of Winery, you need to use the version provided under Pre-releases section or the -no-wine Engines will be considered corrupted

I have SIP enabled for the moment and it’s working just fine, having SIP disabled is no longer a requirement unless on Catalina 10.15.3 or lower, Catalina 10.15.4 only needs a boot-arg set now but that’s only required for wine32on64

[rfperuch]

@Gcenx @emendelson

every attempt I make to create a wrapper produces an error message that says the new blank wrapper is damaged and can't be opened.

I've got the same error here.

[Gcenx]

@rfperuch & @emendelson ensure you both have the recent versions of everything from the Pre-release section as in making wrappers with the provided version of winery just fine, maybe it’s due to lack of any real code-signing

[emendelson]

I downloaded everything except the source code, and replaced my existing Wineskin Winery with the version from the prerelease page. It was the first thing I thought of doing, but the error messages occurred with both the earlier version and the prerelease one.

[Gcenx]

Oh sorry guys, yeah I get it now the wrapper is saying its damaged.

You need to download it using Safari/curl/wget as anything else will get the file marked as quarantine this doesn't usually occur as the wrapper is downloaded using Winery so the master wrapper doesn't get the quarantine mark.

I'd rather avoid making another branch for testing but if needed I'll do just that and then modify the pre-release version of Winery to look in the branch

[emendelson]

Good find! Could you give us the exact curl or wget address? Downloading via Safari was exactly what I was doing, and I got those errors.

[Gcenx]

Did you using a third party tool to unpackaged zip files?, I know using keka also screws with archives when it’s used to unpack archives.

[rfperuch]

Just removing the quarantine bit from the Wrapper worked here: sudo xattr -d -rs com.apple.quarantine ~/Library/Application\ Support/Wineskin/Wrapper/Wineskin-2.9.0.6.app

[Gcenx]

@rfperuch good to know, some users precisely said that the command failed so I avoided mentioning it.

[SamArtsy]

Hi @Gcenx, I’m using your wrapper with ws11winecx64bit19.0.1 and ws10winestaging64bit5.5. I have tried to make the cemu emulator work, but it just crashed at launch with both engines. Here’s the log:

000b:fixme:winediag:__wine_start_process Wine Staging 5.5 is a testing version containing experimental patches.
000b:fixme:winediag:__wine_start_process Please mention your exact version when filing bug reports on winehq.org.
0009:fixme:exec:SHELL_execute flags ignored: 0x00000100
0009:fixme:ntdll:FILE_GetNtStatus Converting errno 8 to STATUS_UNSUCCESSFUL
wine: Unhandled page fault on read access to 0000000000000020 at address 00000001408EF1AE (thread 0030), starting debugger...
0030:err:seh:start_debugger Couldn't start debugger L"false" (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger

The Software can be launched in a linux vm with the winehq-staging5.4. Is this the problem of macOS?

[Gcenx]

@SamArtsy

Windows 7 (x64) or above
OpenGL 4.1 minimum (4.6 is used if available)
RAM: 4 GB minimum, 8 GB or more recommended
Microsoft Visual C++ 2017 X64 Redistributable: vc_redist.x64.exe

macOS doesn’t have OpenGL that high that’s also why you can’t play DirectX10/11 games.

[SamArtsy]

@Gcenx Thank you for your help. Its wiki said it can run with vulkan 1.0. I think we can give it a try since we already have moltenvk.

[Gcenx]

@SamArtsy Only if that Vulkan 1.0 spec, most applications end up using additional extensions that MoltenVK does not provide.

So if it works or not is hit or miss really, however if it works that would be interesting news

[SamArtsy]

@Gcenx You're right, Moltenvk doesn't support all. Actually, it did work with some windows applications. The Dolphin Emu can run games in your wrapper with moltenvk. It shows gpu correctly .

But there is a question still bothers me. Why can I run the cemu in a linux virtual machine without modern graphics APIs? Like this:

Of course, it cannot run games just open the app.

[Gcenx]

@SamArtsy the problem from quickly looking is something with the memory allocation that cemu wants.

A VM works much different then wine and lightly why your at least able to open the applications.

Another example of this is Origin client refuses to open on macOS due to memory allocation yet will open on Linux.

This is one of many macOS only bugs that I haven’t even checked if they are reported or not.

Another fun one in recent version is your unable to use file dialogs/explorer to navigate your wineprefix with Winehq builds but my own compiles don’t have this issue

[Alex1844]

Awesome job Gcenx!

I have tested the 64 bit and it works great. I noticed that the pre-release engines you updated today are way smaller, which is also great.

I have noticed only two minor things.

1. The app icon in Launchpad is blurry, while the icon in the dock when that app launches, is sharp.
2. The app does not remain in the dock if I enable Keep in doc

Sent you a donation for your effort

[Gcenx]

@Alex1844 yeah I shrink the Engines and also the embedded runtime.

1) Honestly don’t use launchpad, but to guess that’s lightly due to the icon being low resolution.

2) It makes sense it doesn’t stay within the dock as your really pinning a running “wine” process not the actual wrapper.

I’ll still need to make changes to WineskinLauncher to get (2) working, that should also get the launcher process also using the selected icon (I think) The wrapper scripts will also be dropped around the same time.

Side Note; FAudio updated and now dropped 10.8 support, so I guess I should consider dropping 10.8 more of a hard requirement or add a work around to keep a 10.8 companion version around within wstools/lib as I do for an older version of libfreetype to keep supporting wine versions below 2.4.

[Alex1844]

FYI, Kaspersky does not complain at all about WS11WineCX64Bit19.0.1 All clear

[Gcenx]

@Alex1844 I'm aware this was accomplished by using the mingw-binutils patches from Proton-GE, so the PE headers are generated in a different manner. I posted a link above showing the results.

[Ted95070]

@Gcenx I've got my 64-bit app running correctly on Catalina using Winery 2.9.0.6 and WS11WineCX64Bit19.0.1, which is awesome! However, there is one small problem. The name of the app on the menubar is always "CrossOver-Hosted Application". I've set the CFBundleName in the Info.plist, but this doesn't seem to help. Is there some way to make it say something different?

[Alex1844]

@Ted95070 I do not have that problem with WS11WineCX64Bit19.0.1. The name works just fine out of the box.

I did notice it with WS11WineCX19.0.1 though.

[Gcenx]

@Ted95070 the name is embedded into wine wine32on64 and wine64 if a name wasn't found for some reason the default fallback name gets used, the newer builds of WineCX added to the pre-release have an embedded name of Wineskin. The CFBundleName doesn't affect the launched wine binaries, this will eventually be the case but currently it won't.

@Alex1844 this can happen regardless it's just the fallback name that's been embedded, I could patch out the embedded wine plist but I'm not sure what could happen when doing this. The newer build on pre-releases have the embedded name of Wineskin

[emendelson]

Things are looking good. First, in Mojave, I used the new prerelease software to create a new wrapper and update some old wrappers with a new engine. These all worked correctly in Catalina, with one exception:

One of my wrappers keeps asking for permission to receive keystrokes from any application. I try adding it in System Preferences, but the app doesn't get added to the list, and this message pops up every time. Is there a way around this? (The wrapper runs the vDos DOS emulator.)

Second, by using the sudo xattr command described in a previous post, I was able to create new blank wrappers. I made them run Notepad.exe and Write.exe, and they seemed to work.

Congratulations on this progress - and we all hope you're feeling better!!

EDIT: The prompt for permission to receive keystrokes occurs with WS11WineCX64bit19.0.1. It did NOT occur with WS9WineStaging64Bit5.1, which I was using in those apps earlier.

[Gcenx]

@emendelson the permission for keystrokes should happen regardless of selected Engine, thats required for secondary launch to bypass "Windows EXE" that's set, instead launching Wineskin.app configuration utility done by holding Alt/option when launching a wrapper.\ I might disable this on Catalina or just remove it entirely as its not exactly a known/used feature.

Now that the BundleID is more stable it should only need the permission once per wrapper, unless the wrappers name was changed causing the BundleID to be regenerated.

If you didn't already you should swap to using the newer WineCX19.0.1 builds provided under pre-releases.

I'm slowly feeling better thanks for asking

[emendelson]

@Gcenx - Do you mean that you might remove the ability to hold down Alt/Option in order to open the Wineskin.app configuration utility? That would be perfectly all right, I think. We don't really need the Alt/Option key for opening Wineskin, because we can View Package Contents and then run Wineskin directly. It's worth giving it up to avoid that permissions message.

[Gcenx]

@emendelson precisely

[Ted95070]

@Gcenx Sorry to be obtuse. I see that when I point the startup app to iexplore.exe it shows "iexplore" on the menubar. I'm assuming that there is something built into iexplore.exe that tells the system the name, but my app must not have it. In fact, since I didn't install gecko when the "please install gecko" popup happens it changed the name to "control", so something is working.

I checked the properties of my app and everything "seems" to be in place including the "Product name" property in Details. What am I missing?

BTW, when I tried to check iexplore.exe app to see how it was set up my antivirus claimed there was a trojan in the executable. Something that started with GenericRXJH-SY. I hope that's just some weird by-product of something.

[Gcenx]

@Ted95070 the menu name is pulled from the windows executables name usually or it’s internal name (you can check crossovers source I uploaded on my WineCX git)

The actual wrapper bundle name etc doesn’t have any affect on the menu name currently that will change eventually but not for the moment.

The virus detection should be going nuts for practically every PE compiled exe and dll file included within the engine.\ As you don’t mention what anti virus your using I can’t tell you if this false positive was resolved within my rebuild under pre-releases I’d you look afew comments up you will see a link to a total virus report showing what anti virus still pickup the new rebuild

[Ted95070]

@Gcenx I'm using McAfee Antivirus Plus.

As for the name, my app has both an internal name and windows executable name that I was hoping would show up, but it's not. This is compiled and linked with Visual Studio 2005 as I haven't had a chance to get it working with a newer version. Maybe that has something to do with it.

Don't worry about it. I can wait until you get the wrapper stuff working. I'm only going into beta so I'll just note this as a limitation to be fixed later. The people who want this will just be thrilled that it's available at all. Which is where they were before. Thanks for your help and hard work on this. It's greatly appreciated.

[Gcenx]

@Ted95070 even the newer build under pre-release will show up in McAfee and some other anti virus, see TotalVirus

I’d recommend using the newer Engine at minimum to help lower false positives for anti virus reports.

The new releases will be pushed soon as I believe the majority of bugs were resolved within it already

[Gcenx]

I updated the wrapper again for MoltenVK and added gcrypt as wine-staging now uses that for bcypt. WS10WineStaging5.5 & WS10WineStaging64Bit5.5 both were rebuilt to take advantage of this.

I think this should be the last change before making the pre-release an actual release, overall it seems this covers a large majority of the current feature requests and bugs

I had some additional features to work on within Winery but I'll leave those disabled for the moment as the ability to use 64Bit only Engines requires the updated Winery

Winery now allows;

• wine64 only engines
• wine32on64 only Engines
• Strips winehq dylibs that I already provide (on repack and wrapper creation)
• Strips additional unused files from Engines (on repack and wrapper creation)

[Alex1844]

With the latest pre-release update, I have noticed that it actually takes a while to close the app. It disappears from the screen immediately, but I still see it in the Monitor for up to 10 seconds. If I remember correctly, it used to be like 3-5 seconds to disappear from the Monitor. In the meantime,the app cannot be started again until it is completely gone (the app itself does not allow more than 1 instance). Could that be due to some change with wrapper/engine (64bit)?

[Gcenx]

I did add an extra wait after running wineserver -k, it waits then checks again and if it’s still running it’s force closed using wineserver -k9

I could remove that step

[Alex1844]

It waits on the Windows application to close? If that is the reason I have to look into why is the Windows application not closing in a timely manner.

[Gcenx]

Not exactly, I use the builtin command wineserver -k (shutdown wine processes) WineskinLauncher checks if wineserver is still running, if it’s still running then we do wineserver -k9 (force close wine processes)

I using wines included system over directly killing wine processes as the official version did as it always left multiple processes still hanging, this is slight cleaner.

Maybe I could reduce the timeout slightly to speed up the additional check.

[Gcenx]

After wineserver has exited then permission fixing happens not before that corrupts wrappers if things are still open/running

[emendelson]

The latest versions are working extremely smoothly. Thank you!

[Gcenx]

The exit lag on the last upload seems to have been caused by my temporarily disabling the wine binary wrapper creation and forgetting to re-enable it before uploading the last pre-release version.

Just uploaded Wine-Staging-5.6.1 Engines to my MEGA

[Alex1844]

Today's update works awesome. Closing the app is better.

There is only one typo when you launch WineSkin.app. In Configuration tab it states that the engine is WS11WineCX164Bit9.0.1 instead of WS11WineCX64Bit19.0.1 164Bit9.0.1 instead of 64Bit19.0.1

Thanks for great job