Posted by Bluestein 6 hours ago
It looks more like a Magneto-Optical Drive, not a beach ball
But you are probably looking for this:
> Does it support GUI apps?
> Almost! This took us a lot of time and effort, but we finally have basic experimental support for running simple graphical applications.
When it started Windows was a lot smaller, so getting Windows 3.1 programs working was probably enough.
There's too much history to cover in a quick comment.
Wine has a lots of things that help - the compatibility database https://appdb.winehq.org/ is a good place for people to submit info on apps for instance, there's also a big test suite that runs against Windows + Wine.
Both of these have been around since the 1990s - Darling is at an earlier stage, but once GUI apps run better both of those are good ideas to adopt.
I think Darling probably needs more people working on it.
The whole are of Metal on Vulkan looks interesting https://github.com/darlinghq/darling/issues/390#issuecomment...
https://en.wikipedia.org/wiki/GNUstep
I don't think the project kept up with changes to the APIs over the decades compared to how well the Wine project kept up with changes in Windows.
I said "used to" because anecdotally, I had a personal project I haven't released anywhere target AppKit, I haven't been maintaining it because life is busy, I recently rebuilt it for the first time in a long time and I was shocked that everything worked. ~8 years ago, you would need to do some porting to a new major release once per year. I skipped that maintenance for many releases and didn't need to change a single line. This tells me that desktop apps are not at all an area of major focus for them lately. Maybe swiftui is getting all the attention. They are doing something more resembling Microsoft, leaving the old shit alone.
No, it did not. There was no point at which GNUstep provided binary compatibility with Mac OS applications - while the two ecosystems shared some common history, it was much too far back to provide any form of compatibility. Additionally, Mac OS X used a different executable format than Linux or other UNIX-like operating systems, and GNUstep never attempted to provide that sort of low-level compatibility.
(For perspective: the GNUstep project started in the early 1990s. Mac OS X was first released to users in 2001.)
It may have been possible for some developers to port applications between Mac OS X and GNUstep while sharing some code, but that's a long way from running an unmodified application.
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
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.
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.
> 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
> 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) ...
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.
Backwards compatibility. Apple changes their API every year or so, usually for no good reason.
A lot of work done over 3 decades. Wine also started when Win32 was something comprehensible by one person, so they could build it up slowly.
*Does Xcode work?*
Yes and no. The Xcode GUI definitely doesn't work yet; see *Will <<Insert_Random_GUI_Application>> Work?* above. However, the Xcode CLI tools like Clang, LLDB, Git, the Metal compiler, the Swift compiler, and more do work.
*What about `xcodebuild`?*
Some versions of `xcodebuild` (e.g. 11.7) are known to work for extremely basic XIB-based macOS apps. However, the vast majority of projects do not qualify as extremely basic and aren't supported yet.