Originally posted by JS987
View Post
Announcement
Collapse
No announcement yet.
A New Project To Run Mac OS X Binaries On Linux
Collapse
X
-
Originally posted by LubosD View PostSorry, I don't understand this reference
Leave a comment:
-
Originally posted by popper View Postlike 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
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...
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.
Originally posted by popper View PostOC, 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 ninez; 10 December 2012, 04:47 PM.
Leave a comment:
-
Originally posted by pjlahaie View Post
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; 10 December 2012, 03:47 PM.
Leave a comment:
-
Originally posted by LubosD View PostThere'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 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.
Leave a comment:
-
"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.
Leave a comment:
-
Originally posted by LubosD View PostI 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
Leave a comment:
-
Originally posted by pjlahaie View PostThere is currently another related project "Project Magenta" which aims to re-implement a binary compatible kernel / userland for iOS applications.
They have already implemented the Mach ports as a kernel modification.
Originally posted by pjlahaie View PostIn theory, there is no reason why you couldn't implement Darwin binary compatibility using the same method that Solaris / Sys V compatibility was achieved with Linux.- The additional amount work.
- The syscall interface is not the official ABI. There is no point in keeping it. They may choose to randomly renumber their syscall numbers without breaking anything. Because libc is the ABI for the syscalls. Linux emulation in FreeBSD is a completely different matter, these systems are much more alike.
- Mach syscalls are crap and we're better off emulating them in userspace where feasible. I'm getting remarkably better performance when emulating some of them in userspace, because those calls just don't belong into the kernel (thread synchronization primitives).
- Ease of installation. No need to patch the kernel, check for the right kernel version or anything.
- Ease of development. Without any doubt. Even the fact that I need to use plain C for kernel development is very limiting.
- Ease of getting the product released. Going through reviews of the kernel code may be useful, but it also means I can't easily distribute any experimental hackish code to the users.
When mentioning NetBSD's Darwin emulation, note that their code was highly experimental. A better part of IOKit was just dummy code and while browsing some of their Mach Ports code I got the feeling that they misunderstood certain aspects of this feature. And I'm not surprised. I have the feeling that no-one except for Apple's and GNU Hurd's developers knows how to use these :-D
Originally posted by pjlahaie View PostPerhaps creating a mailing list / forum for this project would be helpful seeing as there is bound to be interest from others on developing this further.
Originally posted by pjlahaie View PostI've always wondered why no OS X app compatibility was done for Linux, seeing as the base API (OpenStep) is both public and implemented as OSS (GNUstep), all the loader bits are available via Darwin. All that is missing is re-implementing Apple's proprietary services (Quartz / DisplayServer)
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.
Leave a comment:
Leave a comment: