Jump to content

  • Log in with Facebook Log in with Twitter Log In with Google      Sign In   
  • Create Account

ovvldc

Member Since 24 Nov 2010
Offline Last Active Today, 11:17 AM
***--

#107742 Mojave and Wine versions

Posted Gcenx on 13 September 2018 - 05:13 PM

A1, Wineskin unofficial Update is Mojave ready, it’s even Post-Mojave ready bar WSGamma.

A2, always try the most recent Staging version abalone unless appdb says otherwise.

A3, DX10+ should work once the missing features for DXVK are added to MoltenVK same for DX11. DX12 also the same as adding missing features for DXVK also affect VKD3D support directly.
But this is only if the game/app is 64Bit until the solution for running 32bit code Post-Mojave is complete.

A4 post2, CX17.5.1 and the compiled Staging3.15gnuTLS would be the best for Steam and other online platforms.

A5, I believe the version I had Skyrim loading SKSE was CX17.5.0/17.5.1 and also Staging3.6.

A6, Blah really don’t worry about that too much Codeweavers will figure that out in under 2 years, since the majority of there income I via there macOS porting services & now also Valve.


#107737 WineStaging3.XgnuTLS & WineStaging64Bit3.XgnuTLS

Posted Gcenx on 12 September 2018 - 03:21 PM

View Postovvldc, on 12 September 2018 - 09:07 AM, said:

I've tried the WineStaging3.15gnuTLS engine, and I can get Skyrim to work. SKSE_loader seems not to work (SkyUI turns itself off), so I am still messing with it.

