1. 17
  1.  

  2. 12

    The developers of Darling are planning to build a nice and user-friendly GUI for interacting with Darling. But for now, we can interact with Darling via command line only.

    This is the famous underwear-gnomes “Step 2: …”. Getting real apps running requires re-implementing a huge amount of closed-source software that Apple’s engineers have been building over the past 25 years. And it needs to have not only the same APIs, but the same details of behavior, including bugs. (Because apps totally rely on that, often without realizing it.)

    I know things like GNUstep exist, and I’m sure they can get some basic AppKit demos up and running, but porting almost any real-world app would take serious work, and probably require modifying and recompiling the app from source.

    (Speaking as an ex-Apple engineer who spent 8 years in the OS X group building system apps.)

    1. 3

      Wine could use some vc redist libraries. With enough syscalls implemented, if it could directly use the AppKit or other binary Frameworks, Darling probably only needs to implement the frame buffer.

      1. 2

        Yeah, but at that point I suspect you’d be dealing with IP infringement issues by copying the Apple frameworks, just like old-school Mac emulators that required ROM images. Not that it’d stop people, but the project README does point out how everything they’re doing so far is 100% legal.

        1. 2

          AFAIK, Wine always got away with the line “use these DLLs from your own legal copy of Windows

          1. 4

            And this worked for WINE because 20 years ago most people bought computers that came with a copy of Windows and so had a legal copy of Windows preinstalled. They’d install Linux and dual-boot, with their Windows partition mounted on the Linux world and so this was easy to do. Most potential Darling users don’t have macOS and, if they do, they are still violating the license if they are running Darling on anything other than the Mac because Apple’s license explicitly prohibits using any of macOS on non-Apple hardware.

            I’ve been involved with GNUstep and WinObjC for a while and both of those had a much easier task because they were aiming to provide source compatibility. If someone is willing to port their code to an alternative Cocoa implementation then they can work around the incompatibilities. If you’re trying to get unmodified binaries working then you don’t have this affordance. Even with WINE, a lot of its success now comes from the folks who are using it as a porting tool and so are either helping them fix incompatibilities or working around them. I believe most WINE contributions these days are funded by game companies that use it to port Windows games to macOS and Linux. There’s no equivalent group of people who have Mac-only apps that they want to run on Linux to fund development.

            macOS is just software, so it is 100% possible to create a drop-in replacement for all of their libraries. It’s just going to be a phenomenal amount of effort. Darling has been around since I was actively working on GNUstep (which I stopped about 10 years ago) and still can’t run anything nontrivial. Apple has a large number of developers adding new APIs that applications adopt quickly, so it’s a moving target and it’s getting away faster than Darling (or GNUstep) is catching up.

            One of the big problems for GNUstep was the set of things beyond Cocoa that applications depended on. GNUstep’s implementations of Foundation and AppKit were in a pretty good state, but things depended on PDFKit, WebKit, CoreText, CoreAnimation, or any of a hundred other frameworks that Apple provides to make life easier for app developers that had no GNUstep equivalents. WinObjC provided at least stub implementations of a lot of these and even it struggled to get any traction as a tool for porting iOS apps to Windows (a much bigger market than running macOS apps on Linux).

            1. 2

              macOS is just software, so it is 100% possible to create a drop-in replacement for all of their libraries. It’s just going to be a phenomenal amount of effort. Darling has been around since I was actively working on GNUstep (which I stopped about 10 years ago) and still can’t run anything nontrivial. Apple has a large number of developers adding new APIs that applications adopt quickly, so it’s a moving target and it’s getting away faster than Darling (or GNUstep) is catching up.

              To pile on a little bit (because I share your recollection of the project’s age and your assessment of its progress) looking at the rate of commits in the Darling repository, it doesn’t feel like there’s a serious attempt to catch up here.

              I remember Darling the same way I remember PearPC. When Mac OS couldn’t run on commodity hardware, these things were interesting. They lost all momentum when Mac OS was released for intel-compatible CPUs. I guess Darling is seeing more interest because there’s good reason to suspect that Mac OS for intel will disappear in the medium term. But looking at the commit log, it sure doesn’t seem to have the kind of momentum that makes me think it’ll be useful by then.

      2. 2

        How much churn do you think there is in the MacOS GUI code? I mean, they “only” need to implement the result of the 25 years of development, not all the changes that happened over those years - how many years do you think Apple would need these days to green field reimplement the most commonly used 95% of appkit?

      3. 3

        It’s cool that people are doing this, impressive that they’ve gotten this far, and no doubt there’s a lot to learn from the progress that they’ve made so far – but for most people’s purposes this is light years away from running macOS software on Linux.

        1. 3

          Call me when it runs IMessage.

          1. 1

            It won’t ever. iMessage is bound to iOS hardware identifiers for authentication. It’s not the porting / RE that’s hard in that case, it’s that you can’t use it without real Apple hardware.

            1. 2

              It’s definitely possible to run iMessage on a Hackintosh, where you just need a valid combination of device and logic board serial numbers and a few other magic boot loader values—there are tools to automate generating these. On the other hand, getting Messages.app plus all of the frameworks it requires to run on Linux wouldn’t be easy (remember that iMessage makes heavy use of the system keychain, APNs, and other fancy stuff that you can’t easily reimplement without pulling in half of macOS).

              1. 1

                Ok, i phrased that wrong - you need to get an iPhone, but you can copy the identifiers out, which decreases the number of people interested in that solution since… they already have an iDevice.

                I haven’t heard of anyone generating new valid numbers though. Have you got a link?

                1. 1

                  iMessage itself (the blue bubbles) still works just fine without an iPhone, you just don’t have an associated phone number to receive messages at without using your email address.

                  The serial numbers and SMBIOS stuff are for emulating a real Mac; they don’t come from an iPhone. The process is a bit more of a pain if you’ve never associated your Apple ID with a real Apple device or spent real money on the App Store (you usually have to make a purchase or call support to get your account permitted to use iMessage so as to cut down on spam), but it’s certainly possible.

                  Here’s a more detailed link on that topic: https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html

          2. 2

            I love seeing these translation layers. I’d love to see one to run Linux apps on OSX, so I could finally run my FPGA dev tools outside of a VM. No hardware access needed, just X (XQuartz is long dead, sadly) and whatever file access is needed for normal apps.

            1. 16

              I’d love to see one to run Linux apps on OSX, so I could finally run my FPGA dev tools outside of a VM.

              Linux on macOS is comparatively easy. Everything in the stack is open, so you don’t need to, for example, reimplement glibc, Qt, or GTK to get everything working. That said, I’m not sure that there’s any real reason to bother. You can run a Linux app on xhyve with remote X11 to your macOS X11 install everything works fine. A few things I ran in FreeBSD on xhyve ran faster than natively on macOS, so sinking the kernel interface down into XNU wouldn’t really buy you much. This is basically what WSL2 does: it runs a Linux kernel in Hyper-V, uses 9p-over-VMBUS for file sharing and lets you pretend the two systems are the same. For graphics it’s now using a separate Linux VM that runs Wayland with GPU pass through and using PipeWire for the other VMs.

              Doing the same thing for macOS is hard because of the huge stack of proprietary things on top of Darwin. NetBSD tried to provide a Darwin compatibility ABI for a while, which provided the syscall interface, a Mach-O loader, and Mach ports and could run some Mac binaries, but not very many because it couldn’t run Quartz (it didn’t implement the kernel interface to the GPU) and it couldn’t run any of the CoreAudio stack (sound support isn’t part of the open sourced bit of Darwin). Apple doesn’t keep a stable system call interface between minor revisions of macOS and so you really need to provide your own libSystem.dylib if you want to do this.

              If you want to do it legally (i.e. not just copy Apple’s frameworks), you also need to provide a whole pile of system frameworks (WinObjC made a surprising amount of progress on this for iOS, GNUstep is stuck around 10.7ish for OS X and implements only Foundation and AppKit). In some ways this is easier because at least the top parts of the frameworks (i.e. how they interface with the apps you might want to run) are public, whereas the bottom (how they interface to the kernel) is often completely undocumented and sometimes changes radically between releases but it’s a phenomenal amount of code. Worse, some of these APIs subtly leak implementation details and you end up with some apps using Mach ports in a way that is specific to how they would communicate with WindowServer on macOS but is different to how you’d implement the same frameworks with X11 / Wayland.

              No hardware access needed, just X (XQuartz is long dead, sadly) and whatever file access is needed for normal apps.

              XQuartz isn’t exactly dead. Apple upstreamed all of their changes to X.org and stopped shipping a fork. The last versions of XQuartz were just the OS X builds of upstream X.org, so there was no reason for Apple to keep shipping it - the upstream version did everything their fork did and was more actively maintained.

              1. 6

                XQuartz is long dead, sadly

                Xquartz just had a release this year(2021-04-25): https://www.xquartz.org/

              2. 1

                Very disengenuous. Not MacOS software at all, Darwin software. Basically BSD. Almost none of MacOS is included in Darwin, not even all of Core Foundation IIRC, and nothing of all the parts of MacOS that are the only reason you’d need to run MacOS software.

                1. 3

                  Dunno that I’d call it “disingenuous” so much as “aspirational”. I agree that they’re still very far off it being “accurate” :). But I do believe they sincerely want to make that so. I question whether they’re capable of that, but they might get more people trying to help with the impending demise of Mac OS for intel processors.

                  Core foundation source code is here though I have no idea how complete that is. I’ve only used it to help me consume property lists outside of Mac OS.