A New Project To Run Mac OS X Binaries On Linux

[curaga]

Somewhere down the line, I think it'd be cool if there was a PPC version of this that could run the old mac programs. I would only expect this to work on a PPC processor of course.

Wasn't there already something for that? Mac-on-linux it was called IIRC.

[LubosD]

Wasn't there already something for that? Mac-on-linux it was called IIRC.

Mac-on-Linux is a virtualization software.

I plan to support PPC, but the problem are the APIs. I guess Carbon was way much popular back in the PPC times and I don't have time to reimplement that. I need to focus on what is not obsolete.

[schmidtbag]

Mac-on-Linux is a virtualization software.

I plan to support PPC, but the problem are the APIs. I guess Carbon was way much popular back in the PPC times and I don't have time to reimplement that. I need to focus on what is not obsolete.

First of all, I commend you for your efforts, including the fact that you want to focus on modern and relevant software. The funny thing is I actually don't seriously care about running most Mac programs on linux, BUT, since this project is likely to be a greater success than wine (and in less time), and since many popular windows programs/games are also on Mac, I think this project could be a lot more useful than wine. I believe there is more potential to this project than many people are aware.

I just realized that my own comment on PPC might be pointless, because maybe you could just put a lot of focus on Rosetta. Getting that to work ought to ease some stress for you.

[LubosD]

First of all, I commend you for your efforts, including the fact that you want to focus on modern and relevant software. The funny thing is I actually don't seriously care about running most Mac programs on linux, BUT, since this project is likely to be a greater success than wine (and in less time), and since many popular windows programs/games are also on Mac, I think this project could be a lot more useful than wine. I believe there is more potential to this project than many people are aware.

I just realized that my own comment on PPC might be pointless, because maybe you could just put a lot of focus on Rosetta. Getting that to work ought to ease some stress for you.

Rosetta? Well, you could use qemu-ppc with Darling & friends crosscompiled for PPC. The question is how fast it would be, because its direct relative called qemu-system-ppc is either very slow or totally broken. After waiting for 2 minutes for it to load a Linux kernel, I gave up. Anyone running Linux on PlayStation 3 would get that overhead-free, of course.

Today, I put up the project on github instead my own git server, so that could hopefully entice more curious developers.

[popper]

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š

most people around here don't seem to remember the apple emulation history so ill mention that
you may get some code, loader etc insight from the old emulators http://en.wikipedia.org/wiki/SheepShaver
http://sheepshaver.cebix.net/
"SheepShaver is a MacOS run-time environment for BeOS and Linux that allows you to run classic MacOS applications inside the BeOS/Linux multitasking environment. This means that both BeOS/Linux and MacOS applications can run at the same time (usually in a window on the BeOS/Linux desktop) and data can be exchanged between them. If you are using a PowerPC-based system, applications will run at native speed (i.e. with no emulation involved). There is also a built-in PowerPC emulator for non-PowerPC systems."

"Supported systems

SheepShaver runs with varying degree of functionality on the following systems:

• Unix with X11 (Linux i386/x86_64/ppc, NetBSD 2.x, FreeBSD 3.x)
• Mac OS X (PowerPC and Intel)
• Windows NT/2000/XP
• BeOS R4/R5 (PowerPC)"

"Some of SheepShaver's features

• Runs MacOS 7.5.2 thru 9.0.4. MacOS X as a guest is not supported."

https://github.com/cebix/macemu/tree/master/SheepShaver

people seem to be still patching it.

you might even find something useful here too use if your after the older API's etc
http://en.wikipedia.org/wiki/Emulati...ac_OS_on_Amiga
http://amigamac.wikispaces.com/
http://shapeshifter.cebix.net/

[ryao]

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.

How is the LGPL different?

[pjlahaie]

This is something I think about every now and then. So far, I'm using the Wine approach.

There is a problem with the OS/2 approach: unlike what you believe, it requires a *huge* investment of time in developing all the layers, which leads to basically recreating the original system. And that doesn't integrate very well with a Linux (desktop) environment. There will always have to be a line where you stop immitating and start integrating with "standard Linux layers".

There is currently another related project "Project Magenta" which aims to re-implement a binary compatible kernel / userland for iOS applications.

They have already implemented the Mach ports as a kernel modification.

