NRG

Uploaded WS10WineStaging64Bit4.17 I'd forgotten to add the Vulkan tag but it makes little difference anyway.
The new runtime was newly built from macports and updated today. Stipped most unneeded items but left in the XQuartz libs due to being lazy.

If anyone wants instructions on building an updated runtime via macports I can provide instructions even for macOS Mojave users
I have a repository on GitHub with updated versions of wine, wine-crossover, wine-devel a patched libpvx (needed for macOS Mojave universal), a patched cmake (needed for macOS Mojave universal) and custom MoltenVK port (extracts the current Vulkan SDK from LunarG).

RastaFabi, on 29 May 2019 - 11:57 PM, said:

Unofficial Wineskin, is already 64Bit (except wsgamma due to no source code) so the application is ready.

CodeWeavers are working on at least two solutions that I'm aware of, one being Hangover, a patched pure wine64 with included custom qemu to handle 32bit applications/games.
Option 2, (patch?) and compile using a custom version of clang that had built in trunking support so 32Bit process will be ran on 64Bit threads. The resulting wine would be like now wine/wine64 but running as 64Bit. < The version I would prefer.

I've been building wine with MoltenVK support since it was possible so once DXVK runs we can use it with a WS10 Engine, so if later they want to us MoltenGL or some other weirdness if it works it can be built into an Engine.

The NSTask thing is more for passing permissions on correctly from Wineskin > wine processes.
I don't think I will need to fork the project for macOS 10.15, the problem is wine more than anything else (maybe some extra checks to disable all but WS11 Engines to be safe lol)

I don't want to use Hangover but I'm willing to build Hangover Engines if needed, Unofficial Wineskin already launches wine64 if it found over wine already.


I plan to keep supporting the project as long as possible, I don't want to fork into different versions unless it's unavoidable for now I would just need to disabled using WS10 and lower Engines on macOS 10.15 once it's launched.

I have to report that I successfully launch Heroes VII of Might & Magic in 64bit mode using
WS9WineXSherry64Bit4.2vk-28.tar.7z
Although it compiled with Vulkan support it looks like Vulkan in not used for this game and DX10 supported in restriction enough to play the game.
Enjoy!

PS. Yes, 64bit game is fully working in Sierra 10.12.6! I see no artefacts and glitches.

This was rebuilt and tested, it does run on OSX10.8.


However OSX10.8 is unable to use Gnutls as it now require TLS1.1/1.2 these were added to OSX10.9 this is due to https and other secure connection protocols (https) are now using TLS1.2.

If someone has an issue with this let me know, it seems my copy of XCode Command Line Tools 9.4.1 was upgraded to XCode Command Line Tools 10
That would cause wine to not function on some systems due to how Apple Clang handle linking

18.1.0 CrossOver - December 22nd, 2018

• macOS:
  
  • Fixed a bug that prevented Quicken from launching for some users.
    
  • Fixed a bug that caused the latest Quicken 2016 Mondo Patch to fail during installation.
    
  • Fixed a bug that prevented game downloads and the Steam Store page from working on the latest Steam release.
    
  • Restored controller support for Steam.

Download

