Hacker News Reader

Comment by heavyset_go | Hacker News Reader

Wine works because Microsoft spends billions on backwards compatibility and APIs are stable over time.

Apple regularly deprecates frameworks and adds new ones at rapid rates. It's a moving target with the added complication of moving build targets.

If you implement your own version of Apple's XyzKit, that might only be used in macOS 12 to 14, and not before or after that, so you put in a lot of work to essentially support binaries that were released between X date and Y date and that's it. And you have to do that for a sliding window of dates, macOS versions and framework releases and deprecations.

View on HN

Wine works, because it doesn't cover many modern APIs, I would assess.

New Microsoft under Satya has a different stance on anything WinRT related, or even newer Win32/COM APIs since Windows 8.

Also .NET Framework is the Python 2 of .NET, the breaking changes are a reason there are still new projects being done in .NET Framework 4.8.x.

You can desugar all the modern stuff to windows api with first party DLLs

First party DLLs have copyright.

No, these are specifically ‘redistributables’.

In the rare case they aren’t, you just require the user to obtain it, wink and nod.

Typically in Microsoft redistributables there are terms in the license that says they can only be licensed for use with a Windows license.

Here's the Visual Studio redistributable licensing requirements:

https://visualstudio.microsoft.com/license-terms/vs2026-ga-v...

There's nothing about Windows licenses in there. There is a specious claim that I can't modify the DLL in some circumstances, but I doubt that's enforceable in any jurisdiction Microsoft could reach me, and to the careful reader the license almost admits as such.

If I'm NVidia in this case, these would be pretty easy to follow. Now I redistribute the DLL: My user downloads the DLL and uses my software (with the DLL) in Wine. Good for them. I have a happy customer. _Maybe_ Microsoft is unhappy, but I'm not sure what they can do besides pound sand: _I_ haven't violated those terms, and my user doesn't have any relationship with Microsoft.

If I've made a mistake and the Visual Studio redistributable isn't typical, what exactly do you think _is_ a typical license from Microsoft that has the force you suggest?

You are missing all the OS DLLs, COM and WinRT components, .NET libraries, that are covered by Windows EULA.

Also the ones downloaded directly via Windows Update from Microsoft servers.

That's not how copyright law works in the slightest.

You can absolutely download a file from Microsoft's website and run that file on Wine and Microsoft cannot get a judge to hold you to any "license terms" elsewhere on that website. I am not your lawyer and this is not legal advice, you are just a moron if you think otherwise.

Furthermore, I also don't think Microsoft would claim otherwise! But you are still welcome to prove me wrong by providing just _one_ example on their website of a license that you think could force me to do anything at all, because of a DLL _you_ can give to me (aka "a redistributable")

Microsoft redistributables are just the standard library. Most of the rest of the new DLLs are not backed by any system calls, just by API calls. Except of course for the D3DKMT stuff, that stuff is the real system calls used by Direct3D.

The solution for that is to decide which period do you want to build support for.

Trying to be binary-compatible with Tahoe may not be worth it. But you could make a distro binary-compatible with Snow Leopard.

Or better, make it compatible with Ventura apps without the bloat of MacOS Ventura.

That could give new life to old Macs. It can also give a PC a MacOS-like environment without having to deal with Hackintosh.

This won't work simply because majority of apps follow "the new trend". Take calibre, for example. I found myself having to OCLP my calibre server, simply because the hardware won't "take" the new macOS version required by the app, but the app new features are only available in the new versions.

I don’t think it’s as fast breaking as you suggest but certainly big changes like 32Bit support dropping, OpenGL deprecation, and move to arm64 are huge breaks.

Generally their “availability” macros in swift and objc keep things working across versions in a forward compatible way.

Reply on news.ycombinator.com