Initial macOS Catalina support about wineskinserver HOT 276 CLOSED

@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

from wineskinserver.

@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.

from wineskinserver.

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!

from wineskinserver.

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.

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

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.

from wineskinserver.

@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.

from wineskinserver.

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

Ciao.
L.

from wineskinserver.

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

from wineskinserver.

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)

from wineskinserver.

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.

from wineskinserver.

@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

from wineskinserver.

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.

from wineskinserver.

@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

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

@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....)

from wineskinserver.

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

from wineskinserver.

@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

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

@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.

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

@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.

from wineskinserver.

from wineskinserver.

@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

from wineskinserver.

from wineskinserver.

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.

from wineskinserver.

@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.

from wineskinserver.

@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.

from wineskinserver.

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.

from wineskinserver.

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.

from wineskinserver.

from wineskinserver.

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

See bug 40613

from wineskinserver.

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.

from wineskinserver.

@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

from wineskinserver.

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

from wineskinserver.

When do you expect to release the next wrapper?

Thanks for the the great work you are doing.

from wineskinserver.

Hi @Gcenx, any idea of a release date ?

Thx for great work!

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

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?

from wineskinserver.

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

from wineskinserver.

Thanks for clarifying that.

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

from wineskinserver.

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

from wineskinserver.

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.

from wineskinserver.

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.

from wineskinserver.

@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

from wineskinserver.

Yes, an Engine that only includes wine64.

Thanks for the clarification

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

@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!

from wineskinserver.

@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.

from wineskinserver.

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!

from wineskinserver.

@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

from wineskinserver.

@Gcenx Are you considering to do the second option?

from wineskinserver.

@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

from wineskinserver.

@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!

from wineskinserver.

@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.

from wineskinserver.

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

from wineskinserver.

@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...

from wineskinserver.

@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

from wineskinserver.

@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.

from wineskinserver.

@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

from wineskinserver.

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.

from wineskinserver.

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

from wineskinserver.

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.

from wineskinserver.

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.

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.

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?

from wineskinserver.

@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.

from wineskinserver.

@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.

from wineskinserver.

@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

from wineskinserver.

@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.

from wineskinserver.

@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

from wineskinserver.

@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.

from wineskinserver.

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

from wineskinserver.

@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.

from wineskinserver.

@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?

from wineskinserver.

@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.

from wineskinserver.

@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

from wineskinserver.

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.

from wineskinserver.

@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

from wineskinserver.

@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.

from wineskinserver.

@emendelson precisely

from wineskinserver.

@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.

from wineskinserver.

@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

from wineskinserver.

@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.

from wineskinserver.

@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

from wineskinserver.

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)?

from wineskinserver.

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

from wineskinserver.

from wineskinserver.

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

from wineskinserver.

The latest versions are working extremely smoothly. Thank you!

from wineskinserver.

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

from wineskinserver.

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

from wineskinserver.