Linux Mint Forums
Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.
Compatibility layer for Mac apps?
Post by Gryphus One » Sat Jan 30, 2010 7:04 pm
Hi, I’m asking this question in this Linux Mint forum but I could do it in the forum of any other distro or in a Linux general one.
The thing is: you know there is Wine, a compatibility layer to attempt to execute Windows’ programs in Unix based operating systems, like Linux, FreeBSD and Mac OS X.
But my question is: why does nobody make a compatibility layer to execute Mac’s programs on Linux? it should be much easier than Wine, since unlike Windows, both Mac OS X and Linux are based on Unix. And this is true to the point that Mac OS X is said to be able to execute Linux programs, so it should be possible to do the other way round without a great effort.
Can anyone explain me this, please?
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: Compatibility layer for Mac apps?
Post by Husse » Mon Feb 01, 2010 10:08 am
Even if both are related to Unix they are distant relatives and it is probably not to far from the truth if one assumes that Apple has done things to their programs so they don’t play on Linux
Midnighter Level 6
Posts: 1327 Joined: Tue May 22, 2007 1:52 pm Location: Western Australia
Re: Compatibility layer for Mac apps?
Post by Midnighter » Tue Feb 02, 2010 3:53 am
Binary compatibility between Mac OS X and Linux
We have two systems with similar hardware (main point being the processor, let us say a standard intel core 2 duo). One is running (insert your linux distro here: Ubuntu will be used henceforth), and the other is running let’s say Mac OS X. One compiles an equivalent program, Let us say something like:
- If one were to develop a program to repackage the flat binary produced from our Ubuntu system, in the Mach-O formatting, would it run in the Mac OS X system? Then, if one only had the compiled binary of the supposed program above, and one had this mystical tool for repackaging flat binaries, would simple programs be able to run on the Mac OS X system?
Now let us take it a bit further.
We now have a program with source such as:
- Assuming this program is compiled and statically linked, would our magical program still be able to repackage the raw binary in the Mach-O format and have it work on mac os X? Seeing as it would not need to rely on any other binaries, (for which the mac system would not have in this case)
And now for the final level;
- What if we used this supposed program to convert all of the necessary shared libraries to the Mach-O format, and then instead compiled the program above with dynamic linking. Would the program still succeed to run?
That should be it for now, obviously each step of absurdity relies on the previous base, to even make sense. so If the very first pillar gets destroyed, I doubt there would be much merit to the remaining tiers.
I definitely would not even go as far as to think of this with programs with GUI’s in mind. Windowing systems would likely be a whole other headache. I am only considering command line programs at this stage.
Now, I invite the world to correct me,and tell me everything that is wrong with my absurd line of thinking.
5 Answers 5
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 basically correct as to what the problem is, but the issue isn’t really libraries (which could be dragged along) but system calls, which are requests to the OS kernel. If the OS doesn’t provide a compatible system call interface, you are out of luck.
Aah, This is excellent. This is exactly the kind of constructive correction I was hoping for. Thanks a bunch 😀 Could you tell me more about these supposed system calls, or redirect me to somewhere I can learn more about them?
That said, your «crazy» idea isn’t completely impossible. Just a lot of work. The Wine project is essentially this for running MS Windows binaries on Linux (or OS X). It provides a translation layer for system calls. wiki.winehq.org/…
Well, I figured it wouldn’t be completely impossible, but I also did not expect it to be nearly as simple as I described it. I wrote the question with the intention of being corrected. This at times seems like a more efficient method of getting to the heart of the matter than asking a direct question such as «How do I convert a linux binary to run on Mac OS «. Also I have used wine from time to time, but I had never really pondered about how it worked before, I think I shall go look into it sometime now.
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.
One of the reasons this isn’t a big deal for Linux programs → other platforms is: there’s no significant Linux-only apps for which source isn’t available. You want to run your program on OS X or Solaris, recompile it, and there ya go. There may be a little porting to do where the code was written in Linux-specific ways, but generally that’s not a lot of work, especially compared to maintaining the compatibility layer. FreeBSD’s Linux compatibility was a big deal back when Netscape was a binary distributed for Linux only, and probably still is used for Adobe Flash Player.
@Jörg W Mittag — also, you needed to have the system libraries from the other platform available. This may have been the basis for their suit against AutoZone. But honestly I forget the details and barely care anymore. 🙂
So what you say is essentially, that if operating system X provides the same services as operating system Y, then a binary can run under both. This is true, but require a deliberate effort for system X. I am unaware of any operating system being compatible in this way with OS X.
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.
Compatibility layers
While not strictly emulation per se (hence why Wine stands for «Wine Is Not an Emulator»), compatibility layers allow software written for one operating system to run on a different OS, often by translating API and system calls made by an application to their equivalent calls in the host operating system. In theory, this should allow for near-native performance since no processor emulation takes place, but in practice some software such as games will tend to run a bit slower due to other bottlenecks that occur as a result of replicating the correct behavior, such as accounting for graphics APIs like Direct3D that aren’t supported on non-Microsoft platforms. Additionally, compatibility layers may also use emulation in order to run software built for a different architecture.
Compatibility layers [ edit ]
| Name | Operating System(s) | Latest Version | FLOSS | Active | Recommended | Runs the following software | ||
|---|---|---|---|---|---|---|---|---|
| PC / x86 | ||||||||
| Wine | 8.0.1 (Dev: 8.8) | ✓ | ✓ | ✓ | Windows applications and games | |||
| Proton | 7.0-6 | ✓ | ✓ | ✓ | Windows games, included with Steam | |||
| TeknoParrot | 1.0.0.140 | ✗ | ✓ | ✓ | PC-based arcade games | |||
| Rosetta | N/A | ✗ | ✓ | ✓ | x86 macOS applications (PowerPC macOS apps on earlier versions) | |||
| CrossOver | 22.1 | ✗ | ✓ | ✓ | Windows applications and games | |||
| Minecraft Bedrock Launcher | v0.10.0 | ✓ | ✓ | ~ | Minecraft: Bedrock Edition (Android version) | |||
| Anbox | git | ✓ | ✓ | ✗ | Android software | |||
| Darling | git | ✓ | ✓ | ✗ (WIP) | macOS software | |||
| WineVDM | git Dev | ✓ | ✓ | ✗ | 16-bit Windows apps and games | |||
| Wineskin | 1.7 | ✓ | ✗ | ✗ | Windows applications and games | |||
| WineBottler | 4.0.1.1 Dev | ✓ | ✗ | ✗ | Windows applications and games | |||
| WoW | ? | ✗ | ✗ | ✗ | Windows 9x apps and games | |||
| Win3mu | ? | ✓ | ✗ | ✗ | Windows 3.x apps and games | |||
| NTVDMx64 | git | ✓ | ✓ | ✗ | DOS applications and games | |||
| Ardi Executor | 2.1.17 | ✓ | ✗ | ✗ | Classic Mac OS software up to System 6 | |||
| DOSEmu | 1.4.0 | ✓ | ✗ | ✗ | DOS software | |||
| DOSEmu2 | git | ✓ | ✓ | ✗ | DOS software | |||
| Mobile / ARM | ||||||||
| Box86 | git | ✓ | ✓ | TBD | x86 Linux programs | |||
| Wine | 8.8 | ✓ | ✓ | ~ (WIP) | Windows applications and games | |||
| Hangover | git | ✓ | ✓ | ✗ | Windows applications and games | |||
| Anbox | git | ✓ | ✓ | ✗ | Android software | |||
| FEX-Emu | git | ✓ | ✓ | TBD | x86 and X86-64 Linux programs | |||
| Skyline | TBD | ✓ | ✗ | ~ | Nintendo Switch games and homebrew | |||
| Console | ||||||||
| Nintendont | git | ✓ | ✓ | ✓ | GameCube games | |||
Comparisons [ edit ]
- Wine is a free and open-source compatibility layer that aims to allow computer programs (application software and computer games) developed for Microsoft Windows to run on Unix-like operating systems, primarily Linux and macOS. Since late 2017 there is also an experimental build for Android. Wine is almost as old as the Linux project, starting in the summer of 1993. Today it’s widely used, very popular and sponsored by companies such as CodeWeavers and Valve. The core Wine development aims at a correct implementation of the Windows API as a whole. In this regard it’s similar to the MAME project in its focus on correctness over usability. There are a lot of versions/forks of Wine which focus of different goals, such as usability, compatibility, gaming, office applications, etc. A few are listed below, Wikipedia has a more complete list.
- Proton is Valve’s one-click solution to play Windows games on Linux. It’s included in the Steam Linux client by default. Simply click on a whitelisted game and it will launch without any configuration, or enable it for all games in the settings. Proton is based on a fork of Wine in combination with other components such as DXVK (explained below) and FAudio.
- CrossOver is a commercialized, supported version of Wine from CodeWeavers. It uses additional patches on top of Wine to make it easy to use. They contribute all of their work on CrossOvers back to Wine and make up about two thirds of the commits made to Wine. CrossOver is available on macOS, Linux and Chrome OS.
- Wineskin is an open-source compatibility layer which allows users to easily convert Windows software to macOS. The ports are in the form of Mac .app bundles with a self-contained Wine instance which are wrapped around the application to be converted.
Wrappers [ edit ]
Compatibility layers may also make use of wrappers, which translate a specific graphics API to another. How the user sets up the wrapper varies between each project but most involve a drop-in replacement of the original libraries.