Darling Refreshed To Run OS X Binaries To Linux
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...
Excellent, let's get hacking.
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.
Originally Posted by edoantonioco
I'll answer all of your points:
Originally Posted by BSDude
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.
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).