<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jun 10, 2005, at Fri, Jun 10, 9:26 31 AM, David Steuber wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">To elaborate a bit more on what I said above, it seems to me that only the kernel needs to have the kludge.<SPAN class="Apple-converted-space"> </SPAN>I don't know how long PPC support will be needed, but I'm guessing the time frame is in years.<SPAN class="Apple-converted-space"> </SPAN>Perhaps enough years to justify going with the Universal Binaries approach just for the kernel.<SPAN class="Apple-converted-space"> </SPAN>The kernel will know which image files it needs to load based on the host and can then just run native.<SPAN class="Apple-converted-space"> </SPAN>Sure, that is more image files to produce for an app bundle, but having two in Contents:MacOS is probably already one more than is typical.<SPAN class="Apple-converted-space"> </SPAN>Multiple architecture support only matters for distribution of apps and other binaries.<SPAN class="Apple-converted-space"> </SPAN>Development doesn't need that capability.<SPAN class="Apple-converted-space"> </SPAN>At least not app development.<SPAN class="Apple-converted-space"> </SPAN>Compiler development is another story.<SPAN class="Apple-converted-space"> </SPAN>I have no ideas there at the moment.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A few thoughts. There's no inherent reason that the image of an openmcl app has to live in /Contents/MacOS - the image(s) could just as well be in Resources. This would leave just a universal binary kernel which would know which image to load. As for development, I think that Gary's idea of focusing on X86-64 is realistic give how long it would likely take to complete an intel back-end. It is also quite reasonable that Gary should want to wait for confirmation from Apple that they are in fact moving to X86-64 in the near future (i.e., not just IA32 which is all that's been mentioned so far).</DIV><BR><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Lucida Grande; min-height: 15.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">While watching the keynote, I couldn't help noticing the obscene bias for Xcode.<SPAN class="Apple-converted-space"> </SPAN>Telling Metroworks users they have to switch to Xcode!<SPAN class="Apple-converted-space"> </SPAN>Really!<SPAN class="Apple-converted-space"> </SPAN>Jobs clearly isn't even considering vendors of other language implementations.</FONT></P> </BLOCKQUOTE><BR></DIV><DIV>Some of us have noted in other fora that Apple have been pushing Cocoa and Xcode for quite some time. Some of us have considered that Apple was not so subtly hinting that taking the Carbon or Carbon/CodeWarrior path was one day going to lead to a world of pain. Some have speculated that this might explain why all of Apple's own applications were done in Cocoa with the sole exceptions of legacy apps from Mac OS Classic such as Finder and iTunes. Some have even speculated that Apple has been pushing Cocoa/Xcode because this pairing has been capable of cross compiling for years and that Steve "Marklar" Jobs has been "keeping our options open." </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In effect there's no way that Jobs could have been more helpful to other language implementors without revealing outright that a cpu architecture switch was in the pipeline. Naturally Apple wanted to limit the Osborne effect of this announcement, so the best they could do until now was to strongly suggest that developers move to XCode, and move from Carbon to Cocoa. Apple have also helped out other language implementors by making available a public API to the Objective-C runtime which has been used to bridge a number of languages to Cocoa. One recent story has the maintainers of PyObjC porting their bridge to intel in just a couple of hours. So if you followed Apple's advice, you're in good shape.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The issue for openmcl of course is that unlike Python it is not an interpreter which can just be written in portable C. It is a native code compiler. These are inherently less portable (though still portable of course if you compile to some intermediate representation and then do different architecture back ends). So, as Gary said, it would be good to know what the ultimate target architecture is before starting this fairly time consuming process. If any lurkers on this list have any knowledge about this ultimate direction it would be nice if such persons could share this information with Gary at the earliest possible date.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>regards,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Ralph</DIV><BR><DIV> <DIV>Raffael Cavallaro, Ph.D.</DIV> <DIV><A href="mailto:raffaelcavallaro@mac.com">raffaelcavallaro@mac.com</A></DIV> </DIV><BR></BODY></HTML>