Slashdot Mirror
NetBSD's COMPAT_DARWIN Adds XDarwin Support
Dan writes "NetBSD's Emmanual Dreyfus says that COMPAT_DARWIN is now able to run Mac OS X's XDarwin (this is, the X Window server for Darwin). The server is fully functional: display, keyboard and mouse work. He says that running Darwin has no interest in itself, but having it working ensures that NetBSD's IOKit (1) emulation is good enough to be used. Darwin is Apple's Mac OS X core. A fully functional Darwin binary compatibility on NetBSD/powerpc & NetBSD/i386 will imply getting MacOS X libraries to run any Mac OS X program, just like NetBSD is now able to run binaries from Linux, FreeBSD, Solaris, and many other OSes."
That would require emulating the Apple's APIs for everything in the OS.
Given that most of it is proprietary, this is very unlikely to happen, though not impossible (just look at Wine)...
AC comments get piped to
They're trying to get the OSX environment running on NetBSD instead of Darwin. I'm failing to see the point of this other than a different package manager...anyone else see a benefit to this? Drivers? Cheaper hardware? All looks the same to me...
Karma: Chameleon (mostly due to the fact that you come and go).
The goal is to run MacOS X's programs on NetBSD/powerpc. One of the problems is that thoses programs do not use X11, they use quartz.
We have no free software display server for Quartz. Emmanuel Dreyfus had three options to get the job done:
1) Write a Quartz display server
2) Write a Quartz to X11 bridge
3) Emulate enough of MacOS X to get MacOS X's Quartz display server to run on NetBSD.
He chose option 3. It is not an easy job since MacOS X I/O are done through the IOKit, which completely differs from UNIX I/O API.
XDarwin is the X11 server for MacOS X. It uses the IOKit to access the display, keyboard and mouse. Having XDarwin fully fonctionnal on NetBSD means that NetBSD IOKit emulation is in good shape. It is the first step on the right direction.
Next step is to run MacOS X's Quartz display server itself.
Actually, you can take all that wonderful BSD licensed code, strap the GPL on it, and redistribute.
The FSF calls the BSD license "GPL compatible" in that regard.
The unofficial
Darwin is more than just the kernel, it's also the non-graphical userland. Darwin's kernel is actually called "xnu". And Darwin is licensed under the Apple Public Source License, version 2, which is actually GPL-compatible. They even worked together with the FSF to ensure this.
A monkey is doing the real work for me.
DarwinPorts will allow you to install ports from source, and appearently yum offers the ability to install binaries. The point being that Darwin is supposed to be a fully functional unix, not just the little bastard child that's kept in the cellar. Mostly useful I think when (as you pointed out) you want to keep multiple systems with identical configurations, or things that relate to administering or serving to os x machines, when you don't need the gui.
-- http://vectorvector.tumblr.com/
The fact that all Mac binaries are PPC is going to mean at best on i386 platforms you're going to have to use emulation, a better approach is to emulate the Cocoa API allowing a recompile for i386/whatever.
The Cocoa API is basically the NextStep API with Quartz replacing Display Postscript for the display composition/rendering and a number of additional classes and extensions since. (Display Postscript was licenced, Quartz is based on the free PDF specification).
The original NextStep API exists on non-PPC platforms in two forms;
The first is Apple's own implementation which was called 'Yellow Box' back in the NextStep days and let you recompile your apps for Windows. Alas there were licencing issues that Apple claim meant the runtime was expensive to deploy.
Apple still use this runtime in WebObjects for Windows - I don't know if it's been extended to keep up with the OSX enhancements.
The second option is an interesting project called GNUStep who are working towards a complete implementation of the NextStep API and have stated they will add Cocoa's extensions where they provide value. With it being open source you could always add any missing classes/functionality yourself.
This project is usable on FreeBSD and Linux and the core and gui classes are nearly complete however the developer tools themselves are not. This i not a problem however if you are developing on OSX and using them for a port.
[)amien
One of the major APIs for OS X already exists in an open-source form called are.
Of course, this is not emulation, rather source compatibility.
Throw in a GNUstep Makefile and new interface files, and you can have apps that compile from the same source on any free *NIX with GNUstep and on OS X with Cocoa.