I just wanted to make a post with some basic information for people who want to start porting.
Q1: What winery / wineskin versions work on Mojave and where can I find them?
A1: Standard Wineskin has had issues since High Sierra. You can find links to an updated version http://portingteam.c...fficial-update/ It should work on Mojave.
The original and the updated Winery applications let you download engines, and then use these as a foundation to build wrappers for you to install your game/application in.
Q2: What Wine version should I use for my game/application?
A2: That depends a lot of what you want to do. For example, Skyrim has worked fairly easily since Wine 1.6, but runs faster with a recent command stream-enabled engine. In general, you could try a recent Wine stable version (whole numbers, e.g. 3.0.2), a Wine development version (point numbers, e.g. 3.15), Crossover engine (e.g. 17.5), and/or a Wine Staging engine. See if you can find your game/application in the Wine App database https://appdb.winehq.org and use a version that is rated gold or platinum if you can.
Q3: What about DX10 / DX11 / DX12 games?
A3: This is being worked on. The support for DX10 and DX11 in vanilla Wine is only for Linux and not available on Mac OS because Apple stopped updating their OpenGL drivers years ago in favour of Metal. Now there is an effort to use the cross-platform Vulkan API, which requires two bridges: from DX10 / DX11 to (using DXVK) Vulkan to (using MoltenVK) Metal, or from DX12 to (using VK3D) Vulkan to (using MoltenVK) Metal. As you can imagine, these complicated bits of software are not easy to connect, and they are also all still in development with important bits still missing. Fortunately, Valve (the company behind Steam) is providing resources to get all this code working so it is not just amateurs working in their spare time. There are also fundamental issues of DX, Vulkan and Metal having slightly different feature sets, and some of those gaps are hard to bridge.
For the foreseable future, don't think about playing a DX10 / DX11/ DX12 game on Wine on Mac OS. Some of these have Mac ports, usually done by Feral or Aspyr. Find them on Steam or GOG.
Q4: How can I help?
A4: You can test games/applications and report here or in the AppDb. Either build your own wrapper or get some in the Ports Database on this site (you still have to own and install the game yourself). You can buy Crossover Mac, so that Codeweavers (the company that provides most of Wine development) will have more resources and reason to put more emphasis on Mac. You can contribute code to Wine or DXVK or VK3D or MoltenVK if you have the skills and the time to dig into that.
I just had the problem that I wanted to install Brink using Steam. Brink is free to play so there's no "Purchase" option. As a result the website told me it's already in my library but the client didn't show it. As it's pretty much impossible to use get the web-content to render in an out-of-the-box steam installation in WineSkin it was quite hard to figure out how to actually make Steam install the app:
Surprisingly the easiest solution was to just do the same as the browser would do: open the Steam URL
1. In WineSkin, open a Command Line Shell (from the Tools tab)
2. There run: start steam://run/<appid>
(where <appid> is the number that you see in the URL of the game's steam-shop website)
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.
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.
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
Are we going to get any videos or audio recording or notes or such from Wineconf 2018? The programme looked quite interesting, and it has been a decent way to figure out what we might get from Wine next year.
In theory, it is possible, but it is much harder. You have to get the right dependencies and all that and maintaining it would be hell. The biggest reason for not needing 64bit support on 10.6 and 10.7 is that machines that can only run those operation systems aren't strong enough to run 64bit only programs anyway.
Thank you, that just confirmed my fears, since there would be no real benefit I see no point dealing with that headache.
WhoKnows, on 30 April 2018 - 07:45 AM, said:
I can confirm it does NOT work yet in 10.6.8
I added something for you to test out, I took the original wineskin-2.6.2 and replaced everything but the Frameworks folder.
It properly wont work with 64bit engines but might work for current and newer Staging engines I believe.
Little update about 10.6.8 support,
Thanks to WhoKnows, I have added a version for 10.6.8/10.7
That version uses the original Frameworks from stock wineskin-2.6.2, but includes all updates so if anyone does want to figure out what extra files are need to be added to Frameworks then those users be have all the benafits of this update.
Benefits for 10.6.8/10.7 Users Version;
MAC driver is now default like Official Wine
Winetricks Updated -April 30th/2018
Ability to add a symlink for ~/Downloads
"Kill Wineskin Processes" Fixed
Wine process names now works for all Engine types
TEMP/TMP environment preset to /Users/Wineskin
- I did not remove any code related to Wine64/Staging64 creation, so if anyone wants to take the time to find what's missing it would be possible to use all the features of the main version, but remember most 10.6.8/10.7 systems properly can't run 64bit applications well anyway.