Updated (January 2nd 2021)
Wineskin.Winery.txz was updated and is required for Wineskin-2.9.0.7-rc2 due to internal changes that were required for Rosetta2 compatibility.
DXVK Support!!!!;
- Only tested on a mid 2014 13in Macbook Pro and base mode M1 Mac Mini
- 64Bit Engine (WS10 or later Engines will suffice)
- macOS 10.13 or greater (might work below but I haven't tested)
- winetricks menu only shows compatible DXVK verbs
Apple Silicon Support;
This will now function under Rosetta2 use WineCX19 or greater, direct draw & Direct3D won't function so things like cnc-ddraw & DxWnd can be used to workaround this limitation.
Please Note;
The previous master wrapper Wineskin-2.9.0.7-rc1 won't be able to update to this master wrapper version as the structure has changed, while it's technically possible to update a current wrapper to the rc2 I won't provide any support for this so please create the wrapper over and manually move over the wineprefix files currently located with the wrappers /Contents/Resources directory into the newly created wrapper.
The Wineprefix location will also be moved in for rc3
Previous changes;
#### Updated (September 6th 2020 6:23PM)
The Master wrapper and Runtime have been removed, now the current Winery release and Beta versions will both download Wineskin-2.9.0.7-rc1 wrapper directly
#### Updated (June 28th 2020 NYC 4:40 PM
`WineskinLauncher` should no longer request Accessibility permissions due to a change made within ObjectiveC_Extensions, IOKit is no longer linked.\
The updated ObjectiveC_Extenstions should have improved GPU detection\
The prior `fixWinePrefixForCurrentUser` function was restored\
Runtime will now be loaded from `~/Library/Application Support/Wineskin/Runtime` before any other location, XQuartz is checked last.
#### Winery Updated (July 12th 11:30 PM
- Engine Repacking from Winehq releases strips additional binaries
- Engine Repacking skips compression
- Added the ability to download any WS10 Engine from releases
- 1.8.4.2EngineList.txt is used for the online EngineList (to avoid conflict with current version of PortingKit)
- Manual Download button should open my MEGA directory correctly
#### Wineskin-2.9.0.7-Beta3
The wrapper does not contain the usual embedded Runtime, instead download and unpack the attached version into `~/Library/Application Support/Wineskin/Runtime`
#### Winery Updated (June 28th 4:40 PM
Slight internal changes, `View Wine Release Notes` should now work correctly, updated ObjectiveC_Extenstions
#### Updated (June 20th 2020 NYC 1:05 PM
Updated the Runtime again, `Wineskin` and `WineskinLauncher` were not code-signed, this should now allow the wrapper once created to request permissions to access restricted directories on macOS Catalina\
Edit: There really are unsigned now, Xcode 11 was being a pain
#### Winery Updated (June 20th 1:20 PM
When downloading the master wrapper permissions will be set, on wrapper creation permissions will again be set so the base wrapper should be owned by everyone this "should" allow newly created wrappers placed into `/Applications` to launch regardless of who originally created it\
Edit: There really are unsigned now, Xcode 11 was being a pain
#### Updated (June 18 2020 NYC 11:10 PM
Wrappers when added to `Full Disk Access` will now have these permissions\
These permissions will only apply to that wrapper only, this won't work correctly with wrappers upgraded from the prior master wrapper due to the invalid Bundle ID that prior versions generated
#### Updated (June 16 2020 NYC 6:50PM
- 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`)
- `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
Updated (May 26 2020 NYC 8:30 AM
- Updated the Wrappers Runtime
- Added a correction to `renamedefaults.reg` @PlanetIrata
- `Winehq Engine Launch` should now function better
- `NCurses` library is patched to use stock terminal database over macports
- `libffi` was rebuild with `mkostemp` disabled so it functions on systems without this function
Updated again (April 26th NYC 4.50 PM);
Updated Wrappers runtime again, added libusb for wine-5.7, also build libpng15 and libjpeg8 built from source using the final versions available.\
The newly built libpng15 should resolve some file selection and explorer issues within Winehq Engines.\
Still bundled libfreetype from XQuartz to support wine versions below wine-2.18 due to wine versions below this not being compatible with the later versions of freetype.
Winery was also updated slightly,\
On macOS Catalina, only Wine64 and wine32on64 will be shown\
Wine versions that are not compatible with Freetype2.8.1 will now be hidden by default along with wine versions that require XQuartz (this might be changed)
Updated again (April 21th NYC 9:15 AM);
Wrapper updated again, wrappers should exit faster\
No longer removes wine related /tmp files just incase another wrapper or another wine process is running\
"Winehq Engine Launch" now only checks for wine binaires within the wrapper
Rebuilt WS11 Engines to correct a disabled X11 feature, also disabled winemenubuilder
WineskinLauncher will again create the wine binarie wrappers again, this should restore the exit speed unless Wineserver process is still running on exit.
All dylibs have had paths changed and also shrunk shrunk slightly.
Updated wrapper contains latest MoltenVK and also has libgcrypt added as wine-staging makes use of that for additinal bcrypt coverage. WS10WineStaging5.5 & WS10WineStaging64Bit5.5 were both rebuilt to take advantage of gcrypt support.
`WineskinLauncher` will now only regenerate the wrappers BundleID if the wrappers name has changed.
The BundleID will only change again if the wrapper is renamed, it won't save if launched via Wineskin.app after the name change only via a direct launch
`Winery` slight internal tweaks, now on Engine Repacking and wrapper creation unused Engine files/dylibs will be stripped ensuing the Runtime is always used instead of Winehq's outdated versions only libjpegturbo is kept as I don't ship that and it conflicts with stock libjpeg.
Engine bundled dylibs `wswine.bundles/lib`, `wswine.bundles/lib64` & `wswine.bundles/lib32on64` are loaded ahead of anything else so they take priority.
`Wineskin.app` (The configuration utility) `Wine Command Line Test` was renamed to `Winehq Engine Launch` it now launches similar to how the Winehq bundles function, this also auto downloads the patched winetricks if its missing from the wrapper allowing seamless winetricks usage.
Wrapper's Runtime, accidently added libwine from my macports build of wine-staging-5.5
~~EDIT; If you downloaded the `Wineskin-2.9.0.6.zip` earlier please download again to fix font rendering on older Engines~~
These binaries are not code-signed at all
Internal changes to `WineskinLaucher` to allow the usage of Engines that don't contain `wine` this allows the usage of 64Bit and Catalina Only compatible wrappers.
BundleID generation will now produce a more Valid BundleID
Patched `Winery` disabled update check so no this won't conflict with the current release, Repacked Engines now strips additional files, already packaged Engines also have these files stripped when creating a wrapper, also allows 64Bit only Engines without erroring
Tweaked `Wineskin` configuration tool no longer touches the BundleID and some other tweaks.
The master wrapper keep the current release name to avoid any conflicts, Runtime was updated and patched to use `@loader_path` instead of `/opt/local/lib`
Also attached some example Engines.
Updated versions of WineCX19.0.1 Engines that were built with the latest runtime but has no X11 support I might rebuild them again with X11 support when this becomes the official release, but will be using the XQuartz 2.7.7 X11 libraries over the macport versions to avoid any conflicts.