Results 1 to 10 of 16

Thread: Darling Refreshed To Run OS X Binaries To Linux

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,388

    Default 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...

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

  2. #2
    Join Date
    Mar 2011
    Posts
    223

    Default

    Excellent, let's get hacking.

  3. #3
    Join Date
    Apr 2013
    Posts
    145

    Default

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

  4. #4
    Join Date
    Oct 2013
    Posts
    276

    Default

    Quote Originally Posted by edoantonioco View Post
    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.

  5. #5
    Join Date
    Dec 2012
    Posts
    26

    Default

    Quote Originally Posted by BSDude View Post
    '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.

  6. #6
    Join Date
    Dec 2012
    Posts
    26

    Default

    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).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •