Running Mac OS X Binaries With NetBSD

An anonymous reader writes "KernelTrap has an interesting article about an effort to add a Mach and Darwin binary compatibility layer to NetBSD. The project has evidently already made a fair amount of progress, currently working to stabilize the WindowServer emulation portion that will then allow NetBSD to run Mac OS X graphical applications."

You still need a PowerPC machine

[zubernerd]

to use this, since it is only binary compatability. So You will still need to buy PowerPC based computers. And who is one of the largest and most noted for selling powerPC based PCs... Apple Computer; so why not just run MacOS X?
I know you can buy third party PowerPC computer, but they are more expense than Apple's machines.
I do appricated their effort, it is probably a good exercise in programming skill.
It would be useful if it was on x86, but there are plenty of problems with that; see
http://www.emaculation.com/ppc.shtml [emaculation.com]


(This is not a flame, just an observation)

Nifty.

[Anonymous Coward]

Which will come first - Apple cracking down or them getting WindowServer to run on i386? Some info from http://hcpnet.free.fr/applebsd.html [hcpnet.free.fr]

What works?

On NetBSD/i386: nothing. On NetBSD/powerpc, most UNIX binaries, such as ls, sh, or vi will work. No Graphical User Interface (GUI) based program will work for now. We are able to startup WindowServer up to the first attemps to use the IOKit. See the kernel traces for WindowServer and for mach_init to discover how far we have been.

Here is what have been implemented so far:

Mach-O binaries loading

Mach system calls handling

Minimal Mach ports, messages and rights support, so that simple program are able to link and run.

Signals handling (except for siginfo) Minimal multithreading support

Support in ktrace/kdump to display Mach messages (useful for debugging)

Hacks to get mach_init starting (and to get it behaving as bootstrap mach_init)

Support for port rights carried by Mach messages
Here is what is in the TODO list:

Implement Mach notifications for destroyed ports, dead names, and no sender ports

Re-implement enough of Darwin's IOKit to get

WindowServer actually displaying something.

Use COMPAT_MACH for COMPAT_OSF1 (Tru64 binary emulation on NetBSD/alpha), to get multithreading working.

Get Darwin binaries to link and run on NetBSD/i386

Re:Is this a de facto x86 OSX?

[kakos]

Quite wrong. These guys are making a binary compatability layer, not emulation. You will not be able to run OS X applications on an x86 box running NetBSD, only a PPC box running NetBSD.

Re:What about...

[SiMac]

GNUStep allows for source-level compatibility. This is good for people who plan on targeting Mac OS X as well as Linux, but it's not good for people who want to run Mac OS X apps that run on Mac OS X but not on Linux, such as the Mac OS X window server and Finder. These applications would never be ported to GNUStep, as easy as it is, because Apple wouldn't do it. In addition, this should allow Carbon applications as well as Cocoa applications to run on NetBSD.

Re:Linux port?

[KAMiKAZOW]

It does alredy exsist. It called Mac-On-Linux [maconlinux.org].

Re:Great idea

[AtATaddict]

Umm.... you could just buy a Mac and VirtualPC, then install Xfree86 in rootless mode. Seems like a simpler means to the stated end, considering that a Mac running Mac OS X is a "unix box".

Re:That's awesome

[Graymalkin]

Most of Cocoa that doesn't deal directly with Darwin/OSX related functions is basically a strait reimplementation of OpenStep. IIRC the Building Cocoa Applications: A Step-byStep Guide by Simson Garfinkle and Mike Mahoney is pretty much code identical to what was in NeXTStep Programming: Step One: Object oriented Applications.

A GNUStep application if binary compatible with Mach/Darwin would run without recompilation or localization.

WRONG

[Anonymous Coward]

Besides the awful spallilng in this post, it is also wrong. The mailing list post referenced in the blurb is from 1/3/2003. Check [google.com] the Google mailing list archive if you want. Who the hell modded this troll up? Check first.

Re:You still need a PowerPC machine

[tres]

If Windows had a native UNIX layer that interfaced with the Windows kernel, then maybe your analogy would actually work. But since there's no real option on a Windows box for using all of the UNIX programs you've come to know and love, it's just not the same.

(Cygwin is a poor pacifier for the real thing. I know, I still have to use it every day. At best, it works like it's supposed to, but much of the time, it's just a waste of time and effort.)

Re:You still need a PowerPC machine

[RAMMS+EIN]

Nice anology, but you're overlooking a couple of things. First off, OS X is widely seen as a great OS, combining the power and stability of Unix with some nice features of NEXTSTEP and the beauty of Aqua. Windows is widely seen as an unstable and insecure OS that everybody feels forced to use because everyone else uses it. Really, these operating systems are apples and oranges. The same goes for the hardware part. OS X only runs on a slim variety of hardware, known to generally be more expensive than x86 hardware of comparable performance. There is little competition in the PowerPC market, and it's not exactly commonplace to build a Mac-compatible from parts. I would go as far as to say that, where buying Apple machines is the easiest way to get PowerPC hardware, and building from parts is the hardest way (except manufacturing parts yourself) to get a machine capable of running WINE, it's usually easier to do the latter. It's not like you need to buy a PC based computer running Windows to use WINE. You can buy the computer without Windows. You can buy it with Linux and WINE installed. You can even build it from parts without too much effort. Try that for a PowerPC box and tell me if it feels different.