Install Windows Software: Windows software doesn’t run natively on Linux. There are several ways to install and run Windows software on Linux, including the Wine compatibility layer (which isn’t perfect) and by installing Windows itself in a virtual machine (which adds a lot of overhead.).

I have the urge to commit my 24' Core 2 Duo iMac to a single Linux operating system, thus giving up the goodness of my beloved Mac OS X. I am not a stranger to Linux, but I am a stranger to running Mac apps on Linux. On my PowerPC I can use SheepShaver to run Classic apps. The Mac-on-Linux project can run OS X apps, but it requires a PowerPC, not an x86. Virtualizing and emulating are inefficient, especially given the wonderful results the WINE project has had in getting Windows apps to run on Linux. What I would like is an equivalent: a software compatibility layer that will allow Linux to run Mac OS X apps at native performance.

I believe there is some additional complexity in accomplishing this. Mac OS X apps aren't just Mac OS X apps. They are Carbon. They are Cocoa. They are universal binaries.

They are PPC code with Altivec. Does such a project exist yet? If not, why not? Wine is an open source implementation of the Windows API, though it can use Microsoft dlls if you supply them. I'm operating under the assumption that Cocoa and Carbon use Unix APIs at some level, since they sit on top of a Unix core. So as Wine is an implementation of the Win32 API, the Win32 API is just a fairly low-level API that lets you make windows and buttons and pull-down menus, access the filesystem, access task and memory management, etc., but if you want any of the niceties of newer Windows applications, like toolbars, reconfigurable menus, fancy controls, Windows media, etc., you need Windows/Microsoft DLLs that aren't a core part of the Win32 API proper. Sure, Wine provides open source implementations of some of these, but in most cases you need them provided from the application or from a copy of Windows.

The analogy is not quite the same, with Cocoa and Carbon, but I think you get my point. Carbon is a sort of bizarre chimera library, which was intended to provide a compatible set of APIs between classic Mac OS and Mac OS X.

So that once OS X was on the way, you could carbonize an app under Classic and have it just work on OS X. Brilliant idea, but it means Carbon isn't a close relative of anything. It's a huge library and framework (since it spanned multiple operating systems), and would basically have to be engineered from scratch.

In contrast, Cocoa is what used to be OPENSTEP; it's just. A wine-like system for OSX would actually be a lot easier to accomplish.

There is already something iBCS, which lets Linux run binaries from other x86 unix-like systems (SCO, Xenix etc. Old stuff), and various BSD's have the ability to execute Linux binaries. You only need to emulate the kernel interfaces, and then the user mode programs/libraries should run atop a Linux kernel just like they run on OSX's existing kernel. Then you can begin reimplementing the proprietary libraries one by one. Those libraries which are BSD licensed you can directly port the source.

All in all, a much easier job than wine. Wine doesn't really emulate Windows libraries, it runs them directly. Wine implements the Windows API. Wine does not use any software from Microsoft.

Windows programs are just run with the Wine implementation instead of the Microsoft implementation. The Cocoa API is based on the OpenStep API, which has a [gnustep.org].

We've had a FOSS implementation of the OpenStep API for years: GNUstep. GNUstep has even implemented some of the Cocoa additions. Producing a Cocoa compatibility layer should be much easier than producing a Windows compatibility layer. Producing a Cocoa compatibility layer should be much easier than producing a Windows compatibility layer. There are a few more things required than just GNUstep. GNUstep gives source compatibility and is now fairly good at reading nib files. In order to run OS X pure-Cocoa applications you would also need a Mach-O binary loader.

Linux uses ELF as the format for binaries, and so the loader can not start and link OS X applications. Next you would need to compile the Apple (NeXT) Objective-C runtime library on Linux. This is pretty easy (the code is ASPL), but currently GNUstep has problems running with the NeXT libobjc (it uses the GNU one by default). If you did this, you could run applications that just used Cocoa. Unfortunately, a lot of OS X applications also use Carbon. There is no open source version of Carbon, although a few people have written GNUstep wrappers for the parts of Carbon which are toll-free bridged with Cocoa. You would also not be able to run anything that depends on WebKit (unless you use GNUstep's SimpleWebKit as a stop-gap), QuickTime, or any of a number of other frameworks that have not yet been added to GNUstep.