Linux – Is there something like wine to run OSX apps on linux

The whole ABI is different, not just the binary format (Mach-O versus ELF) as sepp2k mentioned.

For example, while both Linux and Darwin/XNU (the kernel of OS X) use sc on PowerPC and int 0x80/sysenter/syscall on x86 for syscall entry, there's not much more in common from there on.

Darwin directs negative syscall numbers at the Mach microkernel and positive syscall numbers at the BSD monolithic kernel ­— see xnu/osfmk/mach/syscall_sw.h and xnu/bsd/kern/syscalls.master. Linux's syscall numbers vary by architecture — see linux/arch/powerpc/include/asm/unistd.h, linux/arch/x86/include/asm/unistd_32.h, and linux/arch/x86/include/asm/unistd_64.h — but are all nonnegative. So obviously syscall numbers, syscall arguments, and even which syscalls exist are different.

The standard C runtime libraries are different too; Darwin mostly inherits FreeBSD's libc, while Linux typically uses glibc (but there are alternatives, like eglibc and dietlibc and uclibc and Bionic).

Not to mention that the whole graphics stack is different; ignoring the whole Cocoa Objective-C libraries, GUI programs on OS X talk to WindowServer over Mach ports, while on Linux, GUI programs usually talk to the X server over UNIX domain sockets using the X11 protocol. Of course there are exceptions; you can run X on Darwin, and you can bypass X on Linux, but OS X applications definitely do not talk X.

Like Wine, if somebody put the work into

• implementing a binary loader for Mach-O
• trapping every XNU syscall and converting it to appropriate Linux syscalls
• writing replacements for OS X libraries like CoreFoundation as needed
• writing replacements for OS X services like WindowServer as needed

then running an OS X program "natively" on Linux could be possible. Years ago, Kyle Moffet did some work on the first item, creating a prototype binfmt_mach-o for Linux, but it was never completed, and I know of no other similar projects.

(In theory this is quite possible, and similar efforts have been done many times; in addition to Wine, Linux itself has support for running binaries from other UNIXes like HP-UX and Tru64, and the Glendix project aims to bring Plan 9 compatiblity to Linux.)

Somebody has put in the effort to implement a Mach-O binary loader and API translator for Linux!

shinh/maloader - GitHub takes the Wine-like approach of loading the binary and trapping/translating all the library calls in userspace. It completely ignores syscalls and all graphical-related libraries, but is enough to get many console programs working.

Darling builds upon maloader, adding libraries and other supporting runtime bits.

Darling (link) is a project that aims to become analogous to wine. Currently it only runs some command-line OSX programs, though. As of mid-2019, it can run many command-line programs, and according to their homepage appears to be approaching the point where it can run some rudimentary graphical software as well. It probably won't run what you want just yet, unless it's text-based.

As long as the developers of the OS X program released their source code and used cross-platform libraries (such as QT, GTK, X11, GNUStep or WxWidgets) you should be able to re-compile an OS X program for linux. OS X and Linux are much more compatible at the API level than the ABI level.

GNUStep implements the Cocoa APIs of NeXTStep and OS X. It was shockingly complete when I tried it, in terms of how much it seemed capable of doing versus how little seems to use it in the wild. GNUStep only works on the source-code (API) level, so it works if a program is open-source and uses Apple's Cocoa GUI (NOT "Aqua" which is proprietary). It depends on being able to compile and link the code.

Think of the API, or Application Programming Interface, as something like a car's dashboard - everything is visible to the driver of the car, and you can get into someone else's car and find his different dashboard just as easy to figure out.

Think of the ABI, or Application Binary Interface, as the engine of the car - it can vary greatly between makes and models, and you probably won't be able to trade your Chevy engine into a Volvo very easily.

Darling would in this analogy be putting the Chevy engine in a Volvo's chassis, and compiling from source would be like just getting out of your Chevy and getting into the Volvo. One is much simpler to do than the other from a programmers' perspective.

But Apple has some proprietary user interface libraries that no one else has, too. If the developer used one of these (such as Aqua), you'll have to wait and hope that Darling grows up like Wine did, or port it yourself. If there is no source code released, it'd be like if the engine was made so big that it could not fit in the Volvo's engine bay, or designed for connecting to a front wheel drive car where your Volvo was rear wheel drive. Unless someone is an absolutely insane maniac (in the best possible way) who has months of free time and ridiculous amount of dedication, it's not likely to happen.

Additionally, GNUStep is not 100% complete in terms of coverage of the Cocoa API's, so some shoehorning is likely still going to be necessary for complex programs. And GNUStep does not provide an xcode-equivalent build system - that is, if the original developer used the XCode IDE's "build" system exclusively, you may be left writing makefiles for it. This was the most frustrating part for me, since while I have experience with compiling and linking software, it's hard to wrestle useful information out of a format like a .xcodeproj that I have no prior backend experience with.