A New Project To Run Mac OS X Binaries On Linux

[ryao]

Hi, first of all I'd like to say I'm happy I made it to Phoronix :-)


I started the project in August this year. When working on something of this size, you have to start small. There's just no other way.

The next big thing (which is quite close by the way) is to have Apple LLVM-GCC fully working. That would basically mean you could compile applications for iOS on other platform than OS X. This is currently not possible. Anybody who wants to do iOS development has to buy a Mac. That sucks big time. iOS is not very popular in this part of Europe, but at least in the US I believe it's still the platform no. 1 for mobile apps.

Getting iOS apps running on... say Android is a different story. I'm planning on supporting ARM (and good old PPC too, while I'm at it) in the dynamic loader and the ObjC runtime. The frameworks itself is I think a job for someone else, because as I've said, I don't see that many iOS devices around so I lack the motivation.

Just for OS X apps, there is lots and lots and lots of work to do. Anyone who's ever written a piece of software for OS X could start mentioning loads of frameworks specific to this platform. While I'm enjoying the work, I also realize that I don't stand much chance to have anything suitable for end users in a short time frame. So if there are any guys out there willing to help out, be it with GNUstep or something that I actually write as part of Darling (IOKit userspace libs, Apple Events support, etc....), help is always welcome. You don't even need to have any experience with writing software for OS X...

Luboš

I have a few comments that you might or might not appreciate:

1. You should pay strong attention to getting the syscall layer correct. If you implement the syscall layer well, it should be possible to use Mac OS X's userland on top of the lower level layers. That would enable you and others to compare the Mac OS X userland against the OSS userland components. That should make this significantly easier. It would also enable you to try a userland from Apple's Darwin images.
2. You can use Gentoo Prefix to assist you in development. It is a userland package manager that lets you build a fairly large body of existing UNIX software for Mac OS X. What should be particularly interesting to you is that its dependencies are fairly light. Installing it should require only standard UNIX utilities, a toolchain, libc and the system headers. Once it is installed, it depends on only libc and the system headers. There might be a few other libraries that I missed, although they would be things like libm and libdl.
3. If you are interested in seeing widespread adoption, it might be better to pick a less restrictive license. The WINE project uses the LGPL, which would probably work well for you. It is important to make a decision on this before you start receiving contributions, because it will be a pain to switch should you change your mind afterward. This is especially true with the GPLv3 because people tend to be very litigation-happy when things involve it.
4. This is an awesome idea. Ignore people that say that this is a waste of time. Their opinions are not worth your attention.

WINE is a failure. After like 20 years of development, millions in donations, and an army of developers, the best it can do is (maybe) run your Windows applications(with some extra bugs and worse performance).

A couple of years ago I evaluated running half a dozen enterprise Windows applications in WINE. WINE failed to run any of them adequately, most couldn't even start, and it was always because of some unimplemented function in a DLL somewhere... Maybe after 40 years of development WINE will adequately run 90% of applications written for Windows 2000.

If that doesn't tell you that "Not An Emulators" are a waste of time, I don't know what will.

It would be interesting to run WINE on top of Darling. Anyway, there are two approaches to running foreign binaries on a system. One is to implement the syscall layer and rely on the foreign operating system's userland to enable it to work (the OS/2 approach). The other is to try to implement both the kernel and userland (the WINE approach). The former was very successful in its time and does not require many resources. The latter is a nightmare.

I doubt that Darling would result in making Linux into a perfect replacement for Mac OS X, but I think Darling would make Mac OS X development on Linux easier. If Darling can obtain near perfect operation when paired with Mac OS X's actual userland, that would be a nice bonus.