Announcement

Collapse
No announcement yet.

Darling Refreshed To Run OS X Binaries To Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    Excellent, let's get hacking.

    Comment


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

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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).

            Comment


            • #7
              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:
              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/
              Last edited by ryao; 01-09-2014, 07:10 PM.

              Comment


              • #8
                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.

                Comment


                • #9
                  Originally posted by zanny View Post
                  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.
                  Last edited by ryao; 01-09-2014, 10:28 PM.

                  Comment


                  • #10
                    Originally posted by zanny View Post
                    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

                    Comment


                    • #11
                      I hope I can play StarCraft 2 with better performance. The Windows version through Wine is slow, even with Nvidia's excellent drivers.
                      Using the Mac version through Darling would probably work better, right?

                      Comment


                      • #12
                        Originally posted by xeekei View Post
                        I hope I can play StarCraft 2 with better performance. The Windows version through Wine is slow, even with Nvidia's excellent drivers.
                        Using the Mac version through Darling would probably work better, right?
                        Why do you think it would work better? Surely that depends entirely on the relative quality of Darling vs Wine, and one of these is a well supported project for which a lot of performance work has been done - and the other is pretty new and struggling for manpower...

                        Comment


                        • #13
                          Originally posted by Delgarde View Post
                          Why do you think it would work better? Surely that depends entirely on the relative quality of Darling vs Wine, and one of these is a well supported project for which a lot of performance work has been done - and the other is pretty new and struggling for manpower...
                          Eliminating the need for DirectX to OpenGL translation should be beneficial from a performance standpoint. Currently, the Windows version of Starcraft II lacks OpenGL support:

                          http://gaming.stackexchange.com/ques...ead-of-directx

                          Having said that, do not expect to be able to run the Mac OS X version of Starcraft II on Linux anytime soon. Darling has a long way to go before it will be able to do something like this.
                          Last edited by ryao; 01-11-2014, 06:13 PM.

                          Comment


                          • #14
                            Originally posted by ryao View Post
                            Eliminating the need for DirectX to OpenGL translation should be beneficial from a performance standpoint. Currently, the Windows version of Starcraft II lacks OpenGL support:
                            True. But even with that translation penalty, I imagine it'd be many years (decades, even) before Darling was mature enough to not only run the Mac game, but to do so with performance even a fraction of that of Wine...

                            Comment


                            • #15
                              Originally posted by Delgarde View Post
                              True. But even with that translation penalty, I imagine it'd be many years (decades, even) before Darling was mature enough to not only run the Mac game, but to do so with performance even a fraction of that of Wine...
                              I did say "do not expect to be able to run the Mac OS X version of Starcraft II on Linux anytime soon. Darling has a long way to go before it will be able to do something like this.".

                              That being said, I will not attempt to speculate on performance of code that has not even been written yet.

                              Comment

                              Working...
                              X