Binary compatibility between Mac OS X and Linux

You forget one crucial thing, namely that your program will have to interact with the operating system to do anything interesting.

The conventions are different between Linux and OS X so the same binary cannot run as-is without essentially having a chunk of operating system dependent code to be able to interact with it. Many of these things are provided through libraries, which you then need to link in, and that means your program needs to be linkable, and linking is also different between the two systems.

And so it goes on and on. What on the surface sounds like doing the same thing is very different in the actual details.


This is doable if someone wants to spend enough time to make it happen. The Darling project is attempting this, though as of this writing, it's in a pretty primitive state.

It's been done successfully before on other platforms:

  • Solaris and UnixWare include a helper program called lxrun which works something like sudo: you pass your executable name and parameters to the helper and it fixes things up dynamically so that the executable can talk to the OS. The official site (down, archive link) says it's bitrotted.

  • Linux's kernel once had a feature called iBCS that did the reverse, except that it didn't need a helper because the kernel recognized the "foreign" binaries directly. It fell into disrepair during the kernel 2.3 development series, most likely because the small Unix server battle was essentially over once 2.4 came out.

  • FreeBSD's kernel can be configured to recognize Linux binaries and run them as if they were native. This feature appears to be in better shape than the above two.

    OpenBSD and NetBSD have similar features.

OS X has a lot of FreeBSD in it, so porting its Linux support might be straightforward.


I pretty much agree with everyone, but I want to add that, while this would take a significant amount of time and effort, it wouldn't be nearly as much as it has taken to develop Wine.

Much of the difficultly in Wine development is that they are porting a binary format from a closed source operating system and MANY of the system calls are undocumented. They had to essentially reverse engineer the operating system.

If someone were to do this from one open OS to another open OS, they could likely get it done in 1/10 of the time, since the compatibility layer could quite conceivably be copy/pasted from the other OS if an equivalent native system call doesn't exist. Of course, in most cases across the POSIX world, there will be a native call available.

Another project of note is ReactOS, where they're essentially creating a full binary-compatible version of Windows... no need for Wine.