Hacker News Reader

Comment by dagmx | Hacker News Reader

Important to note that this is different than what Codeweavers did and the timing of both their announcements is purely coincidental.

https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-come...

Apple did contribute to the Wine codebase and have their own translation layer.

Performance and compatibility seem to be much better than what Codeweavers showed which is expected given the translation appears to be DXIL to MSIL instead of DX to VK to MS.

The Mac gaming Reddit has a bunch of people posting results

https://reddit.com/r/macgaming/hot

And someone’s already made a tool to simplify running games

https://github.com/IsaacMarovitz/Whisky/releases/tag/pre-0.2...

This is also a triumph for open source imho because wine is now receiving patches for macOS directly, and it’s a symbiotic relationship that hopefully grows.

Things look very promising.

View on HN

> This is also a triumph for open source imho because wine is now receiving patches for macOS directly, and it’s a symbiotic relationship that hopefully grows.

I wish. Unfortunately the MetalD3D is proprietary under a very restrictive license. The rest is just Wine code written by Codeweavers.

I don't understand your pessimism. If Apple finds and fixes a gap in Wine's coverage/compatibility, those changes will necessarily be open source. Quite simply, any work which Apple does that could be useful to the wine project will be open source.

Obviously it would be nice if MetalD3D was also released under a better license, but it's hardly as though this omission is a big loss to the wine project.

Apple did not upstream anything to Wine here. They just use CodeWeavers code for macOS support, plus their own changes, and released a 20k line diff to be compliant.

The license to their translation layer(which is closed source) is very restrictive and basically only allows use for evaluation purposes.

> The license to their translation layer(which is closed source) is very restrictive

The Windows EULA didn't allow people who built their own computer to buy the cheaper OEM version of Windows. They were supposed to pay full retail.

I would expect to see people care about this license agreement restriction just as much as they did when they built their own PC and installed the OEM version of Windows on it.

Sure, just trying to correct the notion of this being a "win" for open source, Apple still hates anything GPL :)

>> If Apple finds and fixes

> Apple did not upstream anything to Wine here.

So what you're saying is that Apple didn't do anything useful for the Wine project and you're angry because after Apple did nothing, they failed to open source the nothing. Okay then. I don't follow you.

This is not really important since Metal is Apple-exclusive, right? It's not like it can be used on Linux

It's still not a great thing to do. Apple used to contribute a lot more, even if some of their stuff was exclusive to their platform. https://opensource.apple.com

They can’t really do anything because of the massive liabilities GPL v3 opens them up to.

My understanding; the license won’t allow them to settle if a third party seeks patent licensing from them over shipped GPL code - they have to ensure everyone using any derivative of the upstreamed code is also covered by that patent license.

That's largely down to GPL3, unfortunately.

But it would be useful for OSS to do translation from Metal to DirectX - Apple probasbly doesn't want that.

> MetalD3D is proprietary under a very restrictive license

Can you explain this. Game Porting Toolkit code is LGPL the same as Wine.

The Game Porting Toolkit contains a proprietary (143 MiB) D3DMetal framework that directly translates the Direct3D calls to Metal. They don't use the Direct3D --Wine--> Vulkan --MoltenVK--> Metal path that opensource Wine/CrossOver Wine uses.

So there is more information here:

https://www.reddit.com/r/macgaming/comments/142tomx/apples_g...

And the restrictive license part is this:

"you are granted a limited, non-exclusive, non-transferable, personal copyright license to (i) install, internally use, and test the Apple Software for the sole purpose of developing, testing, or evaluating video games for use on Apple-branded products"

That does look like they have their own shader ir converter. But the fact that there's d3d9-d3d12 there, and under a wine directory, means those parts, at least, are borrowed.

That this exists is hilariously self-defeating. Linux gaming is becoming Proton-driven, so with this and VKD3D, we're potentially looking at Direct3D 12 as the most widely supported cross-platform API. Why write Vulkan or Metal when D3D runs everywhere now?

Is it coincidental? From

https://raw.githubusercontent.com/apple/homebrew-apple/main/...

    url "https://media.codeweavers.com/pub/crossover/source/crossover-sources-22.1.1.tar.gz", using: TarballDownloadStrategy

The release precedes CrossOver's 23 release with DirectX 12 support though. (Though you'd think that many bits are already there in prior releases.)

Edit: I poked around a little in the game porting toolkit and it seems different. They have a D3DMetal framework, whereas CrossOver's Direct3D 12 support goes through MoltenVK.

Toolkit deprecated in 3 years after Apple assembles a large enough game library :)

These results are amazing. Diablo IV, Elden Ring, Cyberpunk running (albeit not smoothly) today.

Reply on news.ycombinator.com