> What allows Wine to run so many Windows apps that there's not an equivalent for MacOS? Is it lack of interest? Is it a technical thing?

It is a technical thing.

The XNU[0] kernel, which underpins macOS and is detailed by the exceptional book "Mac OS X internals"[1], can theoretically run on many x86 and/or ARM machines. However, the issue with running macOS apps via other operating systems is not the OS, but instead are the GUI frameworks expected (i.e., Carbon[2], Quartz[3], etc.). These frameworks are intentionally written for Apple hardware/macOS distros. Which makes sense when viewing macOS as a selling point for selling Mac's.

0 - https://en.wikipedia.org/wiki/XNU

1 - https://openlibrary.org/books/OL17205558M/Mac_OS_X_internals

2 - https://en.wikipedia.org/wiki/Carbon_(API)

3 - https://en.wikipedia.org/wiki/Quartz_(graphics_layer)

▲ bri3d a day ago | parent | next [-]

No? Windows also has its own graphics subsystem, compositor, and an even bigger set of user land UI/forms/controls libraries than Mac OS. It really is just a critical velocity / adoption / time thing, there’s nothing strongly technical separating Mac OS API/ABI translation from Windows ala wine.

▲ AdieuToLogic a day ago | parent [-]

Microsoft's business model regarding Windows is to sell an operating system capable of running on as many devices as possible.

Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.

The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.

▲ bri3d a day ago | parent [-]

I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier. Certainly, vertical integration makes OS porting (ie Asahi) and lower level emulation more difficult, since the hardware and firmware's contract with the OS is entirely proprietary and can be freely changed from revision to revision, but something like WINE operates many layers above this anyway.

There's a reasonable argument that the Win32 API was designed to be more stable than the Mac OS one and this makes WINE's task easier, but this sword is double-edged: while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used. With the continued proliferation of Windows UI frameworks and OS subsystems, it becomes difficult to argue that Windows is any easier than Mac OS would be to implement at an API layer.

I do think there is an argument to be made that Win32 was more straightforward and felt more tractable when WINE _started_, and therefore the project was able to scale with the problem space, while OS X started from a "larger" place and was therefore more daunting, but this again is a timing and traction argument more so than a purely technical one.

	▲	AdieuToLogic a day ago \| parent [-]
		>> Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system. > I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier. Here is my corroboration. Apple publishes XNU to the world in this repository: `https://github.com/apple-oss-distributions/xnu` There is no such publication of the GUI frameworks required by macOS programs. > I do think there is an argument to be made that Win32 was more straightforward ... I did not make that argument. Instead, the position I hold regarding Windows is: `... an independently derived emulation layer is possible (not easy, just possible) ...` When an organizational goal is to sell devices, instead of operating system licenses, there is no need to engineer portability within the OS as the target hardware is well-known. This is a luxury MS-Windows never had, as its goal has been to run on as many disparate devices as plausible. Thus the "intrinsic portability" I referenced. In fact, you have made my point for me: > ... while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used.

▲ BillStrong a day ago | parent | prev [-]

There is a project to use the Snow Leopard kernel and open source components and some bits from the prerelease Snow Leopard on PPC to create a working PPC Snow Leopard.

I wonder if something like that might be a short term viable path to get working apps. Something like the non-opensource libraries as a download pack for certain each release of Mac OS X, for at least versions Apple no longer supports, to get working programs, then you could slowly work toward open implementations.