DirectX 12 Support Comes To CrossOver on Mac With Latest Update

Codeweavers took to its official forums today to announce the release of CrossOver 23.0.0, the new version of its software that aims to make emulating Windows software and games easier on macOS, Linux, and ChromeOS systems. From a report: CrossOver 23 has updated to Wine 8.0.1, and it's loaded with improvements across all its platforms. The most notable, though, is the addition of DirectX 12 support under macOS via VKD3D and MoltenVK. This marks the first time most Mac users have had access to software that relies on DirectX 12; previously, only DirectX 11 was supported, and that went for other software solutions like Parallels, too. This new release adds "initial support" for geometry shaders and transforms feedback on macOS Ventura. Codeweavers claims that will address a lot of problems with "missing graphics or black screens in-game" in titles like MechWarrior 5: Mercenaries, Street Fighter V, Tekken 7, and Octopath Traveler.

Apple Silicon Performance

[battingly]

I've used Crossover on M1 and M2 macs and the performance has been disappointing. Obviously there are big challenges in getting Intel binaries to run on Apple Silicon, but I get much better performance using Rosetta running Mac Intel binaries than I do with Crossover running comparable Windows Intel binaries. Even on compute-intensive binaries that do little graphics or system calls, there's a big difference. It would be nice if Crossover or Parallels could could find out what tricks Apple is using on Rosetta.

Re:

[MightyMartian]

If you can afford a Mac, surely you can afford a PC for the windows apps. Rosetta is pretty awesome and all, and I used it for a while until the Libreoffice team had compiled an Apple Silicon binary, but for me that's a stopgap solution.

Re:Apple Silicon Performance

[caseih]

Crossover Wine *is* using Rosetta on your M1 and M2 macs. Wine is x86 only. There's no other way to run it. The whole works has to run under Rosetta.

There was someone working on integrating an emulator into Wine such that you could compile and build it on Arm and have it translate the x86 binaries on the fly. But I'm not sure what the status is of that. Would be very useful if and when it finally gets integrated. At that point, perhaps crossover would be able to increase performance on Mac if wine and all the NT syscalls were native ARM.

Re:

[battingly]

Aha, I can see now you're right, it's an x86 binary. So it's running an emulator inside an emulator. No wonder the performance is disappointing. Seems like Apple has already done 90% of the work that would need to be done, so I wonder if they have considered adding that to Rosetta. That would probably be more productive than waiting for an Arm version of Wine.

Re:

[caseih]

Essentially correct. Although Wine is more of a syscall translator than an emulator. The windows binaries are executed on the CPU directly if you are running on x86. Wine is basically an implementation of the NT kernel and the Win32 subsystem.

Apple will never touch Wine. Unlike MS, they have a real aversion to anything GPL for a variety of reasons, some of which are technical, and others are plain bunk.

And I think it unlikely they would ever build their own Win32 implementation on top of Darwin either.

Re:

[DamnOregonian]

WINE does not translate syscalls. It only implements system DLLs.
As it turns out, 99.9% of all Windows applications talk to the kernel via system libraries (similar case exists in linux, where all syscalls are realistically done by libc, not your code)

WINE has no way to trap a software interrupt, and thus cannot intercept a syscall.

Re:

[real_nickname]

So it's running an emulator inside an emulator.

Wine Is Not an Emulator, it is in the name. Maybe wine is heavily optimized and all of these optims fall apart after rosetta translation.

Re:

[DamnOregonian]

WINE can't optimize the binaries it runs, because it runs them *directly* (that's why it's Not an Emulator).

As for pure computer performance, they're simply wrong.
A WINE application doing no API calls runs at the same speed whether it's a macOS binary running via Rosetta, or a Windows binary with WINE windows libraries running via Rosetta.

In the case of graphics though, the cost can be significantly higher because you have Rosetta + translation of DX -> Vulkan -> Metal, and no way you swing it- t

Re:

[DamnOregonian]

At that point, perhaps crossover would be able to increase performance on Mac if wine and all the NT syscalls were native ARM.

lolwut?

WINE doesn't handle NT syscalls.
That's the magic. It re-implements the library that processes use instead of doing direct syscalls.
If your software uses a direct syscall, then WINE can't run it.

Otherwise, you are correct. Crossover on Apple Silicon is using Rosetta.

You would not want to use anything but Rosetta, because anything you use is not going to perform as well (without a kext to switch the data ordering mode of the CPU for a segment)
You could run an x86 WINE on arm linux today, using

Re:

[caseih]

I was just using syscall as a generic term here. Whatever the case, Wine implements all the calls the NT kernel exposes. So if a exe requests CreateProcess, wine does what it takes to do that on the native host OS. BSD's linux emulation does something similar to run Linux binaries on BSD, but of course works at a much lower level. But the effect is the same.

Some day when Wine on Arm has built-in support of emulation, Wine and the implemented DLLs can all be native ARM and then the EXE itself is the only

Re:

[DamnOregonian]

WINE implementing ReadFile() is no different than libc implementing read();
Your native C program doesn't directly call the read syscall, it uses a library function to do so. WINE is the same.

All WINE really is is a PE loader (as opposed to ELF) and some re-implementations of common dlls that are loaded directly.
Once it's done all this, the program executes natively.
It's no different than a linux program loading libc.so for implementation of all the expected POSIX calls.

Re:

[DamnOregonian]

Crossover on Apple Silicon uses Rosetta. It's an x86_64 binary.

Dislodging the Windows Monopoly

[xack]

With so many (not an) emulators of Windows software, the only real reason you're stuck with Windows is due to overly aggressive anti cheats, which Microsoft is in no doubt bribing developers to use to preserve their monopoly. With Windows 11 failing in adoption there is a big opportunity to exploit Windows 7, 8.1 and soon to be 10's end of support and tell people they don't have to keep on the upgrade treadmill. The latest Canary version of Windows 11 which is the secret beta of Windows 12 is apparently not

Re:

[tlhIngan]

With so many (not an) emulators of Windows software, the only real reason you're stuck with Windows is due to overly aggressive anti cheats, which Microsoft is in no doubt bribing developers to use to preserve their monopoly. With Windows 11 failing in adoption there is a big opportunity to exploit Windows 7, 8.1 and soon to be 10's end of support and tell people they don't have to keep on the upgrade treadmill. The latest Canary version of Windows 11 which is the secret beta of Windows 12 is apparently not

Re:

[willy_me]

which Microsoft is in no doubt bribing developers to use to preserve their monopoly.

You are ignoring the fact that most developers want to make money, typically by selling software. And sales for software designed to run on systems that people do not use is typically quite bad. So Microsoft doesn't have to do a thing - their lock on desktop software is a given. They just require a minor amount of development to ensure that developing native apps is more productive than cross-platform development.

One can not dislodge the dominant player in such an ecosystem. The only way for an OS to