Darling Refreshed To Run OS X Binaries To Linux

[phoronix]

Phoronix: Darling Refreshed To Run OS X Binaries To Linux

A few weeks ago I wrote about the Darling Project having fallen into dormancy, the ambitious Wine-like project to let Mac OS X binaries run on Linux. Well, now the project has been refreshed and is taking on new work...

http://www.phoronix.com/vr.php?view=MTU2NDU

[M1kkko]

Excellent, let's get hacking.

[edoantonioco]

I guess it should be a lot easier to make than wine, after all, both are unix like systems.

[BSDude]

I guess it should be a lot easier to make than wine, after all, both are unix like systems.

'a lot' is an exaggeration. Besides the microkernel it has a different I/O stack and display server. I wonder if the devs can reuse any of the code written by the wine fellows?! If not, it's going to take some time to write all the code and a heck of a lot more to polish and iron it out.

[LubosD]

'a lot' is an exaggeration. Besides the microkernel it has a different I/O stack and display server. I wonder if the devs can reuse any of the code written by the wine fellows?! If not, it's going to take some time to write all the code and a heck of a lot more to polish and iron it out.

I'll answer all of your points:

ad microkernel: OS X's kernel (XNU) is based on Mach, but I wouldn't call it a microkernel. Apps don't usually even touch the Mach API.
ad different I/O stack: Well, as far as userland is concerned, IOKit is different indeed, but not all that complicated to implement to the extent required.
ad display server: doesn't really matter. Display server is a low-level detail Darling doesn't need to care about.
ad reusing wine code: no, none.

[LubosD]

One of the new endeavors I have decided to start is darling-appkit as a QtQuick-based replacement for gnustep-gui. Before you call me crazy, there are a few things to consider:

1) Darling is totally screwed without GUI support (AppKit). It's been a year and I haven't had luck fixing gnustep-gui's code that hasn't been actually tested with real OS X apps all that much. gnustep devs are too busy fixing and improving areas that concern their own work, let alone help me with hours of debugging, chasing a dangling pointer in the middle of a stacktrace that goes 35 levels deep.
2) gnustep-gui's layering doesn't match that of OS X. Some work has been done in this regard, but GNUstep lacks the manpower to integrate it all and actually make it work with high reliability and performance.
3) I will keep using other parts of GNUstep. They work just great and I feel confident in contributing to them.
4) I will not need to bother with supporting obsolete GCC (from ObjC standpoint) and Windows or avoid C++. I can actually use technologies I'm very efficient in using and I can base my work on something well-proven and high-level as Qt (Qt Quick). Designing UI components in QML will help me move forward very fast with all the eye candy and effects otherwise hard to implement manually.
5) I can start afresh and do it right. I.e. start from the bottom-most layers (CA and CG) and go up. GNUstep is doing the other way around (because the code was written before this layering was introduced, I assume).

[ryao]

LubosD, Michael Larabel wrote "Luboš Doležel recommends picking a framework or set of APIs to focus on implementing". I would like to expand on this suggestion. I suggest that potential contributors pick APIs either from their favorite Mac OS X applications or any of a few very useful open source applications exclusive to Mac OS X. In specific, here is a list in descending order of how useful I think each is:

• OpenEmu
• iTerm 2
• Textmate
• Colloquy

Another possibility is to look into implementing the APIs required by the build systems themselves. Source code for many of Apple's build system tools is available from their open source website:

http://www.opensource.apple.com/

[zanny]

Reimplementing Cocoa would be hell, though. Though I guess if you could get those libraries running on top of the display server you don't need to reimplement the whole shebang.

[ryao]

Reimplementing Cocoa would be hell, though. Though I guess if you could get those libraries running on top of the display server you don't need to reimplement the whole shebang.

Implementing the interface between the Cocoa library/libraries and the Mac OS X display server in Darling should yield working GUI applications (provided the other required interfaces are also implemented). However, the library/libraries needed to make it work would not be redistributeable. I suppose it would make sense to implement things this way in the interest of implementing the lowest level interfaces first. Once the GUI applications are running, a replacement for the Cocoa library itself could be written to fill-in the gap. That likely would produce the same internal layering and also make it easier to adapt to changes made by Apple. That being said, this would be a huge undertaking. It would be cool if enough people get together to carry it out.

[ssam]

Reimplementing Cocoa would be hell, though. Though I guess if you could get those libraries running on top of the display server you don't need to reimplement the whole shebang.

"GNUstep is a free software implementation of Cocoa"
https://en.wikipedia.org/wiki/GNUstep