

Maloder: OSX binary loader for Linux. - naner
https://github.com/shinh/maloader#readme

======
biot
I would have preferred the name "MacLoad: there can be only one".

------
wtallis
I wonder how hard it would be to implement the Apple Obj-C runtime's ABI for
GNUstep so that this could be used to run obj-c programs and perhaps
eventually actual Mac apps. If it were shown to be feasible, I would expect
the combination to get a lot of attention as an alternative to Wine for
running proprietary apps on Linux.

~~~
geocar
The actual Objective-C API is very small and can be (naively) implemented in
an afternoon. I'd expect programs that already work in GNUStep like GNUmail
could be had running by someone who has knowledge of how LD_PRELOAD works but
no other experience with GNUStep and OSX in a week or two.

~~~
natesm
The only significant thing missing from _Objective-C_ itself is garbage
collection, I think (which completely changes the game on Mac OS X). Blocks
work, of course, and besides that, Objective-C doesn't actually add that much
to C (that's sort of the point).

The Cocoa APIs are, of course, fairly incomplete. From a quick Google search,
they don't seem to have finished Core Data, and I'd imagine things like Core
Animation are quite a ways off. Then, there's the integration problem. People
that are likely to develop with an alternative implementation of Cocoa are
likely to be "Mac people", that is, user interface evangelists (Lion's iCal
design aside). GNUStep apps don't fit in with Gnome, or KDE, or, well, any
desktop environment that a large group of people care about.

As a person (admittedly, I'm just a student) that has developed both in Cocoa
and GTK+, I've found convincing myself to work on my GTK+ projects to be a
chore. To put it only somewhat mildly, Cocoa is probably the best framework
I've ever used. Want something to smoothly slide to the left? You can do that,
in one line of code. Want to pull down some data from the web and parse the
XML response, all in a background thread? That's easily achievable with Cocoa,
and you don't even have to think about the threading issues. It just happens.

GTK+ et. al. are, of course, open source projects. They're created by
volunteer developers (let's leave Red Hat out of this, for convenience). In
the end, though, does it matter to developers? Cocoa is fun. GTK+ has mostly
directed me into hours of reading C API documentation while I'm writing code
in languages that are not C.

I'm not really sure where I intended to go with this - it has little to do
with the original post, which I think is an incredibly impressive piece of
work, solving a task that make my API and UI concerns seem like minor
squabbles.

~~~
rchowe
GNUStep also has garbage collection (albeit Boehm, not the same as the
collector in OS X). Yes, it is missing from the language, but it doesn't make
OS X special. And all that needs to come along is a version of GNUStep that
fits in with the desktop environment on a platform before people start
developing for it.

------
mark_l_watson
Off topic: asking for some advice, since this loader sounds close to what I
want. The problem: I need to use a _huge_ C++ codebase that is developed on
the Mac, and is used to generate a shared library used in a Java app with JNI,
SWIG, and loaded with loadLibrary. It would be fantastic to be able to build a
shared library on the Mac, and be able to use it on both Macs and Linux
servers. Maintaining and building 2 versions is a nuisance. (A complete build
takes a couple of hours, even on a fast box.) Probably not possible because
shared libraries are very different on OS X and Linux, but long term it would
save me a lot of time if it is, even if I had to patch the Linux JVM.

~~~
nupark2
This loader will be buggy and incomplete, by it's nature, and won't really
solve the problems inherent in loading a shared library from another OS into
an existing native process.

~~~
mark_l_watson
Thanks for the response! It was a long shot, but I thought that I would ask in
case someone new of a stable and reliable way to use OS X shared libraries on
Linux. I imagine it would be easier on NetBSD.

~~~
ori_b
Not really. The problem is the binary format itself - Linux, *BSD, and pretty
much every Unix but AIX these days uses ELF, but OSX uses MachO. The two
aren't compatible.

The easiest way to do this reliably would probably involve writing your own
mini-linker load the Mach-O binaries in Linux from the JVM, bypassing dlopen()
and friends.

~~~
pyre

      > pretty much every Unix but AIX
    

OSX is actually a certified UNIX.

[http://arstechnica.com/apple/news/2007/08/mac-os-x-
leopard-r...](http://arstechnica.com/apple/news/2007/08/mac-os-x-leopard-
receives-unix-03-certification.ars)

~~~
cycojesus
and? Nowhere is the opposite stated or implied.

------
pbburns
This is very cool. Forgive me if I'm missing something but this only runs very
specific command line programs right? (ie no iTunes)

~~~
Xuzz
For now. In theory, with enough emulated libraries, you could probably run
anything with this. But I don't think the point is to run "random mac app" on
Linux: it's probably more likely to enable something like iPhone development,
which right now is Mac only.

~~~
sliverstorm
Just watch as Apple, in their infinite wisdom, decides to shut this down
because the developers aren't paying to buy the macs needed for development.

~~~
mambodog
Is there any precedent for your assertion?

~~~
dschobel
yes.

[http://www.engadget.com/2010/04/08/apples-iphone-lockdown-
ap...](http://www.engadget.com/2010/04/08/apples-iphone-lockdown-apps-must-be-
written-in-one-of-three-la/)

~~~
mambodog
I don't consider the 3.3.1 situation to be relevant, as in this case you would
be running the official Apple toolchain.

If you had brought up the section of the iOS Developer License Agreement
relating to "non-Apple-branded hardware" you might be in the right ballpark,
but the legality of a similar clause in the Mac OS EULA was cast into doubt in
the Psystar case. Psystar aside, the (non-commercial) OSx86 scene continues to
thrive, unhindered by Apple.

At the end of the day, given that you would be running the official Apple
toolchain, how would Apple be able to prove that a particular iOS app was not
built on a Mac?

------
tomrod
I read the name of this, and thought "Mal Odor... oh dear."

That being said, this is like a Mac version of Wine for Linux? If so, cool.

------
veyron
On the other side, is there a good "ELF.kext" or "Linux.kext" for running
Linux programs on OSX?

------
verysimple
It's not too late to change its name.

