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]

@PlanetIrata if you check remakedefaults.reg within Wineskin.app/Contents/Resources/ you will notice that registry setting is applied to multiple sections already so that might not be required

The browser crashing on Mojave does seem strange, I have a suspicion is related the newer version of wine-gecko

I’d deactivated wine-mono-5.0.0 To do some tests for the Winehq like builds I uploaded, and noticed gecko was now crashing but reactivating wine-mono-5.0.0 it started to work again.... maybe I should rebuild WineCX19.0.1 without upgrading the gecko version.

[PlanetIrata]

@PlanetIrata if you check remakedefaults.reg within Wineskin.app/Contents/Resources/ you will notice that registry setting is applied to multiple sections already so that might not be required

The browser crashing on Mojave does seem strange, I have a suspicion is related the newer version of wine-gecko

I’d deactivated wine-mono-5.0.0 To do some tests for the Winehq like builds I uploaded, and noticed gecko was now crashing but reactivating wine-mono-5.0.0 it started to work again.... maybe I should rebuild WineCX19.0.1 without upgrading the gecko version.

Thx for tips, but the command line in remakedefaults.reg regarding winebrowser.exe will not work with filenames containing spaces, that's why we have manually replaced the %1 by "%1" in the registry. Would be great if Wineskin could generate the commands with "%1" by default.

Regarding the browser crashing under Mojave (but working with Catalina 🤷🏻‍♂️), if you could rebuild WineCX19.0.1 without upgrading gecko, I can test it and give you some feedback.

Thx again for great work!

[PlanetIrata]

I created a PR to fix remakedefaults.reg https://github.com/Gcenx/wineskin/pull/29 https://github.com/Gcenx/wineskin/pull/29

Thx

Yann

Le 26 mai 2020 à 00:57, Gcenx notifications@github.com a écrit :

@PlanetIrata https://github.com/PlanetIrata if you check remakedefaults.reg within Wineskin.app/Contents/Resources/ you will notice that registry setting is applied to multiple sections already so that might not be required

The browser crashing on Mojave does seem strange, I have a suspicion is related the newer version of wine-gecko

I’d deactivated wine-mono-5.0.0 To do some tests for the Winehq like builds I uploaded, and noticed gecko was now crashing but reactivating wine-mono-5.0.0 it started to work again.... maybe I should rebuild WineCX19.0.1 without upgrading the gecko version.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Gcenx/WineskinServer/issues/26#issuecomment-633736748, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANGH6LTXB6AQBOMHEUJG7TRTLZUHANCNFSM4KIV3RRA.

[Gcenx]

@PlanetIrata I actually don't use that source anymore honestly the current version isn't committed anywhere public, I did push an updated wrapper with the correction along with some other tweaks.

WineCX19.0.1-2 will be uploaded once its done compiling

[PlanetIrata]

Ok thx, but still can’t find WineCX19.0.1-2 it in the assets at https://github.com/Gcenx/WineskinServer/releases

And I think that the latest update date is May 25, not March 25 ;-)

Regards,

Yann

Le 26 mai 2020 à 04:52, Gcenx notifications@github.com a écrit :

@PlanetIrata https://github.com/PlanetIrata I actually don't use that source anymore honestly the current version isn't committed anywhere public, I did push an updated wrapper with the correction along with some other tweaks.

WineCX19.0.1-2 will be uploaded once its done compiling

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Gcenx/WineskinServer/issues/26#issuecomment-633780746, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANGH6LIXFRQS2D2DVYNO7TRTMVH7ANCNFSM4KIV3RRA.

[Gcenx]

Yeah I was half asleep editing that, corrected and attached the newer build minus wine32on64 for the moment if that resolves the pre-Catalina issue for you will replace the build with one that contains wine32on64

[PlanetIrata]

Yeah I was half asleep editing that, corrected and attached the newer build minus wine32on64 for the moment if that resolves the pre-Catalina issue for you will replace the build with one that contains wine32on64

