Announcement

Collapse
No announcement yet.

A New Project To Run Mac OS X Binaries On Linux

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

  • A New Project To Run Mac OS X Binaries On Linux

    Phoronix: A New Project To Run Mac OS X Binaries On Linux

    While there is the Wine project to run native Windows binaries on Linux (and other platforms), there's a new open-source project that's emerging for running Apple OS X binaries on Linux in a seamless manner...

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

  • #2
    It seems like a promising start. I suspect there aren't quite so many architectural adaptations to make for OS X apps as there would be for Win32, but that's just a naive assumption of mine based on what I know of Cocoa and Objective C.

    Aside from Adobe CS, Final Cut, and some older game ports like The Sims 2, I'm not sure exactly what substantial gains a full OS X compatibility layer would grant us. Still, it's interesting and it may turn out to be valuable some day, if web technologies don't obsolete everything by then (we've probably got at least a decade).

    Comment


    • #3
      Are they focusing on useful applications? On their homepage the statuses are applications that are pretty much useless and have better alternatives.
      Also I've been tempted to run some Windows applications I was missing, but it never happened with Mac OS applications.

      Originally posted by scionicspectre View Post
      Aside from Adobe CS
      Isn't the Windows version better anyway?

      Comment


      • #4
        POSIX compatibility may make this easier. Also think of it from a marketing standpoint: "Linux! It'll run anything!" lol

        Comment


        • #5
          Intersted! I was writing MachO loader and MachO inspect, but realy stoped in library layer.

          Comment


          • #6
            Originally posted by scionicspectre View Post
            Aside from Adobe CS, Final Cut, and some older game ports like The Sims 2, I'm not sure exactly what substantial gains a full OS X compatibility layer would grant us. Still, it's interesting and it may turn out to be valuable some day, if web technologies don't obsolete everything by then (we've probably got at least a decade).
            There are some apps which are only available on OS X, and which have no exact equivalent in Linux.

            Two that I use myself are DEVONthink Pro and OmniOutliner. There are Linux apps that do some of the things these apps do, but as I said, no exact equivalents -- and the differences are significant enough to make me want to run the OS X app instead.

            However, it seems to me that this project is taking the wrong approach. It would be better (and easier, I think) to identify useful OS X apps where there are no exact Linux equivalents, such as the ones I mention, and then get to work creating those equivalents.

            Comment


            • #7
              Hi, first of all I'd like to say I'm happy I made it to Phoronix :-)

              Originally posted by pankkake View Post
              Are they focusing on useful applications? On their homepage the statuses are applications that are pretty much useless and have better alternatives.
              I started the project in August this year. When working on something of this size, you have to start small. There's just no other way.

              The next big thing (which is quite close by the way) is to have Apple LLVM-GCC fully working. That would basically mean you could compile applications for iOS on other platform than OS X. This is currently not possible. Anybody who wants to do iOS development has to buy a Mac. That sucks big time. iOS is not very popular in this part of Europe, but at least in the US I believe it's still the platform no. 1 for mobile apps.

              Getting iOS apps running on... say Android is a different story. I'm planning on supporting ARM (and good old PPC too, while I'm at it) in the dynamic loader and the ObjC runtime. The frameworks itself is I think a job for someone else, because as I've said, I don't see that many iOS devices around so I lack the motivation.

              Just for OS X apps, there is lots and lots and lots of work to do. Anyone who's ever written a piece of software for OS X could start mentioning loads of frameworks specific to this platform. While I'm enjoying the work, I also realize that I don't stand much chance to have anything suitable for end users in a short time frame. So if there are any guys out there willing to help out, be it with GNUstep or something that I actually write as part of Darling (IOKit userspace libs, Apple Events support, etc....), help is always welcome. You don't even need to have any experience with writing software for OS X...

              Luboš

              Comment


              • #8
                I'm not sure this approach is the right way.

                Hopefully this work won't lead to apps doing less or even non-existing development for Linux because Linux can run Mac OS X applications anyway.

                Comment


                • #9
                  Originally posted by CorkyAgain View Post
                  Two that I use myself are DEVONthink Pro and OmniOutliner. There are Linux apps that do some of the things these apps do, but as I said, no exact equivalents -- and the differences are significant enough to make me want to run the OS X app instead.

                  However, it seems to me that this project is taking the wrong approach. It would be better (and easier, I think) to identify useful OS X apps where there are no exact Linux equivalents, such as the ones I mention, and then get to work creating those equivalents.
                  Hey, that's exactly how open source apps usually start. Scratch your itch and go write that perfect app for doing foo.

                  Can't code? There's your motivation to learn, to get that perfect app

                  Comment


                  • #10
                    WINE is a failure. After like 20 years of development, millions in donations, and an army of developers, the best it can do is (maybe) run your Windows applications(with some extra bugs and worse performance).

                    A couple of years ago I evaluated running half a dozen enterprise Windows applications in WINE. WINE failed to run any of them adequately, most couldn't even start, and it was always because of some unimplemented function in a DLL somewhere... Maybe after 40 years of development WINE will adequately run 90% of applications written for Windows 2000.

                    If that doesn't tell you that "Not An Emulators" are a waste of time, I don't know what will.

                    Comment


                    • #11
                      Originally posted by LubosD View Post
                      Hi, first of all I'd like to say I'm happy I made it to Phoronix :-)


                      I started the project in August this year. When working on something of this size, you have to start small. There's just no other way.

                      The next big thing (which is quite close by the way) is to have Apple LLVM-GCC fully working. That would basically mean you could compile applications for iOS on other platform than OS X. This is currently not possible. Anybody who wants to do iOS development has to buy a Mac. That sucks big time. iOS is not very popular in this part of Europe, but at least in the US I believe it's still the platform no. 1 for mobile apps.

                      Getting iOS apps running on... say Android is a different story. I'm planning on supporting ARM (and good old PPC too, while I'm at it) in the dynamic loader and the ObjC runtime. The frameworks itself is I think a job for someone else, because as I've said, I don't see that many iOS devices around so I lack the motivation.

                      Just for OS X apps, there is lots and lots and lots of work to do. Anyone who's ever written a piece of software for OS X could start mentioning loads of frameworks specific to this platform. While I'm enjoying the work, I also realize that I don't stand much chance to have anything suitable for end users in a short time frame. So if there are any guys out there willing to help out, be it with GNUstep or something that I actually write as part of Darling (IOKit userspace libs, Apple Events support, etc....), help is always welcome. You don't even need to have any experience with writing software for OS X...

                      Luboš
                      I have a few comments that you might or might not appreciate:
                      1. You should pay strong attention to getting the syscall layer correct. If you implement the syscall layer well, it should be possible to use Mac OS X's userland on top of the lower level layers. That would enable you and others to compare the Mac OS X userland against the OSS userland components. That should make this significantly easier. It would also enable you to try a userland from Apple's Darwin images.
                      2. You can use Gentoo Prefix to assist you in development. It is a userland package manager that lets you build a fairly large body of existing UNIX software for Mac OS X. What should be particularly interesting to you is that its dependencies are fairly light. Installing it should require only standard UNIX utilities, a toolchain, libc and the system headers. Once it is installed, it depends on only libc and the system headers. There might be a few other libraries that I missed, although they would be things like libm and libdl.
                      3. If you are interested in seeing widespread adoption, it might be better to pick a less restrictive license. The WINE project uses the LGPL, which would probably work well for you. It is important to make a decision on this before you start receiving contributions, because it will be a pain to switch should you change your mind afterward. This is especially true with the GPLv3 because people tend to be very litigation-happy when things involve it.
                      4. This is an awesome idea. Ignore people that say that this is a waste of time. Their opinions are not worth your attention.

                      Originally posted by rudolph_steinberg View Post
                      WINE is a failure. After like 20 years of development, millions in donations, and an army of developers, the best it can do is (maybe) run your Windows applications(with some extra bugs and worse performance).

                      A couple of years ago I evaluated running half a dozen enterprise Windows applications in WINE. WINE failed to run any of them adequately, most couldn't even start, and it was always because of some unimplemented function in a DLL somewhere... Maybe after 40 years of development WINE will adequately run 90% of applications written for Windows 2000.

                      If that doesn't tell you that "Not An Emulators" are a waste of time, I don't know what will.
                      It would be interesting to run WINE on top of Darling. Anyway, there are two approaches to running foreign binaries on a system. One is to implement the syscall layer and rely on the foreign operating system's userland to enable it to work (the OS/2 approach). The other is to try to implement both the kernel and userland (the WINE approach). The former was very successful in its time and does not require many resources. The latter is a nightmare.

                      I doubt that Darling would result in making Linux into a perfect replacement for Mac OS X, but I think Darling would make Mac OS X development on Linux easier. If Darling can obtain near perfect operation when paired with Mac OS X's actual userland, that would be a nice bonus.
                      Last edited by ryao; 12-08-2012, 07:16 PM.

                      Comment


                      • #12
                        Originally posted by ryao View Post
                        It would be interesting to run WINE on top of Darling. Anyway, there are two approaches to running foreign binaries on a system. One is to implement the syscall layer and rely on the foreign operating system's userland to enable it to work (the OS/2 approach). The other is to try to implement both the kernel and userland (the WINE approach). The former was very successful in its time and does not require many resources. The latter is a nightmare.

                        I doubt that Darling would result in making Linux into a perfect replacement for Mac OS X, but I think Darling would make Mac OS X development on Linux easier. If Darling can obtain near perfect operation when paired with Mac OS X's actual userland, that would be a nice bonus.
                        A reasonable sentiment, but when you take into account that most OSX applications these days are crappy ports of Windows applications that have half of the performance and numerous additional bugs compared to their Windows counterpart, then it really start looking bleak. For example, look at any of the Windows/OSX audio applications, everything from workstations to plugins; they all perform so badly compared to Windows that you actually need that dual socket Xeon configuration just to break even with mainstream quad cores in Windows, presumably due to crappy BSDisms that Mac inherited, as well as general developer apathy to that 5% of their customer base. Had they based OSX on Linux, which is actually scalable and performant, it might have been a different story.

                        Comment


                        • #13
                          Great project, congratulations on the progress you've made.

                          To prevent some duplication, here's another project with similar goals (apologies if you've already aware of it):

                          https://github.com/shinh/maloader
                          http://shinh.skr.jp/slide/ldmac/000.html

                          Originally posted by LubosD View Post
                          I started the project in August this year. When working on something of this size, you have to start small. There's just no other way.

                          The next big thing (which is quite close by the way) is to have Apple LLVM-GCC fully working. That would basically mean you could compile applications for iOS on other platform than OS X. This is currently not possible. Anybody who wants to do iOS development has to buy a Mac. That sucks big time. iOS is not very popular in this part of Europe, but at least in the US I believe it's still the platform no. 1 for mobile apps.
                          I agree that not having cross compilers (for any platform) sucks, but it's not strictly true that there are none for iOS/OSX; there's been a few projects dedicated to making cross compilers for Darwin (xchain, toolchain4, puredarwin and opendarwin). I've adopted, modernised and improved them, forking from javacom's toolchain4:

                          Binaries:
                          http://mingw-and-ndk.googlecode.com/...-120724.tar.xz
                          http://mingw-and-ndk.googlecode.com/...dows-120614.7z

                          Source:
                          https://github.com/mingwandroid/toolchain4

                          Using these you can build both iOS and OSX software using either gcc or llvmgcc on either Linux or Windows. You need to bring your own SDK of course. I've not yet looked into the feasibility of building Darwin libc or any of the other system libs (nor the legality of distributing these). I think there's definitely a gap for the OSX/iOS equivalent of MinGW-w64.

                          My build scripts and patches are a bit untidy, I'm currently engaged in an effort to merge this work into crosstool-ng which will force me to clean things up.

                          Another project that's fairly closely related is Cocotron, an effort to make open versions of Cocoa for Windows:

                          http://www.cocotron.org/

                          I've a feeling that with all these bits lying around, something really cool could be cobbled together.

                          Ray.

                          Comment


                          • #14
                            Originally posted by ryao View Post
                            It would be interesting to run WINE on top of Darling. Anyway, there are two approaches to running foreign binaries on a system. One is to implement the syscall layer and rely on the foreign operating system's userland to enable it to work (the OS/2 approach). The other is to try to implement both the kernel and userland (the WINE approach). The former was very successful in its time and does not require many resources. The latter is a nightmare.
                            This is something I think about every now and then. So far, I'm using the Wine approach.

                            There is a problem with the OS/2 approach: unlike what you believe, it requires a *huge* investment of time in developing all the layers, which leads to basically recreating the original system. And that doesn't integrate very well with a Linux (desktop) environment. There will always have to be a line where you stop immitating and start integrating with "standard Linux layers".

                            Also given how much Apple's APIs rely on Mach kernel stuff, this is certainly not something I'd like to be putting into the Linux kernel. Not to mention how crappy Mach is. In certain synthetic tests, programs for OS X run faster under Darling than on the original system and Mach is to blame for that. We're talking orders of magnitude faster. But before anyone starts saying "Darling is faster than the original system", everything that comes from GNUstep seems to be way slower actually.

                            With the Wine approach, the similarities between the OS X and Linux userspace are in my favor. In my loader, OS X binaries are being dynamically linked against native ELF libraries where applicable.

                            Also, note that I am not doing this for any specific OS X applications. I think GNU/Linux is a very good platform when it comes to application availability and quality. By the way, I use Wine only like couple of times a year for stuff I could absolutely do without.

                            I'm doing this to give people a choice and to make Linux an even more "universal" operating system. I also do this because it's *not* something that exists in ten different variants and has been done by hunderds of people before.

                            As for LGPL/BSD: I do not use the BSD or similar license for a purpose. You wan't to make money off this? You either give me a cut or share your code with others. I find it fair.

                            Comment


                            • #15
                              Originally posted by LubosD View Post
                              This is something I think about every now and then. So far, I'm using the Wine approach.

                              There is a problem with the OS/2 approach: unlike what you believe, it requires a *huge* investment of time in developing all the layers, which leads to basically recreating the original system. And that doesn't integrate very well with a Linux (desktop) environment. There will always have to be a line where you stop immitating and start integrating with "standard Linux layers".

                              Also given how much Apple's APIs rely on Mach kernel stuff, this is certainly not something I'd like to be putting into the Linux kernel. Not to mention how crappy Mach is. In certain synthetic tests, programs for OS X run faster under Darling than on the original system and Mach is to blame for that. We're talking orders of magnitude faster. But before anyone starts saying "Darling is faster than the original system", everything that comes from GNUstep seems to be way slower actually.

                              With the Wine approach, the similarities between the OS X and Linux userspace are in my favor. In my loader, OS X binaries are being dynamically linked against native ELF libraries where applicable.

                              Also, note that I am not doing this for any specific OS X applications. I think GNU/Linux is a very good platform when it comes to application availability and quality. By the way, I use Wine only like couple of times a year for stuff I could absolutely do without.

                              I'm doing this to give people a choice and to make Linux an even more "universal" operating system. I also do this because it's *not* something that exists in ten different variants and has been done by hunderds of people before.

                              As for LGPL/BSD: I do not use the BSD or similar license for a purpose. You wan't to make money off this? You either give me a cut or share your code with others. I find it fair.
                              You might want to read the following paper:

                              http://research.microsoft.com/apps/p...aspx?id=141071

                              Anyway, have fun with your effort. It will be nice if it results in something.

                              Comment

                              Working...
                              X