CrossOver Support - Community Forums

I'm wondering if there are plans to make to next version run natively on M1 macs? Performance is pretty good already so I can only imaging it would be a lot better with native arm support, atm it's running thorough Rosetta which works decently well. I have used the trail and I really do want to buy a licence but can't commit to it while it's not native on M1.

Hi Nathan,

We actually have a blog post that goes into details about our M1 support: https://www.codeweavers.com/blog/jramey/2021/5/19/what-is-our-technology-roadmap-for-apple-silicon

Long story short, no, the next release of CrossOver will not have native M1 support, but that shouldn't be cause for concern.

Best,
Meredith

Nathan Wragg wrote:

I'm wondering if there are plans to make to next version run
natively on M1 macs? Performance is pretty good already so I can
only imaging it would be a lot better with native arm support, atm
it's running thorough Rosetta which works decently well. I have used
the trail and I really do want to buy a licence but can't commit to
it while it's not native on M1.

It’s going to take years for CrossOver to be “Native” on Apple silicon and run as well as it currently does.

Currently almost all CodeWeavers developers are trying to help Julliard push through all the required changes for the upstream 32-on-64 implementation.

After that’s done I’d assume CodeWeavers will wants to pull in those changes so all there internal 32-on-64 hacks can be dropped as maintaining those is a nightmare. The lack of features between versions recently would be directly linked to this.

Once all of the above have completed the larger issue is still running x86 code (and x86 memory layout differences companies to ARM64), qemu would be required to handle this but currently Hangover has sever limitations and runs very slowly.

Rosetta2 is currently running x86_64 code almost as fast as native ARM64 code, current M1 chips actually allow x86 memory layouts.

It's likely we lose Rosette many years from now with new Mx chips that remove the memory support for Intel-emulation.

I can't imagine there'd be much point given the fact that a vast majority of Windows games are x86 only

I purchased an M1 mac and now I have lost the ability to play mud games that I can play on non M1 macs using the same install method. I will have to take a step back from further purchases of crossover until there is more functionality on M1 macs. I was hoping there was a fix in the new version but I will wait and see what develops.

April Hollis wrote:

I purchased an M1 mac and now I have lost the ability to play mud games that I can play on non M1 macs using the same install method. I will have to take a step back from further purchases of crossover until there is more functionality on M1 macs. I was hoping there was a fix in the new version but I will wait and see what develops.

You should have already reached out to support so they can assist you and add to there internal tracker.

April Hollis wrote:

I purchased an M1 mac and now I have lost the ability to play mud games that I can play on non M1 macs using the same install method. I will have to take a step back from further purchases of crossover until there is more functionality on M1 macs. I was hoping there was a fix in the new version but I will wait and see what develops.

Are you referring to zMud/cMud no longer installing?

Yes I can no longer seem to install Cmud/Zmud or Portal mud clients

Any official update on Apple Silicon native CrossOver progress? I know probably it is still far away, but the dreaming is free.

For apps that require OpenGL 4.6 there's one person on GitHub who's done some work on implementing that on metal, tho not fully completed I think.

I don't believe there will ever be one.

As far as I understand, crossover needs Rosetta2 to translate x86 binaries (and their associated libraries) to ARM, before it can do any translation of Windows APIs to MacOS APIs (not to mention translating DirectX10/11 to Vulcan and then to Apple's own Metal APIs). If Crossover would be a native ARM binary, Rosetta2 would not be invoked for its runtime, thus Crossover wouldn't be able to translate anything. An ARM binary cannot just randomly request the execution to jump to a code segment containing x86 instructions (e.g. your Windows game). However, if Rosetta2 is already translating the Crossover process(es), then execution can jump to your game code (think of it as an x86 library invocation) - but in this case Crossover is your main binary, and your game's x86 code is the library being loaded (the "dll" if you will), so Rosetta2 will happily translate those x86 instructions as well. Crossover can then take over from there to act as a translation layer between Windows and MacOS system calls, doing its magic.

Actually you are wrong. There are wrappers that are M1 universal binaries that load Intel games just fine.

Actually, you are wrong (sorry). A universal binary just means you have both binaries (x86 + ARM) lumped together so that the same "universal" binary can run on both x86 and ARM machines. On an M1 (or any other Apple Silicon) machine, the universal binary would run the ARM version, so Rosetta2 would never be invoked. Apart from that, what would be the benefit of a "native" ARM version ? The whole translation layer goes through Rosetta2 first, to convert X86 to ARM instructions (there's no other way around this). Then when the translated ARM instructions encounter API calls (Direct X for example, but all the other Windows API calls), Wine + DXVK comes into play to map the actual Windows-native API calls to MacOS system calls and Metal API calls. (mapping is very different from translating - it's not instruction-by-instruction, it's finding an equivalent Mac-Native API call and "re-directing" execution).

You can think it like this: it's already "native" to a degree: the game is running "native" code after being translated by Rosetta2 (it's ARM instructions at this point), and the translated (mapped) API calls (Windows-to-Mac) are also executing native Mac/ARM code (because they inherently are native API implementation on the Mac).

TL;DR: there's absolutely no need to have a ARM-"native" version of crossover.

These are the Crossover forums and it would be uncool for me to post names and links, but believe me you are wrong. I have two different apps in my Mac that are native M1 and still load rosetta and wine64 just fine...

Hopefully apple doesn’t remove rosetta 2 for like a very long time or at least till codeweavers figure out a performative way to do the translation from a native app to x86_64

But I do not know since they removed 32 bit support which destroyed a lot of game support