No change with engine WineCX19.0.1-2 under Mojave. The browser icon still bounce and never start when TOWeb open a html file for previewing. Tested with Safari, Chrome and Firefox as default browser, the same. The browser icon bounce and never open.

We tried to disable SIP on the MacbookAir under Mojave, but still the same issue.

Interestingly TOWeb with engine WineCX19.0.1-1 that don't open browsers under Mojave works perfectly under El Capitan on a 10 years old MacbookAir, it opens the default browser without any issue 🤷🏻‍♂️

And we have retested TOWeb with wrapper 2.6.2 and engine WS9Wine1.9.24 under Mojave, it opens the browsers correctly.

The issue seems to concern only Catalina engines under Mojave. But we have only tested so far on one Mac under this OS.

Thx for help

[Gcenx]

@PlanetIrata I’m starting to think the issue isn’t the Engine but permission based issue.

Older applications have some of these restrictions relaxed, if possible could you try using Winehq Engine Launch that should launch a winehelp bash script contained within Wineskin.app that setup a terminal session with the engine in PATH with everything set bar the wineprefix. You might need to grant Terminal more permissions depending.

[Gcenx]

What steps would I need to follow to get the crash you experience?

[PlanetIrata]

What steps would I need to follow to get the crash you experience?

• Download and install our latest TOWeb for macOS master from this link: https://www.lauyan.com/download/setup-toweb8.dmg

• Launch it, create a website by following instructions and click the preview button (play button in a circle in the sidebar).

• Under Catalina your default browser will open the website

• Under Mojave, your default browser will not open, the icon will bounce infinitely, wand the browser will crash

Thx

[Gcenx]

I only got to quickly test this, the app I downloaded last night used the older Engine that does open the native browser.

I upgraded the wrapper to mine, still works (I have XQuartz installed), next swapped to wine-5.9 compile now it won’t launch the native browser

Not sure if the issue is a regression within winebrowser or some configuration that needs to be set.

Edit;\ Used Winehq Engine Launch installed the application into a clean wineprefix and chrome loaded the test page.

Now to figure out what’s causing this within WineskinLauncher....

Edit2;\ Figured out what’s causing the issue, I’ll tag you once the fixed version is uploaded

[Gcenx]

@PlanetIrata well launching winebrowser now works but seems to take longer than a much older engine, but if I use the play button and view a site the app wont cleanly exit.

If I launch the application and exit without pressing play it exits cleanly

[PlanetIrata]

@PlanetIrata well launching winebrowser now works but seems to take longer than a much older engine, but if I use the play button and view a site the app wont cleanly exit.

If I launch the application and exit without pressing play it exits cleanly

@Gcenx yes, there's an issue while closing the app we don't have with older engines. Does the fix for winebrowser is uploaded ?

[Gcenx]

Need to verify winetricks is working again before uploading the newer revision, the last few weeks have been hectic

[PlanetIrata]

Thx @Gcenx, some users of TOWeb under Catalina have another issue that we are not able to reproduce (snapshot of a user below): on the first time that Chromium is displaying our templates, they have a strange error saying that TOWeb tries to delete a xxx.asset file that it is not allowed to since it is not from a trusted developer.

After some research it seems that this file extension is for Unity engine. Could it be related to the fact that we have disabled d3d11 in order for chromium to work... (see above in the thread) ?

Any idea ?

Thx

[Gcenx]

@PlanetIrata was TOWeb built using unity Engine?

Where does TOWeb typically store those .asset files?

Last night got some testing done and have stock winetricks working with wine32on64, wine64 only and also wine Wineskin will now provide winetricks with 7za, cabextract & unrar

Launches regular launches were unaffected\ And Winehq launch is also functioning correctly

[PlanetIrata]

@Gcenx, TOWeb do not use Unity engine, and do not create or use any file with the .asset extension...

[Gcenx]

@PlanetIrata I'm not sure where the .asset is coming from then, have any other users reported this issue?

