I'm very aware, that it is not easy to do. But the basics I was talking about is Quartz and the low-layer stuff.
That's exactly what you'd want to get running, Cocoa/Carbon shouldn't have too many platform specifics in it (though it probably still has a surprising amount of those...).
As for the reason, it is a market. A big one. And already having a large portion of the code working (per YB) really helps. There had to be people around who knew how to do this kind of stuff, and after all simply throwing it away seems pretty wasteful.
Furthermore, why do you suppose had Apple went through the trouble of keeping a separate x86 build of OS X around since day one?
That also doesn't really make sense, unless you want to keep all roads open. The very same idea applies to the theory of a Cocoa implementation for Windows.
I am not saying that it is easy to do, nor that it is fully functional (and I wouldn't know for sure, anyway). But I seriously doubt that there isn't any code that makes it at least doable.
And yes, the supporting runtime would be huge. There'd be a whole lot of code which Apple would have to supply, from tiny things as the Objective-C runtime to some sort of DisplayPDF windowserver layer. There would of course also be stuff that simply wouldn't work, as IOKit and kexts.
But that is not the point. It wouldn't be about porting OS X to Windows, which wouldn't make sense, but rather supply the upper-level frameworks.
The stuff that interests the application developers.
Whatever, speculation. Given the cool new hardware roadmap, and the ability to run Windows if someone ever needed/wanted to, may make the mere thought obsolete. I wouldn't be disappointed ;)
by Kay — May 24
That's exactly what you'd want to get running, Cocoa/Carbon shouldn't have too many platform specifics in it (though it probably still has a surprising amount of those...).
As for the reason, it is a market. A big one. And already having a large portion of the code working (per YB) really helps. There had to be people around who knew how to do this kind of stuff, and after all simply throwing it away seems pretty wasteful.
Furthermore, why do you suppose had Apple went through the trouble of keeping a separate x86 build of OS X around since day one?
That also doesn't really make sense, unless you want to keep all roads open. The very same idea applies to the theory of a Cocoa implementation for Windows.
I am not saying that it is easy to do, nor that it is fully functional (and I wouldn't know for sure, anyway). But I seriously doubt that there isn't any code that makes it at least doable.
And yes, the supporting runtime would be huge. There'd be a whole lot of code which Apple would have to supply, from tiny things as the Objective-C runtime to some sort of DisplayPDF windowserver layer. There would of course also be stuff that simply wouldn't work, as IOKit and kexts.
But that is not the point. It wouldn't be about porting OS X to Windows, which wouldn't make sense, but rather supply the upper-level frameworks.
The stuff that interests the application developers.
Whatever, speculation. Given the cool new hardware roadmap, and the ability to run Windows if someone ever needed/wanted to, may make the mere thought obsolete. I wouldn't be disappointed ;)