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

[Gcenx]

@Alex1844 @emendelson @marnovo @NBR101 @The-SamminAter @kant Tagging as I'm sure you will all find this of interest.

Any bugs found then using WineCX19.0.1 can be reported here and on CrossOver-20 (based on Wine-5.0) if I own the game/software I'll verify the bug still exists and report it to hopefully get it fixed before it's launch. WineCX19.0.0 and WineCX19.0.1 contain the following patches;

• Update winldap_private.h
• Revert "HACK: Disable the wait window as it is deemed confusing"
• Create distversion.h

[emendelson]

Something seems to be wrong with the WS11WineCX64Bit19.0.1 engine. When I add it to Winery, it appears instantaneously in the list of Installed Engines (and doesn't take a long time to download) and when I try to create a wrapper with it, Winery reports that the engine is corrupted.

The non-64bit version works correctly; the problem is only with the 64-bit version.

[Gcenx]

@emendelson yes sorry I should have posted about that issue, since the Engine was larger the 100MB I needed to use “git lfs” that changed how the file is stored.

Currently working on a quick Winery update to resolve the issue by using an alternative GitHub link.

If you want it now just download it directly from GitHub

Resolved in Winery-1.8.4 Also provided a modified Winery that doesn't compress engines, speeds things up but increases disk usage for repackaged Engines

[emendelson]

Thank you - will test when back at my home machine.

[emendelson]

The new Winery update successfully downloaded the CX 64-bit engine, and I updated an existing 64-bit app to the CX version (under Mojave). It seems to start up more quickly than the 4.x engine I was using earlier, and works perfectly, as far as I can tell. Thank you!

I won't be able to test under Catalina for a while, and may wait until we don't need to disable protection - unless it would helpful to you for me to do that.

Meanwhile, thank you for this!

[Alex1844]

For me, the new winery on Catalina does not even list the CX 64 bit version, only WS11WineCX19.0.1

[Gcenx]

@Alex1844 I'd forgotten to add it back to the list, I had to remove it while setting "git lfs" as disabled.

I've added it back to the list just moved the Engine's location to work around the lack of bandwidth LFS provides (1GB....)

[xellosiris]

it seems has a privacy problem when I executed window application on winery.I tried to change privacy setting but it doesn't work......:( ps.I do turned off SIP

[Gcenx]

@xellosiris I’ve received the same prompt for permissions even when using CrossOver19, I’d given it permission but I still get the prompt on each launch.

As for the software it’s possible it’s just not compatible with that version of wine, I’ve had luck with other software and games

[emendelson]

I think (or simply imagine) that the permissions prompt will come up every time if the app is not notarized. But that's mostly a guess.

[Gcenx]

Rebuilt WineCX19.0.1 without ffmpeg, haven’t done a wrapper update with the newer runtime embedded just yet but I did add it as an asset under releases.

Edit;
Working on some updates,

Winery

• Will give a warning if SIP is enabled on macOS Catalina
• Strip invalid characters from wrapper name on creation

  WineskinLauncher

• will generate a sane BundleID

  Wineskin.app

• will no longer touch BundleID

[Alex1844]

I have tried the latest WineCX19.0.1 with 2.9.0.6 wrapper but now my app completely fails to start

This is reported in the log

i386_set_ldt: Operation not permitted wine: failed to initialize: failed to set the LDT entry for 32-bit code segment

My app is a 64 bit app and it worked (apart from Full Disk Access issue) on previous 19.0.1 build and 2.9.0.5 wrapper

[Gcenx]

@Alex1844 to use WineCX19.0.1 on Catalina you need to disabled SIP that’s the reason for the error, this is explained in my first comment.

I’d made a slight tweak to 2.9.0.6 it always prefers wine32on64 over wine64 on Catalina also prefers wine over wine64 when below Catalina. This fixed some launch bugs when dealing with 32Bit binaries.

Use another engine and let me know if it still doesn’t work so I can fix it within the next wrapper update.

[Gcenx]

Adding a new comment so anyone subscribed will get the additional information

Vitor had added an extension for easily checking if SIP is enabled, so instead of being static on setting wineExecutable I’ll change how it functions and expand on it.

If your running macOS Catalina with SIP enabled it will set wine64, if no wine64 it will display and error then terminate.

If your running macOS Catalina with SIP disabled use wine32on64 if available, if not available fallback to wine64, if no wine64 it will display and error then terminate.

Anything lower will default to using wine

[xellosiris]

Hi Gcenx, I have tried WineCX19.0.1 with 2.9.0.6 wrapper but my app fails to start. Could you please help me on this? This is reported in the log:

0009:fixme:winsock:set_dont_fragment IP_DONTFRAGMENT for IPv6 not supported in this platform 0035:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFA, 029FFDDC 0009:fixme:shell:InitNetworkAddressControl stub 0009:fixme:mpr:WNetGetUniversalNameW (L"C:", 0x00000001, 0033EA40, 0033EA0C): stub 0009:fixme:mpr:WNetGetUniversalNameW (L"C:", 0x00000001, 0033E5F0, 0033E5BC): stub 0009:fixme:mpr:WNetGetUniversalNameW (L"C:", 0x00000001, 0033E17C, 0033E148): stub 0009:fixme:imm:ImmReleaseContext (00010054, 09789948): stub 0009:fixme:imm:ImeHandleNotify WM_IME_NOTIFY:IMN_SETOPENSTATUS 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0009:err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0009:err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0009:err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0009:err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0009:err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0009:err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered 0009:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0009:err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 0009:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0033FD24

[Gcenx]

@xellosiris I’ve clipped the err:plugplay lines from your comment those can be ignored.

I don’t see anything that stands out causing the software to fail, a link the software would be ideal to attempt to debug it.

[xellosiris]

Hi Gcenx, Thank you pay attention on this. I am not quite understand you said…"a link the software would be ideal to attempt to debug it”. Where should I get a link from ? or should I tell you the name of application?

Huang Kuanwei

On Jan 30, 2020, at 10:33 AM, Gcenx notifications@github.com wrote:

@xellosiris https://github.com/xellosiris I’ve clipped their err:plugplay lines from your comment those can be ignored.

I don’t see anything that stands out causing the software to fail, a link the software would be ideal to attempt to debug it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Gcenx/WineskinServer/issues/26?email_source=notifications&email_token=AH7AODRZMJ3TARZN6MM2F2LRAI4AZA5CNFSM4KIV3RRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKJPN3Y#issuecomment-580056815, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7AODUE2AIZ7WUUEXFSBR3RAI4AZANCNFSM4KIV3RRA.

[Gcenx]

@xellosiris the name of the application and/or a link to the softwares homepage so it can be downloaded or a trial can be downloaded.

Without the software I can’t try making it work on my system

[xellosiris]

Hi Gcenx, the software name “Watchtower Library”, I put download link as below: https://www.jw.org/en/online-help/watchtower-library/install-watchtower-library/ The Website provide software in iso format. Please feel free if you want to contact me privately via email, and sorry to bother everyone.

Huang Kuanwei xellosiris@gmail.com

On Jan 30, 2020, at 11:14 AM, Gcenx notifications@github.com wrote:

@xellosiris https://github.com/xellosiris the name of the application and/or a link to the softwares homepage so it can be downloaded or a trial can be downloaded.

Without the software I can’t try making it work on my system

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Gcenx/WineskinServer/issues/26?email_source=notifications&email_token=AH7AODXZCYP7Z4L3XCJHQI3RAJA25A5CNFSM4KIV3RRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKJRLYI#issuecomment-580064737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7AODRWG5AHFK7IL2ZBAMTRAJA25ANCNFSM4KIV3RRA.

[LeonVeganMan]

Hi Gcenx, first of all a big "thank you" for your effort !!!

We are try to notarize our app, but on codesign we have this error:

/usr/bin/codesign --force -o runtime --timestamp --verbose=4 -s "Developer ID Applic ation: (**)" "/Users/****/Desktop/MYAPP.app"

bundle format unrecognized, invalid, or unsuitable
In subcomponent: /Users/****/Desktop/MYAPP.app/Contents/Frameworks/wswine.bundle

Any suggestions?

Thanx. Ciao. L.

[Gcenx]

@leonbadman that sounds correct as wswine.bundle and wstools.bundle we’re both manually created Xcode didn’t generate them so they would have an invalid structure/missing files.

At the moment I haven’t finalized all backend changes to make signing/notarizing the final application easy.

If there application is to be ran on macOS Catalina you could pull the contexts from wswine.bundle and place then into another basic application, codesign/notarize them, then place then back into wswine.bundle.

@emendelson do you happen to have any advice for @leonbadman as I know you’d managed to sign/notarize a wrapper you had created.

[emendelson]

@leonbadman - I've been able to codesign wrappers using the standard codesigning commands, but I've never been able to notarize a wrapper. Codesigning is basically meaningless under Catalina: it's part of the notarizing process, but it's not enough to turn off warnings, permission requests, etc. PS The simplest way to notarize is to use SD Notary from LateNightSoftware (makers of Script Debugger) but of course you'll need a developer account from Apple.

[LeonVeganMan]

Hi @Gcenx and @emendelson .. thank you for your support. We've try SD Notary, but while codesing the app, a strange error occured: "Bad file descriptor" (I think too many open files).

Ciao. L.

[emendelson]

I've been away from Catalina for a while, but did some brief testing with Wineskin today. I've been testing with a 64-bit Windows app (a version of the vDos DOS emulator) and it works very well under Catalina, with the 2.9.0.6 wrapper and the WineStaging64Bit5.1 engine.

As expected, I can't codesign or notarize it, but it doesn't ask me for permissions each time I run it. This seems to me good progress. Thank you!

EDIT: One question: When I ran the latest experimental 64-bit version of vDos in my wrapper, vDos gave me the error message "Do not run vDos elevated." I have an older version that I can use instead of this one, but is there some way I can prevent Wineskin from running an application with elevated privileges? I'm also in touch with the vDos author, in case this is just a bug that only appears under Wineskin. FURTHER EDIT: Ignore this question. As the Wine FAQ says:

As far as Windows programs are concerned, you are running with administrator privileges. If an application complains about a lack of administrator privileges, file a bug; running Wine as root probably won't help.

So I'll need to get in touch with the program author and ask him to allow his program to run as admin.

[Alex1844]

Try signing out and back in and then try again if it asks you for permissions. For me it works fine after i add it to full disk access as long as I do not sign out or restart the machine. After that I does not have access and i have to fiddle with it to somehow get it to work again

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: emendelson notifications@github.com Sent: Sunday, February 9, 2020 9:35:58 PM To: Gcenx/WineskinServer WineskinServer@noreply.github.com Cc: Alex1844 alexsql@hotmail.com; Mention mention@noreply.github.com Subject: Re: [Gcenx/WineskinServer] Inintial macOS Catalina support (#26)

I've been away from Catalina for a while, but did some brief testing with Wineskin today. I've been testing with a 64-bit Windows app (a version of the vDos DOS emulator) and it works very well under Catalina, with the 2.9.0.6 wrapper and the WineStaging64Bit5.1 engine.

As expected, I can't codesign or notarize it, but it doesn't ask me for permissions each time I run it. This seems to me good progress. Thank you!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Gcenx/WineskinServer/issues/26?email_source=notifications&email_token=AJLDGR5O3XXNNG2FSN5JPY3RCC4Q5A5CNFSM4KIV3RRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELHBOHI#issuecomment-583931677, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJLDGR53M7Y6MXYFHGKQRU3RCC4Q5ANCNFSM4KIV3RRA.

[Gcenx]

@emendelson thats the opposite it’s complaining because of wine faking being admin all the time.

See bug 40613

[emendelson]

Yes, that's what I finally figured out. The vDos author is going to put in a check for whether the program is running under Wine, and will allow vDos to run as admin if it is.

[emendelson]

@Alex1844 - I signed out and then in again, and started my 64-bit wrapper without getting any requests for permission. I suspect this may be because I copied it from a Mojave partition and never downloaded it from anywhere. If I remember correctly, there's a command that lets you remove the extended attributes that tell macOS that an app has been downloaded, and I wonder if that might help with these permission requests? (Obviously, I should experiment, but maybe someone knows the answer already.)

EDIT: Yes, here it is:

xattr -d com.apple.quarantine /path/to/application/applicationName.app

[Gcenx]

The permissions issue is lightly tied to the BundleID generation producing an invalid BundleID

That should be fixed in the next wrapper release as it now strips all invalid characters from the wrappers name to generate a more realistic BundleID

As long as Wineskin Winery isn’t blocked the downloaded wrapper shouldn’t have any issues in that regard. I believe it’s more the BundleID issue

[Alex1844]

When do you expect to release the next wrapper?

Thanks for the the great work you are doing.

[Gcenx]

@Alex1844 I don’t have a fixed timeline for the next update unfortunately (lack of free time and doing this mostly solo) All components are getting updates;

WineCX19.0.1 will be replaced again so all PE files will get the wine headers, hopefully if enough people flag them as false positives then antivirus will be happy. The above was accomplished by back-porting some upstream commits from Wine-5.1 to add the --builtin flag into winegcc/winebuild that allows PE files to get the “wine” headers.

I’d like to get the signing issue resolved so wrappers can be code signed/notarized

[PlanetIrata]

Hi @Gcenx, any idea of a release date ?

Thx for great work!

[Gcenx]

@PlanetIrata no ETA as currently I'm also ill with COVID-19.

However running without SIP being disabled requires a developers license, as others have asked previously I have added a to the README with a developers license the SIP requirement will be no more.

[marnovo]

@Gcenx that's sad to hear, take rest. I hope you and your significant others get well and healthy soon! Contributed ✔️

[emendelson]

Get well soon (and, when you get a chance, check your e-mail...)

[Gcenx]

Done a little work on wineskin since I'm in quarantine fixed the BundleID generation.

Also some interesting findings while not as good as code-signing and notarizing the binaries, macOS Catalina 10.5.4 made a change to the no32exec=0 boot argument, now setting this also allows i386_set_ldt to be changed meaning SIP can still be enabled while retaining the ability to use wine32on64 10.15.3 and below this wasn't the case

[Alex1844]

Great news, I hope you are getting better, given that you were able to do some work. Get well soon!

[Gcenx]

Unfortunately that's not the case i'm getting worse each day, but my brain needs to stay busy so I work on things when possible.

[Alex1844]

Sad to hear that, hopefully you will get over it soon

[Alex1844]

Kaspersky is quarantining a whole bunch of windows executables in the wrapper on my Mac for WS11WineCX19.0.1, marking them as Trojan infected. Have you checked your system for viruses?

[Gcenx]

My system is clean, same for those files that’s a false positive, since wine moved to using PE format executables it’s more common for these files to get flagged by anti virus software.

This was also mention on CodeWeavers blog and upstream wine

[Alex1844]

Thanks for clarifying that.

Any ETA for new wrapper now that you fixed the BundleID generation?

[Gcenx]

Not too sure just yet need to do some more testing on the newer versions of WineskinLauncher & Wineskin.app to ensure both are working as expected.

Lastly wipe out my macports install and build it cleanly to ensure there are no issues.

Also looking into the possibility of using the Proton binutils patches, wondering if that might help with this virus detection issue

[LeonVeganMan]

Unfortunately that's not the case i'm getting worse each day, but my brain needs to stay busy so I work on things when possible.

Hi Gcenx, OMG....be strong !!! Cheers from Italy.

[Gcenx]

@Alex1844 I have some good news I've integrated these binutils patches into my version of mingw-binutils and here is the VirusTotal Results 6/71 that's from a build of WineCX19.0.1 I'd just ran. So future builds should be flagged way less going of these results.

@leonbadman thanks I'm mostly resting and working on wine related projects when I'm able to keep my mind occupied, I hope your doing well in Italy for NYC the cases have increased very quickly I'm good enough to not need to enter a hospital lucky as there very overrun.

[Alex1844]

Great, your hard work is much appreciated.

Is there a relatively simple way to produce a 64 bit only wrapper? 32on64 is half the size of the 64 bit as the 64 bit includes both.

[Gcenx]

@Alex1844 I'm not sure exactly what your asking here?

Do you mean you want an Engine that only includes wine64 ?

The WS11 Engines are setup in a different manner then a normal Engine,

• 64Bit Engine contains wine, wine32on64 & wine64
• 32Bit Engine contains wine & wine32on64 To reduce the size I do some symlinking. The dll and exe files of /lib32on64/wine/ load from /lib/wine

WS11WineCX19.0.1 runs on 10.8 > 10.15 WS11WineCX64Bit19.0.1 runs on 10.8 > 10.15

If your wanting to have the ability to use pure Catalina compatible wrappers that's something I need to implement into WineskinLauncher to allow wine32on64 only as well as wine32on64 & wine64 but that's not too desirable so I won't be providing pre-built Engines like this within Winery for direct download anytime soon

[Alex1844]

Yes, an Engine that only includes wine64.

Thanks for the clarification

[LeonVeganMan]

Hi Gcenx, a little donation to purchase the developer license from Apple. Thanx for your effort.

Ciao. L.

[Gcenx]

@Alex1844 You can find the files here pre-release 1.8.4.2 I've provided two Example Engines for you.