I've sent the newer wrapper version to PaulTheTall so he can test it out in combination with PortingKit, some additional issues have been resolved

• TestRun no longer instantly crashes on macOS Catalina (now only if clicked quickly after opening)
• Winetricks menu can now install verbs (place next to winetricks and select custom call the .verb)
• Added wrappers for winetricks compatibility (wine, wine32on64, wine64, & 7z)
• 7za Updated
• cabextract Updated
• unrar Updated
• winehelp functions correctly (Winehq Engine Launch)
• winetricks is downloaded directly from official github (for Winetricks/Winehq Launch)
• Wineskin.app will now will now use the correct csmt Registry setting for WineCX18.0.0 and above
• Single DYLD_FALLBACK_LIBRARY_PATH configuration
• Improved PATH configuration

Edit;\ Needed to remove 7z & 7z.so Apple archive stage really didn’t like 7z.so, might look into resolved that later

[Gcenx]

The remaining issues are related to the changes to permissions.

Not having access to ~/Downloads and attempting to install will results in the error

There is no Windows program configured to open this file type

Having SIP disabled bypasses the new restrictions on most all the users directory’s (~/Desktop, ~/Documents, ~/Downloads, ~/Photo etc)

I’ll be looking into using AppSandboxFileAccess it doesn’t seem ideal but I’m not finding much else that does what’s needed, I’d rather just request access to ~/Desktop, ~/Documents & ~/Downloads and ignore the others.

I’ll try to provide the latest version of Wineskin-2.9.0.7 tonight, bar the permission annoyance I believe it’s stable enough to become the current version.

[Alex1844]

The latest update, Wineskin-2.9.0.7-Beta1.txz with WS11WineCX64Bit19.0.1-1.tar.7z has the following issues:

1. The Top Menu says WineSkin again. It used to show the name of my app
2. When new wrapper is launched the first time, it does not ask for the permissions to user folders anymore and it does not map the folders.
3. Even when manually added to Full Disk Access, it still does not map Documents folder. Actually, even if I, in my application that has full disk access navigate from root folder, up to the Documents folder, i.e. /Users/myuser/Documents, it does not show the content of the folder, although there are some files there. It does show the content of other folders though, just not the Documents folder. Disabling/enabling folder mapping in Wineskin makes no difference. Another weird thing I noticed is that in Activity Monitor, the process with the name of my app appeared only a couple of times I launched it, and never after. I would launch the app, there would be 6 instances of Wine64-preloader, but not a single with my app name even though the app launches and works fine with the exception of the user folders

[Gcenx]

The latest update, Wineskin-2.9.0.7-Beta1.txz with WS11WineCX64Bit19.0.1-1.tar.7z has the following issues:

1. The Top Menu says WineSkin again. It used to show the name of my app

Hum that’s strange, I’ve seen the menu bar name being different but it depends on the executable.

2. When new wrapper is launched the first time, it does not ask for the permissions to user folders anymore and it does not map the folders.

Yeah once I code-signed the binaries it now doesn’t prompt for the permissions, seems I need to add additional entitlements to enable that plus add a fallback to ensure the wrapper really has the needed permissions as mentioned above.

3. Even when manually added to Full Disk Access, it still does not map Documents folder. Actually, even if I, in my application that has full disk access navigate from root folder, up to the Documents folder, i.e. /Users/myuser/Documents, it does not show the content of the folder, although there are some files there. It does show the content of other folders though, just not the Documents folder. Disabling/enabling folder mapping in Wineskin makes no difference.

The above is correct behavior on macOS Catalina with the changes to Gatekeeper/SIP

Another weird thing I noticed is that in Activity Monitor, the process with the name of my app appeared only a couple of times I launched it, and never after. I would launch the app, there would be 6 instances of Wine64-wrapper, but not a single with my app name even though the app launches and works fine with the exception of the user folders

That’s intended behavior, prior wrappers would rename the wine binaries giving them unique names and replacing them wrapper scripts causing other permission issues.

