undefined

points

[-]

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.

by AdieuToLogic4 hours 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.

by bri3d4 hours 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.

by AdieuToLogic3 hours 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.