Dear fellow Porting Kit users. Here an update of the massive impact having change which Apple is gonna do changing from 32-bit to 64-bit only OS. As you have read in earlier posts, we were already looking for solutions to make Wine possible after the change to 64-bit only, but these were very complicated and had massive impact in the way of use of Porting Kit. All seemed to look dark and void and far away.
But there seems to be light in the horizon! Looks like the great Codeweavers team (Partner of Porting Kit/Paulthetall.com), also responsible for Crossover, has working on a Solution in Wine to still make it possible to run 32-bit games in Wine in a 64-bit only environment! Codeweavers made a blogpost about it here…. where they explain the progress and story around the whole issue with Catalina and 64-bit. But don’t upgrade just yet! I just want to point out the most important Wine part which Porting Kit use to run the games.
The changes required to overcome these challenges would entail changing behavior throughout Wine. That would be an exceedingly large job if we attempted to do it manually. To pare that down by a lot, we rely on a tool that’s already central to governing Wine’s behavior: the compiler. A compiler is a tool used by software developers to translate source code into the instruction byte sequences that CPUs can directly execute. We have built a modified version of the standard C language compiler for macOS, Clang, to automate many of the changes we need to make to Wine’s behavior without pervasive changes to Wine’s source code.
First, our version of Clang understands both 32- and 64-bit pointers. We are able to control from a broad level down to a detailed level which pointers in Wine’s source code need to be 32-bit and which 64-bit. Any code which substitutes for Windows at the interface with the Windows app has to use 32-bit pointers. On the other hand, the interfaces to the system libraries are always 64-bit.
There are places in Wine where it receives pointers to data from the system libraries and needs to pass that data along to Windows code.
This is a problem. The Windows code won’t be able to handle the 64-bit pointers returned from the system libraries. If we tried to just pass the pointer through as-is, the top 32 bits of the 64-bit pointer would be lopped off, resulting in a pointer that points to the wrong place.
So, we have to manually address such cases. But first, we need to find them! Doing so by poring over the code and considering each place where one pointer is copied to another would take way too long and be too prone to errors. To that end, our version of Clang will flag such places in the code as errors during compilation, forcing us to fix them, but allowing us to be confident that the remaining code is correct.
Next, our Clang needs to recognize places in our code where 64-bit Wine code may need to call 32-bit Windows code, and vice versa. It needs to compile our code in such a way that smooths that transition. “Normal” Wine already had to do some of that, but this is much more extensive. Our Clang generates “thunks”, small pieces of code which mediate a transition between two other pieces of code. Where Wine’s 64-bit code needs to call 32-bit code from a Windows app, Clang generates a 64-bit-to-32-bit thunk. Where Wine needs to provide an entry point for 32-bit Windows code to call what it thinks is a 32-bit Windows function, but which is actually implemented as a 64-bit function in Wine, Clang generates a 32-bit-to-64-bit thunk. Those thunks manage switching between the two modes of the CPU.
With these tools (and some others), we have been able to make good progress! But, unfortunately, not enough to be ready to release when Catalina is released. Work continues!
So that’s awesome news indeed! The only thing is that we have to wait to have it finished. Until that time: Don’t update to Catalina yet! Ignore, postpone every notification to upgrade to Catalina for now.