Now wrappers will directly use the wine binaries for normal launches, wrappers are a temporary measure for winetricks comparability

[Alex1844]

Another thing. My app is checking if it is already running, not allowing multiple instances. I always create a wrapper as a different Mac user than my main one, install into Applications folder and after everything works fine sign in as the main user and test again. It always worked fine. Now, while everything seems to work fine launching and closing the app as that second user, if I close the app, just lock out that second user, not logout, and switch to the main one, when I launch the app it says that it is already running as a different user and it won't launch. That means that when I close the application, it is still running even though the window disappears and everything I can recognize disappears from Activity Monitor. Some process keeps it running. Which is weird, because I am able to relaunch the app as that second user again, meaning that such launch actually tears the previous instance before launching it again.

Update: eventually I got an error that the main user does not have permission to write to user.reg in resources (since the wrapper was created and moved to /Applications by the second user and everybody else apparently has read only permissions) This was never an issue since long time ago when there were some folder permission misconfigurations if you remember

[Gcenx]

Update: eventually I got an error that the main user does not have permission to write to user.reg in resources (since the wrapper was created and moved to /Applications by the second user and everybody else apparently has read only permissions) This was never an issue since long time ago when there were some folder permission misconfigurations if you remember

Good catch thanks, the reason it was never previously an issue is after launch WineskinLauncher would move the Contents/Resources/ into /tmp change the permissions then move back.

Now the issue with that approach is when the user doesn’t have full write permissions (can happen after an update) the files that have corrected permissions can’t be moved back causing the wrapper to become empty.

The replacement code “should” have fixed permissions for everything within /Contents/Resources but it seems that wasn’t the case.

[Gcenx]

@Alex1844 While I haven’t gotten any permission prompts (maybe I still need to reset something) I have resolved the “Full Disk Access” not working.

Started to look into the permissions one, I made a new wrapper the internals are owned by my user and everyone, however MyCoolWrapper.app was only owned by my user not everyone. Looks like that caused the permission weirdness you’d gotten.\ To resolve this I'll need to alter Winery to fix the permissions once the wrapper is extracted.

For the “already running” one I’m not sure what’s going on with that one yet

[Alex1844]

Did you upload the updated wrapper? I see that It is still called Beta1 and I tried it but Full Disk Access does not work. Actually I see that it is a new one as it creates a smaller wrapper than the previous one, but FDA does not work.

[Gcenx]

@Alex1844 the uploaded wrapper was the one I’d tested on Catalina and it functioned unlike the previously uploaded copy.

It’s possible you tccd database is corrupted, before I started testing I’d reset the tccd database then proceeded with testing.

Make a new wrapper with unique name, add newly created wrapper to “Full Disk Access” now the installers I selected from ~/Downloads no longer gives an error.

This was also tested using the next release of PortingKit where instead of giving permissions for a wrapper, I’d added PortingKit to “Full Disk Access” this caused any wrappers launched to inherit the granted permissions

[Alex1844]

This is what I got when I tried to reset the tcc

tccutil reset SystemPolicyAllFiles

tccutil: executable_is_endpoint_security_client failed for path file:///Applications/MyApp/Contents/MacOS/WineskinLauncher with error: invalid Info.plist (plist or signature have been modified)

[Gcenx]

I used tcc-reset.py I needed to disable SIP run the re-enable SIP.

I don’t place any ports into /Applications, but the error about the plist not being signed/changes makes sense and lightly why wrappers don’t prompt for permissions but adding them manually did work when I was testing it.

I’ll remove the plist from WineskinLauncher project files that should avoid that, or I just don’t code-sign the wrapper at all again

[Gcenx]

@Alex1844 I updated the wrapper again Wineskin-2.9.0.7-Beta2 updated Runtime and skipped code-signing I'm hoping this restores the functionality you had with previous versions of Wineskin-2.9.0.7

Also uploaded a slightly modified version of Winery that applies permissions on the wrapper after extraction and also on wrapper creation, this might help when having a wrapper within /Applications over ~/Applications