Specifically, I start SKSE_loader from Wineskin, and that in turn starts Steam and that seems to start the Skyrim launcher, and then that can start the game but no SKSE gets injected :(. Should I use the SKSE plugin preloader (https://www.nexusmod...rim/mods/75795/)? Or is there another solution? Also, installing and setting msvcr90 to native did not work. Or maybe it is this bug: https://www.winehq.o...uly/446947.html

I did notice the following in my Wine log, which if followed by a lot of errors and seems to point to an oversight on your end:
00be:err:d3d:wined3d_check_gl_call >>>>>>> GL_INVALID_ENUM (0x500) from extension detection @ /Users/gcenx/Downloads/wine-3.15/./dlls/wined3d/adapter_gl.c / 3674.

I also see the following:
0063:err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting
Does that mean I should install a native version? Answer: for some reason, that does not help. But I think that I've seen this quite often.

I have not even tried to use SKSE with the current Wine versions so I don’t really know what’s gonna be required o get it working without looking into it on my end.

That error is not an issue with the compile but an issue with that line upstream, I got some confirmation before posting back so not the only one seeing that issue and they are not using my compile.

Not loading the file I’m not sure what the issue is with that but yeah I have seen that before I think even in Crossovef.

The trunk error is the new trunking feature added to staging instead of faking the trunking in Windows they are currently trying to build it into Wine instead of passing off assembly code back as a response like it use too, that’s what cause things like Steams web store to not work and also why most anti cheat systems fail to work with wine.
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

View Postovvldc, on 12 September 2018 - 09:10 AM, said:

Another question, due to my head being overstuffed lately: Should I use a 64bit engine to smooth transition into Mojave and the 64bit future? If so, I will add to my post for beginners.
It currently makes no difference if your using 32Bit or 64Bit for Mojave since even 64Bit engines still contain 32bit components, this is more a winehq issue they need to finish getting wine to run on only 64Bit threads even for for 32Bit components
Wineskin is already 64Bit bar WSGamma.

Post-Mojave should be the removal of 32bit and the time we really need to be worried about of codeweavers are not finished with there solution in time, if Wineskin then needs to make changes to run said new Wine versions we will, properly just blocking off old wine versions that won’t work and only showing compatiabke versions will cause less issues.


#107701 WineStaging3.XgnuTLS & WineStaging64Bit3.XgnuTLS

Posted Gcenx on 04 September 2018 - 12:33 PM

View PostNRG, on 04 September 2018 - 04:44 AM, said:

this wine staging version 3.15 steam (x86) works again with Pro Evolution Soccer 2017, but it doesn't load any sound:


0075:err:module:load_builtin_dll failed to load .so lib for builtin L"xaudio2_7.dll": dlopen(/Applications/GAMES/Pro Evolution Soccer 2017/PES2017.app/Contents/Frameworks/wswine.bundle/lib/wine/xaudio2_7.dll.so, 258): Library not loaded: /opt/local/lib/libavcodec.58.dylib
  Referenced from: /Applications/GAMES/Pro Evolution Soccer 2017/PES
0075:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\\windows\\system32\\xaudio2_7.dll"
0075:err:ole:CoGetClassObject no class object {5a508685-a254-4fba-9b82-9a24b00306af} could be created for context 0x1

All the wine stagings until v. 2.21  and all the crossover engines work without any issue with this game

all the officials wine staging for mac after v3 until v.3.15  crash the game during his launch

You could replace with a native xaudio2_7.dll should give you audio until I add the additional dylibs to make the new implementation of xaudio work directly even thought it might not be as stable as a native version.

>libavcodec.58.dylib;
I'll need to unpack all of the ffmpeg package and add that to the master wrapper to get that working. Pretty much what I did to get Steam downloading working in the new master wrapper using this engine, I extracted all components needed by gnuTLS to get that running and added it to the new master wrapper version.

EDIT;
I have added the everything ffmpeg was asking for on my end so now I can launch Skyrim without needing to apply "winetricks xact"


#107688 Wine 3.13 and Vulkan Support Not Working Yet. Any ideas?

Posted Gcenx on 27 August 2018 - 09:16 PM

View Postovvldc, on 26 August 2018 - 06:27 AM, said:

Automation is a good thing for repetitive tasks, no need to be self-deprecating about it :)

I blame being from England and been in the states for years now lol.

Yeah I did it since I was getting close to the maximum allowed amount of data on GitHub so after the idea was floated to just use repacking directly from winehq instead so I just a dirty implementation to get it working, it serves the purpose for my fork so it’s good enough. Nobody has complained yet so I’m sticking with its good enough.

As for Vulkan I properly won’t be adding any builds for download through Winery.app as it’s currently useless for playing any commercial games, I may add them for download from mega under a sub-folder. I’m sure soon macOS prebuilt will start to come with Vulkan support built right in, but if they are not I will Upload at least one or two Vulkan enabled builds to Winery.app


#107650 Wine 3.13 and Vulkan Support Not Working Yet. Any ideas?

Posted Gcenx on 23 August 2018 - 12:40 PM

View Postovvldc, on 23 August 2018 - 04:23 AM, said:

Yes, that was flagged and bisected almost immediately, see https://www.winehq.o...st/130767.html.

Not sure if it has been addressed yet.

It's been addressed already upstream, I was focused on just getting a working build environment that I didn't even check for an open bug report.

The images I posted on Discord;

Running Cube from within Wineskin from the Windows Vulkan SDK
Posted Image

vkquake;
Posted Image

And then with the addition of the Crossover hack for Steam browser;
Posted Image


#107640 Wine 3.13 and Vulkan Support Not Working Yet. Any ideas?

Posted Gcenx on 20 August 2018 - 07:28 PM

I know not everyone used Discord so I thought it best to also post the update here.

I managed to compile wine64 (32 & 64Bit) with Vulkan support it was a pain to say the least, when I’m free I’m going to try tracking down and howto do it in a simpler way to compile for Vulkan support.
But with the current state of wine for macOS it’s not going to be too useful since we only get access to Vulkan for 64Bit and it’s also missing Vulkan components that DXVK needs to work. Maybe we could try VKD3D but the same limitations apply, only 64Bit applications can make use of it.


#107635 CrossOver Engine 17.5.1 (WS9WineCX17.5.1 & WS9WineCX64Bit17.5.1)

Posted Gcenx on 10 August 2018 - 03:07 AM

Users of my "Unofficial Update" can directly download this via Winery.app



Downloads Folder



17.5.1 CrossOver - July 25, 2018
  • Application Support:
    • Fixed a bug that prevented installing and launching games in newly downloaded Steam bottles. Users can now install the latest Steam app and use without modification.
  • macOS:
    • CrossOver 17.5.1 includes preliminary support for the beta version of macOS Mojave 10.14.
Fixed Source Code < contains both 17.5.1 & 17.5.0
Unlike the one directly downloaded from CodeWeavers this will compile correctly as long as you provide the needed dependancies.
Does not include the wineboot fix in source code.


Please Note:
Using this engine with Stock Wineskin-2.6.2 you need to add your own libpng16.16.dylib since I compiled it using that instead of libpng15.15.dylib.
Also require a copy of gnuTLS installed or you won’t be able to download anything from Steam.

Reuploaded - August 28th, 2018;
Due to my missing gnuTLS when compiling Steam would not work, so recompiled with gnuTLS support along with some other additions when compared to stock CrossOver17.5.1


#107568 32bit and OpenGL going away next year on MacOS

Posted Gcenx on 14 July 2018 - 04:42 PM

View Postovvldc, on 14 July 2018 - 03:13 PM, said:

I guess we have our answer. https://source.wineh...4855ab547f8d5fc winemac: Implement Vulkan driver on top of MoltenVK.

This route made the most scene, still not the ideal solution of having a pure Metal driver but it's better then being stuck on OGL.
At least now they can focus on improving Vulkan to D3D and we see the benafits.


#107500 CrossOver Engine 17.5.0 (WS9wine17.5.0)

Posted Gcenx on 21 May 2018 - 11:22 PM

Download Folder


Fixed the source by removing the missing reference of a missing file within winedebug, but Wine launched a few of my games just fine.


Source Code  <- Original Source Code

Change Log


Note:
Both were compiled using 10.13SDK 10.9SDK but set min version to 10.8, I only have access to 10.13 so I can't test below.
"wineboot" will show when on wrapper creation & rebuilding.
You need to use macdriver with these I did not compile with X support.

I have uploaded the fixed Source code, incase anyone wanted it.


#107417 Questions about the state of the art of Wine and Wineskin

Posted Gcenx on 27 April 2018 - 05:58 PM

View Post1Mac, on 27 April 2018 - 05:02 PM, said:

Great, thank you for your answers! I'm long suspected that Wineskin wasn't really making the most out of 64-bit engines, so I'm very excited to try your updated wrapper out.
Thank you, it's just to hold people over until a real update is released.

Quote

Maybe I misunderstood, but on the thread you say that Staging64-bit engines won't build properly "in the default wrapper." Are you saying that they will build properly in your wrapper?
That is correct with the stock wrapper, you can not make Staging64-bit engines work or even build correctly.
Mine now will work with and build Staging64-bit engines correctly.
(the wineskin-2.6.2 you download via WineSkin Winery directly aka stock wrapper)


Quote

I guess my fear is that some future update will remove OGL support from MacOS entirely. That's certainly been Apple's MO in the past, to go from "we're no longer supporting x" to "x will no longer work after the latest update," where x = OS Classic, 32-bit applications, etc. Maybe that doesn't make sense in the case of OGL.
It's Apple it is possbile but that's where MoltenVK will come into play, or Crossover will build another way to still use wine on macOS since they bundle modified wine with their product.


View Post1Mac, on 27 April 2018 - 05:32 PM, said:

Cool, thank you. That article was part of what I was thinking of when I asked my question. I guess you all are saying that Apple hasn't been updating its OGL implementation but also hasn't removed it. Is that right? Would I still be able to run OGL games if I upgrade to High Sierra? Is there any chance Apple would ever remove OGL implementation entirely from future OS's? Would Vulkan hypothetically be able to fill that void?
OGL is currently still included with High Sierra, I still use multiple wrappers I have made without issue once I fixed the GPU detection issue.


What I do when ever a new macOS version is released I download the installer but install it onto an External Drive to test it out to ensure I can use what I need before upgrading me internal drive, that way no surprises when something stops working.


#107404 Wineskin Unofficial Update

Posted Gcenx on 23 April 2018 - 06:28 PM

Re-uploaded wrappers with additional libs, now wine/wine64 should be good
As you can see below wine/wine64 are happy with them and you can see I do not have XQuartz installed on my system so wine/wine64 are using the libs provided in frameworks.


Posted Image

The two missing libs are by default missing when using normal WineHQ installs.
A few libs included with Slice's update6 were giving me errors about version mismatches or just out right ignoring them, these are read fine by  --check-libs and I no-longer see errors about wrong version of libs when checking wine run logs.


#107359 Wineskin Unofficial Update

Posted Gcenx on 05 April 2018 - 07:07 PM

View Postovvldc, on 05 April 2018 - 06:52 PM, said:

Thanks Gcenx! Did you update the download at the top of this thread? Edit: never mind, you did.

I haven't used the 'kill Wineskin processes' button in forever because it didn't work for me some time ago and now I just use the application monitor. It would be nice if it worked again, and i don't mind if it kills of other Wine stuff. I only run one at a time.

Yeah I noticed since I now only use MAC Driver that it no longer worked and like you I had to keep "Activity Monitor" open all the time to make sure I could kill everything, wouldnt be the first time I remade wrappers over not noticing processes were still open that caused the install problems to begin with.

For the fix just use 2.6.4 it will kill anything wine/wine64 related processes, I know it's overkill but I tried other ways to kill everything just inside the wrapper but no luck but since this way works I guess it's fine.

The Downloads folder symlinking was added as I get lazy always needing to navigate to the Downloads, I started to notice some of my wrappers kept growing in size as I forget that Downloads is inside the wrapper...


#107353 Wineskin Unofficial Update

Posted Gcenx on 04 April 2018 - 02:07 PM

View PostdankoB, on 04 April 2018 - 01:22 PM, said:

Oh...hahaa, kind of funny I guess. I must have disabled it out of habit I suppose, without realizing. I thought it was actually disabled. So GPU detection now works on High Sierra again?

Yep GPU detection is working again on High Sierra with this.



EDIT;
Ever noticed that wine64 wrappers don't show the wrapper name instead it's just wine64?
I'm currently testing out a fix for this little issue.


EDIT2;
Finished quicker then I thought, now Wine64 processes will take on the wrappers name instead of just showing Wine64
This change also does not affect 32bit builds so it's still universal.


EDIT3;
Added symlink for Downloads folder and added control to Wineskin interface also testing a fix for "Kill Wineskin Processes" since it never worked right when using "MAC Driver"

"Kill Wineskin Processes" works but to work it has to force close anything related to wine/wine64/Windows, so other Wine/wrappers/applications would be affected by this. Since no one ever mentioned "Kill Wineskin Processes" not working, I guess its not used much.


#107351 Wineskin Unofficial Update

Posted Gcenx on 03 April 2018 - 08:51 PM

View Postovvldc, on 03 April 2018 - 07:54 PM, said:

Ok, it works now, great :) Thanks for spotting the missing folder!

