I think it may have something to do with an icon cache, but again, I don't know.Īs for the. As I said though, this might break the code-signature/notarization, and it would also require converting an icon to that format.Īnother idea I have, though it'd require some looking into (as I'm not sure how it works, I just know it doesn't break the code-signature/notarization) is by setting the icon the way that CandyBar and/or LiteIcon do (I'm not sure if they do it the same way or not, and I'm not sure if either of their source codes are available). One idea I have (that may possibly break the code-signature/notarization, I'm not sure) is setting the icon with a Icon? file in the application's root directory. I believe that there may be other ways to set the icon, without breaking the code-signature/notarization. The idea is having code-signed/notarized master wrapper with all the needed entitlements will negate the need to do this for the Engines, that’s part of the reason for dropping the wrapper scripts within wswine.bundle, who’s format lightly needs to be correct still. The only solution I can come up with currently is embedding the ist and ObjectiveC_amework into the binary, meaning the ist within the last wrapper can be altered without breaking the code-signature/notarization on WineskinLauncher. The irritating Wineskin problem I’m facing is code-signing/notarizing a master wrapper, once the ist/icon etc are altered the code-signature is invalidated. Sometime finding time to also bug test CrossOver-20-beta releases, while ensuing it will still be compatible with Wineskin
#WINESKIN WINERY GAME LAGGY UPDATE#
Recently the majority of my time has been spent maintaining homebrew-wine/macports-wine/Wineskin Engines and communicating with a wine contributor to resolve macOS specific wine bugs.Ĭurrently trying to get mingw-w64 updated to 8.0.0 while ensuring mingw-gcc packages don’t break, that’s ignoring the mingw-gcc update to gcc-10.2.0 issues (libtapi/cctools/ld64 etc) (I should edit the release section to indicate this) While donations are appreciated, I now have a developers account thanks to the contributions. Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned. Subject: Re: Inintial macOS Catalina support ( #26) So I'll need to get in touch with the program author and ask him to allow his program to run as admin. If an application complains about a lack of administrator privileges, file a bug running Wine as root probably won't help.
#WINESKIN WINERY GAME LAGGY WINDOWS#
As the Wine FAQ says:Īs far as Windows programs are concerned, you are running with administrator privileges. Thank you!ĮDIT: 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.
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.Īs expected, I can't codesign or notarize it, but it doesn't ask me for permissions each time I run it. I've been away from Catalina for a while, but did some brief testing with Wineskin today. Could you please help me on this?Ġ009:fixme:winsock:set_dont_fragment IP_DONTFRAGMENT for IPv6 not supported in this platformĠ035:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFA, 029FFDDCĠ009:fixme 🐚InitNetworkAddressControl stubĠ009:fixme:mpr:WNetGetUniversalNameW (L"C:", 0x00000001, 0033EA40, 0033EA0C): stubĠ009:fixme:mpr:WNetGetUniversalNameW (L"C:", 0x00000001, 0033E5F0, 0033E5BC): stubĠ009:fixme:mpr:WNetGetUniversalNameW (L"C:", 0x00000001, 0033E17C, 0033E148): stubĠ009:fixme:imm:ImmReleaseContext (00010054, 09789948): stubĠ009:fixme:imm:ImeHandleNotify WM_IME_NOTIFY:IMN_SETOPENSTATUSĠ009:err:ole:CoGetClassObject class could be created for context 0x17Ġ009:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0033FD24 (I said “being”, because the crawl already starts while loading such a windowed application, and the crawl ends (=begins to run smoothly) once a 3D game is loaded and in foreground.I have tried WineCX19.0.1 with 2.9.0.6 wrapper but my app fails to start. As soon as there’s a windows being created through the Windows-API it crawls.
0 kommentar(er)