[Alex1844]

Verified: It asks for permission to access Documents folder and access works fine. Already running issue does not appear anymore.

Still not working: When launched as a different user from /Applications, it still complains that Resources are not owned by the user.

Thanks

[Gcenx]

Still not working: When launched as a different user from /Applications, it still complains that Resources are not owned by the user.

@Alex1844 did you also use the newer version of Winery to create the wrapper?, as that now alters the wrappers permissions on extraction and also on wrapper creation

[Alex1844]

Yes, I did

[Gcenx]

To investigate that more I’ll need to add multiple users onto my Catalina install.

Side Note; At least for Intel based systems wine32on64 Is still functional on macOS Big Sur

[Alex1844]

Beta3 seems to work fine. It asks properly for access permissions for Documents folder. It works fine in /Applications for different users.

The only thing is that it still says Wineskin as the app name, which is not a big deal.

Thanks, your work is much appreciated

[Gcenx]

Beta3 seems to work fine. It asks properly for access permissions for Documents folder.

It seems to work fine, as long as the end users tccd database isn’t corrupted.\ It’s about time I add a wiki to cover know issues/questions.

It works fine in /Applications for different users.

Yeah I restored a function I’d precisely removed, I hope the permission changes Winery does on wrapper creation is enough to avoid wrapper self corrupted when the wrapper is placed with /Applications over ~/Applications.

The only thing is that it still says Wineskin as the app name, which is not a big deal.

This isn’t cause by the wrapper but the Engine, is removed the “crossover hosted-application” string and replaced it with “Wineskin”

I’m sure some noticed there’s no more unique wine binaries names, these wrappers were removed to avoid issues with entitlement/permission inheritance, wrapper script are only used during winetricks/Winehq engine launch. (The wrapper scripts will be changed to binary wrappers later)

Thanks, your work is much appreciated

Thanks

[PlanetIrata]

@Gcenx found that this issue is related to the fact that the user stores its Desktop and Document in iCloud. Reported in #50.

Thx @Gcenx, some users of TOWeb under Catalina have another issue that we are not able to reproduce (snapshot of a user below): on the first time that Chromium is displaying our templates, they have a strange error saying that TOWeb tries to delete a xxx.asset file that it is not allowed to since it is not from a trusted developer.

After some research it seems that this file extension is for Unity engine. Could it be related to the fact that we have disabled d3d11 in order for chromium to work... (see above in the thread) ?

Any idea ?

Thx

[Alex1844]

I have a problem with wrapper running on a different machine (10.15.2 if that matters). It works just fine on my machine (10.15.5) where I created the wrapper and put it in /Applications and it works for multiple users, but it keeps crashing on a different machine. Something seems to be missing from the wrapper that exist on my machine. I have noticed that the final wrapper with the latest update is some 60MB smaller than the one before.

[Alex1844]

The Run Test reports it cannot find the FreeType font library

[Gcenx]

@Alex1844 you didn’t copy the runtime into the wrapper, Beta3 I’d separated the runtime from the wrapper to test a feature

[Alex1844]

I did this on my machine per instructions "The wrapper does not contain the usual embedded Runtime, instead download and unpack the attached version into ~/Library/Application Support/Wineskin/Runtime"

Where do I copy it in the wrapper?

[Gcenx]

Maybe the edit didn’t save, the runtime if you want the wrapper to be portable needs to be placed into /Frameworks within the wrapper

The next wrapper version will have it embedded again and will be showing up for direct download in the next winery versions to be uploaded (a little busy with macport stuff)

[Alex1844]

That fixed it, thanks

[drpatchadams]

I USE PCXS2 for PS2 games emulation on my MacBook Air 4 Gb RAM Catalina Using WINE Last Unofficial versión.

I installed IT and configurated properly but when I RUN IT

Wine C+++ runtime library error apears

And in the program Windows apears This at the End:

convert.fx:21:10: error: syntax error, unexpected NEW_IDENTIFIER

Please help !!

