www.darlinghq.org
Back to storiesRanked by HN
Comments
31 total · 31 loaded
I went down a deep but entertaining rabbit hole in the other direction for fun: https://github.com/ayourtch-llm/fakelinux - initially with the idea “just replace the syscalls in the executable with some sort of a trap and handle that”.
It almost worked, unfortunately MacOS reserves x18 for platform purposes and Linux doesn’t.
The result is some sort of pretty mad contraption which works sufficiently often to compile aarch64 Linux VPP and its dependencies on the Mac using Linux gcc :)
I suppose with some polish it might be useful for something..
Recently, Apple has made it so with a special entitlement, com.apple.private.custom-x18-abi iirc, you can actually use the x18 register, mainly so ARM64 versions of WINE/CrossOver can run outside of Rosetta, since they'll be partially killing Rosetta in macOS 28.
I believe you can find slightly more info on how to use it in some XNU (macOS kernel) tests, namely this one: https://github.com/apple-oss-distributions/xnu/blob/main/tes...
In theory, running Apple Silicon apps on ARM64 linux machines would be really nice. But we are still far from having a performant and feature-complete implementation of doing so.
Darling only targets x86_64 stuff. Still, it's a cool project.
Kinda sad that there are very few updates though [1]
their AppKit implementation receives about 20-30 commits every 5 years. Cool project, but
you are better off waiting for proprietary software manufacturers to release ARM64 builds (a lot of them do now) and patch the holes with FEX.
> Do you know about opensource.apple.com, GNUstep, The Cocotron and other projects?
> We do, and in fact, Darling is largely based on the original Darwin source code published by Apple. We use The Cocotron as a basis for our Cocoa implementation, along with the Apportable Foundation and various bits of GNUstep.
Apportable (<3) was a YC startup https://www.ycombinator.com/companies/apportable from 2011 - the Foundation repo last update was Dec 2014.
For me its a shame to make the Mac apps look like linux.
A few years back, I would have dreamt to run Photoshop on Linux.
But this and the mandatory utilities that come with it became so bloated that even if it was officially offered on Linux I am not sure I would be using it.
You don’t have to run the latest photoshop. (Or Lightroom..)
I run the last version I could fully buy before it went subscription based. It’s great.
Very neat.
All I want for Christmas is Logic on Linux. But then you’d still need a Mac to legally download it from the App Store and DRM checks would probably only work on Macs
Give Reaper a try, it works very well on linux and you can even use VSTs.
Cool that it exists, but I honestly don't even know which mac exclusive program I would want to install.
Quibble: it'll run anything that runs on open source Darwin. You won't be running anything needing macOS frameworks.
This is the Darling project which aims to run macOS software on Linux for both Intel and ARM64.
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.
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? I'd even be willing to limit to x86 apps. Or maybe there is and I'm just really out of touch??
Wine has been going for a very long time - since 1993.
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...
At a guess: the "killer apps" are things like MS Office and Photoshop, and since they are usually available on both Windows and Mac, there's not such a pressing demand to support similar functionality for Mac apps if the Windows version is easy to obtain.
> 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
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.
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.
GNUstep ran early MacOS apps on Linux after Apple bought Next and adopted their APIs.
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.
> GNUstep ran early MacOS apps on Linux after Apple bought Next and adopted their APIs.
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.
Win32 has a little less churn than AppKit used to. If you support the API surface of winxp from 25 years ago you can run a lot of stuff. Most teams inside Windows at MSFT also try to leave older APIs alone and introduce stuff in an additive fashion. Apple, by contrast, historically has app compatibility as a non-goal.
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.
While the productivity apps are mentioned in the other comments of this reply, games are another reason. There are far more games on Windows to port and handle than macOS games. And in that case, you got a financial desire in the form of Valve and its Steam store. macOS games tend to be ports from Windows and are usually less featureful.
[deleted]
[deleted]
> What allows Wine to run so many Windows apps that there's not an equivalent for MacOS?
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.
The real/final test is running applications like Final Cut Pro using `darling`
Will it run xcode build tools?
From the FAQ on the Discord:
*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.
Would be nice to run Final Cut Pro on Linux without having to pay an arm and a leg for the actual machine. It's a really expensive toy :(
[deleted]
[deleted]
[deleted]