<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, 12:53 45 PM, Chris Curtis 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">If you mean that Carbon itself is inherently more difficult, then (a) I don't see any significant reason why that would be true, and (b) as you pointed out, a lot of Cocoa is wrappers around Carbon functionality which would need to be ported anyway. All of which is moot, since everything has been running internally on both platforms from the outset.</FONT></P> </BLOCKQUOTE><BR></DIV><DIV>I think many people fail to see that these things cannot all be true:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1. Carbon does not receive more limited Apple support/maintenance than Cocoa.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>2. Both Cocoa and Carbon have been running as intel builds for 5 years.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>3. Carbon apps will take longer to port.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Apple have stated publicly that 2 and 3 are true and I have no reason to doubt them. Therefore the only reason #3 is true - that Carbon apps will take longer to port - is that Apple have done less to make sure that Carbon apps will work with a simple recompile.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Now some might say that this due to the nature of the Carbon framework - that is, that it is lower level than Cocoa and therefore does not for example inherently take care of the endian issues that Cocoa does. Quite possibly so. But why hasn't Apple been maintaining a secret set of Carbon APIs that just do the right thing so that all that is needed is a recompile? My answer is that this would have entailed a good deal more work for Apple, and again, Apple does not have infinite manpower resources.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Five years ago when this began, I think Apple decided that Cocoa was going to be the "just click a checkbox and recompile for ix86" framework and that Carbon was going to be the transitional framework. The fact that many developers clung to Carbon like grim death came as a surprise and disappointment for Apple. But it didn't cause them to start a parallel project that would allow Carbon apps to just work. Thus, Carbon apps require more effort to port. The fact that Carbon apps require more effort to port means ipso facto that Carbon is less supported than Cocoa.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Now Apple DTS will swear up and down that this is not the case because they don't want to alienate Carbon developers, especially big Carbon developers like Adobe. But the very fact that moving a Carbon app to intel will take more effort means that Apple have put more work into making sure that Cocoa apps "just work" with a simple recompile. This greater effort on the part of Apple is the very definition of "more fully supported."</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>