In theory, there is no reason why you couldn't implement Darwin binary compatibility using the same method that Solaris / Sys V compatibility was achieved with Linux.

Perhaps creating a mailing list / forum for this project would be helpful seeing as there is bound to be interest from others on developing this further.

I've always wondered why no OS X app compatibility was done for Linux, seeing as the base API (OpenStep) is both public and implemented as OSS (GNUstep), all the loader bits are available via Darwin. All that is missing is re-implementing Apple's proprietary services (Quartz / DisplayServer)

Paul

[pjlahaie]

most people around here don't seem to remember the apple emulation history so ill mention that
you may get some code, loader etc insight from the old emulators http://en.wikipedia.org/wiki/SheepShaver
http://sheepshaver.cebix.net/

SheepShaver runs with varying degree of functionality on the following systems:

• Runs MacOS 7.5.2 thru 9.0.4. MacOS X as a guest is not supported."

[/URL]

people seem to be still patching it.

you might even find something useful here too use if your after the older API's etc
http://en.wikipedia.org/wiki/Emulati...ac_OS_on_Amiga
http://amigamac.wikispaces.com/
http://shapeshifter.cebix.net/

PearPC would probably be a better place to start since it runs OS X, unlike SheepShaver which was (IIRC) a MacOS System 7-9 emulator.

http://pearpc.sourceforge.net/

Paul

[LubosD]

How is the LGPL different?

LGPL introduces a loophole that enables others to escape this restriction by linking with your LGPL code dynamically (plus other possible ways).

[LubosD]

There is currently another related project "Project Magenta" which aims to re-implement a binary compatible kernel / userland for iOS applications.

They have already implemented the Mach ports as a kernel modification.

Oh yes, I've seen Magenta and the Mach ports were the only feature that I found interesting in that project. Because the rest is just Apple's code with minimal added value.

In theory, there is no reason why you couldn't implement Darwin binary compatibility using the same method that Solaris / Sys V compatibility was achieved with Linux.

The reasons are:

• The additional amount work.
• The syscall interface is not the official ABI. There is no point in keeping it. They may choose to randomly renumber their syscall numbers without breaking anything. Because libc is the ABI for the syscalls. Linux emulation in FreeBSD is a completely different matter, these systems are much more alike.
• Mach syscalls are crap and we're better off emulating them in userspace where feasible. I'm getting remarkably better performance when emulating some of them in userspace, because those calls just don't belong into the kernel (thread synchronization primitives).
• Ease of installation. No need to patch the kernel, check for the right kernel version or anything.
• Ease of development. Without any doubt. Even the fact that I need to use plain C for kernel development is very limiting.
• Ease of getting the product released. Going through reviews of the kernel code may be useful, but it also means I can't easily distribute any experimental hackish code to the users.

When mentioning NetBSD's Darwin emulation, note that their code was highly experimental. A better part of IOKit was just dummy code and while browsing some of their Mach Ports code I got the feeling that they misunderstood certain aspects of this feature. And I'm not surprised. I have the feeling that no-one except for Apple's and GNU Hurd's developers knows how to use these :-D

Perhaps creating a mailing list / forum for this project would be helpful seeing as there is bound to be interest from others on developing this further.

Good idea. I'll do that.

I've always wondered why no OS X app compatibility was done for Linux, seeing as the base API (OpenStep) is both public and implemented as OSS (GNUstep), all the loader bits are available via Darwin. All that is missing is re-implementing Apple's proprietary services (Quartz / DisplayServer)

There's more missing. GNUstep would first need a Quartz backend. And then you'd have to emulate Quartz under X11 somehow. It's easier to just use any of the X11-compatible GNUstep backends, because the official ABI is "Cocoa".

My biggest worry though is the state of GNUstep. Once I started writing various tests, I started finding bugs immediately in stuff you'd expect to be stable and proven by now. It's quite bad, worse than I thought. Half of the OS X apps I've tested don't start because GNUstep can't even load the NIB (UI definition) file properly. I got me to the point of thinking whether it wouldn't be better in long term to implement Cocoa on top of something stable like Qt: that way we wouldn't have to worry about that many implementation details, slowly work through all the APIs and then replace GNUstep.

Of course, such an endeavor needs human resources and I don't have these.