A New Project To Run Mac OS X Binaries On Linux

[WorBlux]

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.

On the other hand, the FreeBSD kernel has nearly perfect Linux binary support. The issue with Wine is that the windows interfaces are convoluted, undocumented, and have multiple incompatible implementations that need to be supported. I'd imagine Mac is closer to Linux as architecturally goes than it is to Windows.

[schmidtbag]

But none of those things are related to the reasons people are interested in running apps from OS X.

Yes, you can run X11 and OpenGL programs on a Mac. But guess what? As far as I know, every one of those programs already runs on Linux. The reason people wanted X11 on Macs was so they could run open source applications!

BSD, X11 and OpenGL aren't going to help you, however, if what you want to do is run an app that uses Quartz and/or any of the other Mac-specific frameworks.

Like I said in my animal analogy, mac and linux are 2 completely different animals, different to the point that you could never cross-breed them no matter how hard you try, but they're similar enough that it doesn't take much effort to figure out how to make them compatible to some level. The reason I brought up things like opengl or having a *nix background is because those put more relation to each other than they would have with Windows. Windows has no compatibility with X11 that I'm aware of. Most Windows programs use DX (and we all know how perfectly DX translates in wine). Windows has a kernel unlike any other. While Mac and Linux (or FreeBSD for that matter) are all binary incompatible, they're all similar enough that even if you don't have direct access to the code, they're EASIER to figure out if you've been a linux developer for a while. So for example, it should take less effort to make a Mac game run on linux because it'll already be in opengl and most macs don't have all the fancy high-end GPU features. Or, the Adobe CS could take less effort than the Windows version because the window management is different (maybe not X11 but still different). There would also be less confusion with file attributes and drive association. You won't have to worry about so many quirky installaton methods either - I've found most Mac programs install the same way. And I'm sure one thing that would be handy is BASH. Macs do use a CLI backend, you usually just never see it unless you're in a hackintosh. This makes debugging much easier.

[conathan]

Personally, I am quite happy to hear about this project, and can already think of a few uses.

I have a linux to macosx cross compiler which works fairly well (Although wishing I could get a newer version of CCTools). I have my work posted at http://nathancoulson.com/proj_cross....apple-darwin10, which wouldn't have been possible without all the other similar projects I found. (although I missed RayDonnally's work. I'll have to see what secrets he holds)

There is one thing my cross compiler cannot do, and that is code signing. On OSX, there is a tool called codesign, and unfortunately it does not look like there's a version that will work under linux (and all of my development is done in linux, then cross compiled for other platforms).

For linux to windows development, I use wine to run wixtools, and osslsigncode to sign the .exe/.dll files (I wish it also worked on .msi, but alas)


This would be amazing if it could be used as the main C Library for gcc (when building cross compilers) Currently, that is the one missing part, which has to be downloaded from apple.

[liam]

It will be interesting to watch how many people contribute. I do not imagine many people would find the idea that contributing to LubosD's project would enable him to enrich himself very appealing. The project might encounter legal problems should he fail to clarify that to contributors.

I would think that would be more of a concern when contributing to more BSD-type projects.
I write the code, a company grabs it, makes some changes which go down their binary hole.
GPL isn't such a bogeyman.

[LubosD]

Great project, congratulations on the progress you've made.

To prevent some duplication, here's another project with similar goals (apologies if you've already aware of it):

https://github.com/shinh/maloader
http://shinh.skr.jp/slide/ldmac/000.html

I actually based my work off maloader :-) If you look down the commit history of Darling, you'll see it.

I agree that not having cross compilers (for any platform) sucks, but it's not strictly true that there are none for iOS/OSX; there's been a few projects dedicated to making cross compilers for Darwin (xchain, toolchain4, puredarwin and opendarwin). I've adopted, modernised and improved them, forking from javacom's toolchain4:

Oh yes, I've seen these. But after I fix the little problem with ofstream failing to flush data to a file (some sort of ABI problem in cc1), then we will have something working out of the box with a 100% guaranteed result. Now that's worth fighting for!

[LubosD]

It will be interesting to watch how many people contribute. I do not imagine many people would find the idea that contributing to LubosD's project would enable him to enrich himself very appealing. The project might encounter legal problems should he fail to clarify that to contributors.

Oh I'm not doing this to enrich myself. I only said I want to prevent others making money on my (and other people's) work without sharing back! GPL takes care of this very well.

[LubosD]

There is one thing my cross compiler cannot do, and that is code signing. On OSX, there is a tool called codesign, and unfortunately it does not look like there's a version that will work under linux (and all of my development is done in linux, then cross compiled for other platforms).

codesign is tricky. For codesign, you need to have Security services/framework working. The good thing is a) it is open source (APSL) b) I remember having successfully compiled a great deal of this, but I did not have any use for it, so I put it on the backburner. But now I know about codesign being important.

[RayDonnelly]

codesign is tricky. For codesign, you need to have Security services/framework working. The good thing is a) it is open source (APSL) b) I remember having successfully compiled a great deal of this, but I did not have any use for it, so I put it on the backburner. But now I know about codesign being important.

You can find a Linux arm-apple-darwin11-codesign_allocate with my cross compilers:

http://mingw-and-ndk.googlecode.com/...-120724.tar.xz

I've never tried it, having only run stuff on jailbroken ithings.

[mike4]

Wine is not a failure but very good. With 1.4 I run all my Windows apps perfectly and can finally say goodbye to Windows. Having alike for OSX would allow people like me to leave osx.

[Pallidus]

FINALLY ...


I have made threads in the past questioning exactly why people weren't developing a os x wine.


BEING ABLE TO RUN FINAL CUT PRO 7 ON LINUX = OMG


I hope the performance is better than wine tho, but I bet it is since os x it's all bsd and bsd is unix and linux is sorta the same shit with x11 and stuff like that.