Thanks for catching it and posting feedback.


#107343 Wineskin Unofficial Update

Posted Gcenx on 02 April 2018 - 04:01 PM

Last Updated - September 15th/2018
Current version Wineskin-2.8.6Beta4

Unofficial Wineskin Winery.app

Using the above just download then run, directly download the current master wrapper

Don't use keka to unpack as it currently breaks any downloaded applications after unpacking!


List of modifications in the Wineskin App (WineskinApp)
  • The Auto-detect GPU feature should never cause malfunction in the port;
  • The Auto-detect GPU feature should have a much bigger accuracy and detect the memory size of integrated video cards as well;
  • The Retina Mode can be enabled from the Screen Options window;
  • Kill Wineskin Processes should kill ALL Wineskin processes.
  • Images (not .icns files) should also be accepted has wrapper icons;
  • LNK files should be able to be selected as a port's run path, so Wineskin can extract the path and flags from it;
  • Winetricks installation can be silent (with no windows) so it's much faster;
  • Disables X11 option if XQuartz is not installed.
  • The first Advanced tab (Configuration) should be much more simple in the first section:
    • The Windows EXE should use Wineskin syntax, including the drive and the flags, (eg. "C:/Program Files/temp.exe" --run) instead of using a macOS reference path (eg. /Program Files/temp.exe) and the flag apart (eg. --run).
  • Advanced Tab "Disabled Mono & Gecko installation" checkbox (allows install to be enabled for "Wrapper Refresh" )
  • Able to detect XQuartz installed via macports
  • Integrated fntoggle directly into Wineskin.app, now you can have Standard F keys during wrapper usage.
  • Wine versions not compatible with "mac driver" will have that option disabled.
  • gnuTLS included so supported engines can use it, aka using WineCX17.5.1 Steam will download again.
  • Added components of ffmpeg (will be swapped later for a version with less dependancies)
  • Includes current freetype.6.dylib needed for ffmpeg and other later additions
  • good_freetype.6.dylib used by updated fontfix included in updated "WineskinStartupScript" (will be converted to internal wineskin.app option later < Feature is no longer required.
List of modifications for the Master Wrapper (WineskinLauncher)
  • Many fixes when dealing with newest engines.
  • Closes XQuartz on exit if used.
  • Mono & Gecko install is disabled on wrapper creation
  • Able to use XQuartz installed via macports
  • fntoggle will be set on wrapper started and unset on wrapper exit.
  • A cleaner FontFix while still using a current version of libfreetype.6.dylib
List of modifications in the Winery App
  • Engine Ordering
  • Connects to custom WineskinServer
  • Download engines hosted on WineskinServer
  • Directly download current "Unofficial Master Wrapper Version"
  • "Update" feature will display when new "unofficial Wineskin Winery.app" version is available
  • Wine versions that Require XQuartz to function are hidden by default.
  • Able to read from a local EngineList.txt (in the same folder as Winery.app)
  • Download and repack Engines from winehq
The minimum macOS/OSX requirement is 10.8.


Download;
Unofficial Wineskin Winery.app

I don't see text anymore with your new update!!!!!
This is due to "Contents/Resources/Scripts" not being replaced, I didnt want to forcibly replace it each wrapper update incase anyone added custom items to the Startup & Shutdown scripts, you can simply remove the "Scripts" folder and update the wrapper again or remove the following;

WineskinStartupScript
"$CONTENTSFOLD/Frameworks/wswine.bundle"
if [ -d "lib" ]; then
	cd "$CONTENTSFOLD/Frameworks/wswine.bundle/lib"
	ln -s ../../libfreetype.6.dylib libfreetype.6.dylib
fi

cd "$CONTENTSFOLD/Frameworks/wswine.bundle"
if [ -d "lib64" ]; then
	cd "$CONTENTSFOLD/Frameworks/wswine.bundle/lib64"
	ln -s ../../libfreetype.6.dylib libfreetype.6.dylib
fi

WineskinShutdownScript
"$CONTENTSFOLD/Frameworks/wswine.bundle"
if [ -d "lib" ]; then
	cd "$CONTENTSFOLD/Frameworks/wswine.bundle/lib"
	rm libfreetype.6.dylib
fi

cd "$CONTENTSFOLD/Frameworks/wswine.bundle"
if [ -d "lib64" ]; then
	cd "$CONTENTSFOLD/Frameworks/wswine.bundle/lib64"
	rm libfreetype.6.dylib
fi

Removing those sections and changing Engines even if its the sameone your already using will solve any issues.

About Local EngineList.txt feature;
This feature was added so winery.app can read a local EngineList.txt file, create a text file with that name in the save directory as winery.app this will now override the copy host on GitHub , follow the correct Wineskin engine naming style to download Wine to be repacked into Engines.

Spoiler


Please make sure to clear out your users /tmp folder if you have any issues creating wrappers.

Now works with "Porting Kit!!!!!"
VitorMM updated PortingKit to work with the next official release once its ready, so that mean Wineskin-2.8.3 is compatible with "Porting Kit" , current verison will throw some errors about not finding "WineskinMenuScripts" and it's contents but the wrapper will be created and work as long as you pick "mac" unless you have XQuartz installed then you can use "x11"

A Very Special Thanks to;
doh123 - For creating Wineskin
VitorMM - For The new code base along with all the included features!
NRG & dankoB - For Testing the initial releases