Here is the summary.

PCSX2 1.6.0-20200506140834- compiled on May 6 2020 Savestate version: 0x9a0e0000

Host Machine Init: Operating System = Microsoft Windows 7 Service Pack 1 (build 7601), 64-bit Physical RAM = 4095 MB CPU name = Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz Vendor/Model = GenuineIntel (stepping 01) CPU speed = 1.999 ghz (4 logical threads) x86PType = Standard OEM x86Flags = bfebfbff 7ffafbbf x86EFlags = 2c100000

x86 Features Detected: SSE2.. SSE3.. SSSE3.. SSE4.1.. SSE4.2.. AVX.. AVX2.. FMA

Reserving memory for recompilers...

Loading plugins from C:\Program Files (x86)\PCSX2\plugins... Bound GS: GSdx32-SSE4.dll [GSdx 20200506140834 (MSVC 19.25 SSE4.1/AVX) 1.2.0] Bound PAD: LilyPad.dll [LilyPad (20200506140834) 0.12.1] Bound SPU2: Spu2-X.dll [SPU2-X 20200506140834 2.0.0] Bound CDVD: cdvdGigaherz.dll [cdvdGigaherz 20200506140834 0.11.0] Bound USB: USBnull.dll [USBnull Driver 20200506140834 0.7.0] Bound FW: FWnull.dll [FWnull Driver 20200506140834 0.7.0] Bound DEV9: DEV9null.dll [DEV9null Driver 20200506140834 0.5.0] Plugins loaded successfully.

(GameDB) 9858 games on record (loaded in 1138ms) HotSwapping to new ISO src image! HLE Notice: ELF does not have a path.

Initializing plugins... Init GS Init PAD Init SPU2 Init CDVD Init USB Init FW Init DEV9 Plugins initialized successfully.

Patches: No CRC found, using 00000000 instead. Opening plugins... Opening GS Opening PAD Failed to init the freetype face Current Renderer: Direct3D 11 (Hardware renderer) Opening SPU2 Opening CDVD isoFile open ok: C:\users\crossover\My Documents\PCSX2\Games\street fighter.iso Image type = DVD

• CDVD Disk Open: DVD, Single layer or unknown:
• • Track 1: Data (Mode 1) (1663376 sectors) Opening USB Opening FW Opening DEV9

convert.fx:21:10: error: syntax error, unexpected NEW_IDENTIFIER

[Gcenx]

@drpatchadams this isn’t a Wineskin issue but a user issue. The application launched and gave an error of missing C++ libraries (you need to instal the required version using the Winetricks menu)

First your attempting to use PCXS2 1.6 that requires DirectX11 support when wine on macOS only has DirectX9 support, you should be using PCXS2 1.4.

Second issue is your using a MacBook Air, these already have terrible cooling to begin with that plus the Intel iGPU.

Please Note;

I’ve had PCXS2 1.4 running on Mojave and Catalina with pitiful performance attempting to play Armored Core 2 (mid 2014 14inch MacBook Pro)\ Unless your using a recent MacBook Pro/iMac with a dedicated GPU you will never get playable performance out of PCXS2, the emulator isn’t exactly optimized.

[shinra-electric]

Try out the PCSX2 64-bit native build that’s in testing at the moment...

[drpatchadams]

Thanks I Will try both options

1)PCXS2 1.4 with directX9

2) And the newer 64 bit PCXS2

Do you have Download link ?

Can't find IT in PCSX2.net

[kode54]

Can't find IT in PCSX2.net

The blue colored word "PCSX" in the post directly above yours is a link to it.

[drpatchadams]

Thanks I am Going to try

Where I can find the winetricks menú ?

[Gcenx]

[drpatchadams]

Thanks I installed PCXS2 1.4

It comes in the instalación With visual C ++2015

Directx9

Know when I RUN IT

ITs stops with This error

Intel(R) HD Graphics 5000 (8.19.15.4352) :68:14: error: syntax error, unexpected NEW_IDENTIFIER