Requires a minimum of macOS 10.9 (10.8 won't have working Gnutls)
This was built to be used with Wineskin-2.6.2 (I bundled libpng16.16/libjpg9/libgnutls/libgsm inside the engine)
To ensure Steam does not have issues you need to set "gameoverlayrenderer" to disabled in winecfg.
Controller support is included like with Winehq builds.
Use with macdriver, I'm not sure if WineskinX11 will work as it's not functional on macOS Mojave.


Please Note;
If your an Unofficial Wineskin user download the version available from "Unofficial Wineskin Winery" that was built to take advantage of the additional dylibs that are part of Unofficial and some games will work out of box were the above version will need some winetricks to be used as with other "Official Wineskin Engines"
Also if you encounter an SSL error it’s due to the version provided by your version of OSX/macOS



Why do I need 10.9?
The reason is 10.8 only support TLS1.0 where as 10.9 support TLS1.1/1.2 and we need these newer versions to support https sites other secure connection type aka Steam Store/Downloading/Friends List etc

Hi everyone,

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.

NRG, on 04 September 2018 - 04:44 AM, said:

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"

The following engines versions support Gnutls (Steam/Origin etc downloading and bcrypt support)

Vulkan support was also included with the 64Bit version so it might come in handy to anyone who wants to test Vulkan support (still no working DXVK for now)

Download

The new naming format;
WS10WineStagingGnutls3.13 & above < 32Bit only but has Gnutls support
WS10WineStagingVulkan3.13 & above < 64Bit Vulkan support and 32Bit & 64Bit Gnutls Support


Minimal Requirements;

• Running the latest version of Wineskin Unofficial Update
  
• OSX 10.9 for Gnutls support
  
• OSX 10.11 for Vulkan support.

These Engines will function on OSX10.8 but won't get the main benefit of Gnutls support

Notice for Winehq users;
The Engines (wine compiles) provided here are for use with “Unofficial Wineskin” while they could be unpacked and used via terminal I won’t give any support for using them in that manner.

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.

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

Updated again, now both "Fixed Wineskin Winery.app" & "Unofficial Wineskin Winery.app" versions include the Engine ordering from VitorMM

emendelson, on 10 June 2018 - 07:51 PM, said:

I got time today and take a look but since I'm not enrolled in Apple's Developer Program (I don't pay), I don't have access to a download of Mojave at the moment.

EDIT;
I took a different route and got the Mojave installer, I didn't get to try it much last night but Wineskin did work. The currently released unofficial update will give 32bit warnings before even launching wine.

My current Development branch aimed at post Mojave only gives an 32bit warning when launching wine.
I will try to test more when I have enough free time.

The next version I release will have ALOT of changes to the structure and stripped down the included dylibs. I will be providing a different version of “Wineskin Winery.app” along with the new master wrapper.
To use the new master wrapper you will need to use the new winery.app that I will be providing.

NRG, on 25 May 2018 - 12:20 PM, said:

Thanks but I already have 10.8 SDK but Crossover won't compile with it due to some code changes that require 10.9 SDK


/Users/Gcenx/Downloads/sources/wine/dlls/bcrypt/bcrypt_main.c:897:68: error:
  use of undeclared identifier 'kCCAlgorithmAES'; did you mean
  'kCCAlgorithmDES'?
  ...= CCCryptorCreateWithMode( kCCEncrypt, kCCModeCBC, kCCAlgorithmAES, ccNo...
^~~~~~~~~~~~~~~
kCCAlgorithmDES
/Developer/SDKs/MacOSX10.8.sdk/usr/include/CommonCrypto/CommonCryptor.h:151:5: note:
  'kCCAlgorithmDES' declared here
kCCAlgorithmDES,
^
/Users/Gcenx/Downloads/sources/wine/dlls/bcrypt/bcrypt_main.c:903:68: error:
  use of undeclared identifier 'kCCAlgorithmAES'; did you mean
  'kCCAlgorithmDES'?
  ...= CCCryptorCreateWithMode( kCCDecrypt, kCCModeCBC, kCCAlgorithmAES, ccNo...
^~~~~~~~~~~~~~~
kCCAlgorithmDES
/Developer/SDKs/MacOSX10.8.sdk/usr/include/CommonCrypto/CommonCryptor.h:151:5: note:

That only starts to appear in 10.9 SDK so it has to be compiled with a min of 10.9 SDK, but looking over my build script it might not have passed deploy version on before causing the issue of it not working for you.
But I'm just going to re-compile it using 10.9 SDK set target as 10.8 just to be safe.


EDIT;
NRG confirmed the newer upload now works correctly, so that means it worked on 10.10 if anyone is below that post if it works for you or not but it should work down to 10.8 but I don't have access to a system running 10.8 or even the instal media.

Bump, I re-compiled 32bit to be more like the official Crossover version so no X support.
Also built 64bit, also no X support.