Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 59

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

  1. #41
    Join Date
    Feb 2011
    Posts
    1,116

    Default

    Quote Originally Posted by LubosD View Post
    I got me to the point of thinking whether it wouldn't be better in long term to implement Cocoa on top of something stable like Qt
    Great, now you've summoned the dreaded FunkSTAR.

  2. #42
    Join Date
    Dec 2012
    Posts
    24

    Default

    Quote Originally Posted by TheBlackCat View Post
    Great, now you've summoned the dreaded FunkSTAR.
    Sorry, I don't understand this reference

  3. #43
    Join Date
    Jul 2012
    Location
    SuperUserLand
    Posts
    538

    Default

    "Of course, such an endeavor needs human resources and I don't have these. "


    where there is a will there is a way, code it and they will come...


    go forth my minions and deliver me final cut, running as it were native, if you are sucessful you will get not 10 but 20 shiny euros.

  4. #44
    Join Date
    Apr 2009
    Posts
    66

    Default

    Quote Originally Posted by LubosD View Post
    There's more missing. GNUstep would first need a Quartz backend. And then you'd have to emulate Quartz under X11 somehow. It's easier to just use any of the X11-compatible GNUstep backends, because the official ABI is "Cocoa".

    My biggest worry though is the state of GNUstep. Once I started writing various tests, I started finding bugs immediately in stuff you'd expect to be stable and proven by now. It's quite bad, worse than I thought. Half of the OS X apps I've tested don't start because GNUstep can't even load the NIB (UI definition) file properly. I got me to the point of thinking whether it wouldn't be better in long term to implement Cocoa on top of something stable like Qt: that way we wouldn't have to worry about that many implementation details, slowly work through all the APIs and then replace GNUstep.

    Of course, such an endeavor needs human resources and I don't have these.
    It seems though as if the GNUstep project has done quite a lot of work. Even if it needs fixing up, would it not be less work than reimplementing it from scratch?

    It appears that Cocoa is a very nice API for writing desktop applications with. Completing GNUstep would presumably allow people to develop for Linux using Cocoa as a first-class citizen, in addition to providing binary compatibility for existing OS X applications. That sounds like a good thing to me.

  5. #45
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by pjlahaie View Post
    PearPC would probably be a better place to start since it runs OS X, unlike SheepShaver which was (IIRC) a MacOS System 7-9 emulator.

    http://pearpc.sourceforge.net/
    like i said most people around here don't seem to remember the apple emulation history never mind actually used them in real life

    true pearpc will also add to the existing available tried and trusted code base, its not about an ether or case here but rather taking what's available taking its assembly code ,API's etc, for sure there needs to be lots of C to assembly routines written and extended from what already exists and adding to this latest emulation app (assuming he wants to actually make it good and usable) for the better longer term... or not...

    OC, ether way he now knows of their functional existence and can evaluate them and their core speed of code on modern day hardware and make use of that sheep "
    built-in PowerPC emulator for non-PowerPC systems" as an integrated base with any pear code that helps etc....
    Last edited by popper; 12-10-2012 at 02:47 PM.

  6. #46
    Join Date
    Jun 2011
    Posts
    840

    Default

    Quote Originally Posted by popper View Post
    like i said [COLOR=#000000][I]most people around here don't seem to remember the apple emulation history never mind actually used them in real life
    I've used sheepshaver, pearPC and i (currently) virtualize MacOSX in VMware - big fricking deal... I think your comment really comes across as trying to publicly measure your e-penis more than anything... I know plenty of other users (not necessarily in this forum, but linux users nonetheless) whom are aware and/or have used such applications.

    true pearpc will also add to the existing available tried and trusted code base, its not about an ether or case here but rather taking what's available taking its assembly code ,API's etc, for sure there needs to be lots of C to assembly routines written and extended from what already exists and adding to this latest emulation app (assuming he wants to actually make it good and usable) for the better longer term... or not...
    PearPc is a powerPC emulator... I don't get the impression that this project is the same thing, in fact - it seems to be much more like Wine than anything else.... 2ndly, MacOSX has not supported PPC since Snow Leopard (and had been moving away from PPC since 10.5) and even snow leopard dropped 'rosetta' (for running PPC apps on an intel mac) from being installed by default. (with newer releases ie: 10.7/.8 not supporting PPC at all) ~ So why the hell would an app that is focusing on supporting MacOSX applications (which these days are all x86/64) be based around PPC code bases, when PPC has been dead for some time on the Mac??

    also, running PPC code on x86 is pretty slow. To me, it makes far more sense to shoot for x86 and Arm being as they both matter in the mac/apple world of software.

    Quote Originally Posted by popper View Post
    OC, ether way he now knows of their functional existence and can evaluate them and their core speed of code on modern day hardware and make use of that sheep "built-in PowerPC emulator for non-PowerPC systems" as an integrated base with any pear code that helps etc....
    I would say putting any effort into supporting PPC is pointless, if your plan is to support MacOSX binaries on intel/amd/x86/x86_64 hardware.
    Last edited by ninez; 12-10-2012 at 03:47 PM.

  7. #47
    Join Date
    Feb 2011
    Posts
    1,116

    Default

    Quote Originally Posted by LubosD View Post
    Sorry, I don't understand this reference
    Let's hope you never have a need to. Just don't mention KDE or Qt around here if you can possibly avoid it.

  8. #48
    Join Date
    Sep 2012
    Posts
    343

    Default

    Quote Originally Posted by TheBlackCat View Post
    Let's hope you never have a need to. Just don't mention KDE or Qt around here if you can possibly avoid it.
    Some forum user won't decide about what other users will talk.

  9. #49
    Join Date
    Feb 2011
    Posts
    1,116

    Default

    Quote Originally Posted by JS987 View Post
    Some forum user won't decide about what other users will talk.

  10. #50
    Join Date
    Dec 2012
    Posts
    24

    Default

    Quote Originally Posted by Wingfeather View Post
    It seems though as if the GNUstep project has done quite a lot of work. Even if it needs fixing up, would it not be less work than reimplementing it from scratch?
    You're right. But then you see how slow their backends are, how it still doesn't even support short language names when looking for resources ("en" instead of "English"; "en" is default in original Cocoa), you find bugs even in the About dialog. An then you start doubting their work

Posting Permissions

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