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

With a minimum requirement of macOS/OSX 10.8.With a recommended requirement of macOS/OSX 10.9.

Download;Unofficial Wineskin Winery.appUsing the above just download then run, directly download the current master wrapperDon't use keka to unpack as it currently breaks any downloaded applications after unpacking!

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 hosted on GitHub , follow the correct Wineskin engine naming style to download Wine to be repacked into Engines.

Spoiler

Examples;

WS9Wine3.15

The above example would download portable-winehq-devel-3.15-osx.tar.gz and repack into WS9Wine3.15

WS9Wine64Bit3.15

The above example would download portable-winehq-devel-3.15-osx64.tar.gz and repack into WS9Wine64Bit3.15

WS9WineStaging3.15

The above example would download portable-winehq-staging-3.15-osx.tar.gz and repack into WS9WineStaging3.15

WS9WineStaging64Bit3.15

The above example would download portable-winehq-staging-3.15-osx64.tar.gz and repack into WS9WineStaging64Bit3.15

This feature was added incase Winehq added a new wine version and I'm not able to update the list on GitHub , so if tomorrow Wine3.16 was released and compiled versions were available for download, its possible to just make a list and add them yourself

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

PortingKit
Anyone who uses PortingKit and is running OS X10.8 to 10.14 is now using Unofficial.

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

Great work! I think the best thing about the update is the fact that gpu detection is now disabled by default. I feel like a lot of people unaware of the simple fix to get wrappers working again on High Sierra.

Great work! I think the best thing about the update is the fact that gpu detection is now disabled by default. I feel like a lot of people unaware of the simple fix to get wrappers working again on High Sierra.

Thanks;

But that is not the case, the GPU detection is just fixed (Apple screwed something up with Intel cards in HS), if its unable to detect the gpu its defaulted to Intel since that's what Apple screwed up.

Default setting changed was Mac Driver and all the new libs so 64bit Engines and Staging engines just work when built without editing anything.

Side Note;
I was messing with Winey but Xcode 9.3 gave up and now crashes for no reason, I might build a VM and see if I can get Winey correctly redirected to another host.

If it was try to run wineskin-2.6.2 once to give it permission to run on your system, don't make any changes just make sure you can launch it. I have have my system to set to run "applications from anywhere"

This is lightly due to it not being signed code since I don't have a developers license and also won't pay for one

No, after creation finished. I have my permissions set to the next higher level, but you can usually bypass if you right-click on it and select 'open'.

If it does work cleanly otherwise, maybe doh123 can adopt and sign it as 2.6.3?

I used terminal command to enable the lowest option to allow apps from anywhere, ages ago since I use other software that are not signed, the right click open trick does not always work since it core app calls other unsigned binaries.

sudo spctl --master-disable

If it was signed it would work just fine, I remember doh123 said these days they don't have time to work on the project and since the GPU fix was submitted 2017-10-03 I'm not sure when doh123 will be back again.

If you want I could explain how to get most of it working without even updating the base wrapper so it auto disables the GPU check and also defaults to MAC Driver, then just add the updated Framework Folder since those are all signed.

EDIT; Please download again it seems the copy I uploaded was missing a folder and wineskin didn't like that....

But that is not the case, the GPU detection is just fixed (Apple screwed something up with Intel cards in HS), if its unable to detect the gpu its defaulted to Intel since that's what Apple screwed up.

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?

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.

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.

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

In case you are clueless about that, you can just upload you code somewhere and I can check the differences between it and the original Wineskin source code

That's easy to do with Terminal commands.

Let me look over you version some more and I will do a pull request with the changes, I got the idea already from your updated code.

Seems you have detection built in for what type of engine you try to install nice, for Staging64bit engines they don't like redirection of libs or it won't create syswow64 or program files (64bit) correctly.

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.

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.

Renaming also restored and improved, the new upload will rename wine/wine64/wine-preloader-wine64-preloader as needed depending on the engine used.
This is done by directly checking inside wswine/bundle/bin then does the correct naming, this solves the problem of Staging & Staging64 wrappers not always building correctly due to wine/wine64 being renamed will break them.
Instead for Staging & Staging64 the wine-preloader/wine64-preloader are renamed, since those are the used processes.

Okay, I've installed the new wrapper, cleared the tmp folder*, and made a new wrapper. Wineskin is still hanging, unfortunately.

*Open the hard drive, hit command+shift+period to reveal hidden files, open the tmp folder/alias, move everything to the trash. Right?

What ever way works for you, I use Finders "Go To Folder" /tmp

Clear it out, you might find temp files from Wineskin/wrappers.

I don't know if your wrapper ever really got created I still think its also because didn't give it permission, so I made a Staging3.6 wrapper compressed as dmg image and added the folder that contains the wrapper update. Try to use that instead I guess since its working on my system and also working on another install on a USB hard drive that's a clean install.