<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jun 12, 2005, at Sun, Jun 12, 4:37 05 AM, Lawrence E. Bakst 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">At 5:06 PM -0400 6/10/05, Raffael Cavallaro wrote:</FONT></P> <BR><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">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?</FONT></P> <BR></BLOCKQUOTE><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">Sorry there are no "secret APIs" in Cocoa or really anyplace else,<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There were whole secret OS builds for 5 years. That's a bit more clandestine than a couple of undocumented APIs.</DIV><BR><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"> nor are any needed for Cocoa or Carbon.<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I think you might have missed my point here. I said that if Apple were intent on having Carbon transition to x86 as easily as Cocoa they could have maintained a set of APIs (in secret of course, just as the x86 OS builds were secret) that took care of more byte swapping issues for Carbon developers. But Apple did not. I take this as a sign that helping Carbon developers transition was a lower priority than making Cocoa just work.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><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">In some cases Cocoa even calls Carbon. The reverse is not true.<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Which is why I said that I believe that Cocoa will eventually swallow Carbon.</DIV><BR><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"> So the boundaries between Carbon, Cocoa, and the Frameworks aren't quite as clear as you might think<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I clearly don't think there are clear boundaries. I know that Cocoa is a much higher level, framework that calls the lower level Core and Carbon routines quite often. That's why I said that I believe that Cocoa will eventually swallow Carbon.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">Once again, Carbon has always been advertised as a *transitional* technology. The keynote made clear that porting a Carbon app to ix86 is going to be significantly more difficult than porting a Cocoa app especially if that Carbon app is being maintained under CodeWarrior as so many legacy Carbon apps are.</FONT></P> <BR></BLOCKQUOTE><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">You should listen to the keynote again. The word "transitional" was not used.<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The word "transitional" was used when the concepts of Carbon and Cocoa were first trotted out. Carbon was the transitional or porting framework, Cocoa was for new apps or complete rewrites. We now know that the move to intel began way back then, with whole parallel x86 builds going on in secret. This project didn't happen overnight. It was planned over 5 years ago. At that time Apple were very clear that Carbon was a transitional technology. They never expected to have to support numerous developers porting legacy Carbon apps over to intel. It shows.</DIV><BR><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"> The phrase "significantly more difficult" was not used. What you say was "made clear" I didn't hear. What was said is that porting a Carbon application to X86 would take "more tweaking" than Cocoa and "we may be overstating it here" (the effort involved to Port Carbon apps). Again the exact words that Steve said were, "Carbon with Xcode, more tweaks and a recompile and they're going to work" and "... a few weeks, a few more tweaks".</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>When Steve said those things he was in front of a huge bar chart representing the amount of time it would take to port Cocoa, Carbon, and Carbon CodeWarrior projects. The Cocoa bar was half as short as the Carbon bar.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This was the famed Jobs Reality Distortion Field at work. His remarks were intended to sweet talk potentially frightened and pissed off Carbon developers. When listening to Jobs it is important to see if what he is saying matches up with the reality he is talking about. In this case his minimizing remarks were belied by his own giant graphic.</DIV><DIV><BR><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">Remember, the example that was used was Mathematica which is a Carbon application. Granted it was already cross platform code.<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And since we're talking about a transition to cross platform code here Mathematica was in effect already done. That's why they were picked by Apple as their "look how easy this will be" poster child.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">As an aside one might consider the influence of CodeWarrior being purchased by Motorola. Apple and Motorola have had some bad history so this might go some way toward explaining why Apple kept CodeWarrior out of the loop here.</FONT></P> <BR></BLOCKQUOTE><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">As far as CodeWarrior situation is concerned I believe that die was cast a number of years ago, before the sell out to Motorola. First MetroWerks couldn't grow the company as fast as they wanted to with just a Mac base (top guys wanted sell out for lots of $, former president is now a VC at SoftBank) so they went down the embedded path to pump up the revenue. They lost some focus on the Mac, lost some key Mac developers, and sold out to Motorola during the height of the bubble.</FONT></P> <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">I think Apple also wanted/needed a GCC based tool chain and wanted to be in control of their own destiny with respect to development tools. The same thing that happened with Symantec happened with MetroWerks. So I think Apple didn't want to be fooled a third time. I happen to be a big CodeWarrior fan, but I think Apple made the right decision. Xcode is OK.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Yes I agree that Apple was very keen to control its own development tool chain.</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">At 11:36 AM -0400 6/10/05, Raffael Cavallaro wrote:</FONT></P> <BR><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">And I believe<SPAN class="Apple-converted-space"> </SPAN>that Apple is hoping that developers will write mostly Cocoa apps using a bit of Carbon for that functionality not yet wrapped in Cocoa classes. Ultimately Carbon will be just another C library used from Cocoa.</FONT></P> <BR></BLOCKQUOTE><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">Look, if you know anything about Apple you know there is/was a kind of war inside Apple with respect to Carbon and Cocoa. There is a faction that wants to push Cocoa. There is a faction that wants to push Carbon. It used to be that the Cocoa camp was driven by the former NeXT folks and the Carbon camp was driven by pre-Next Apple folks. However now that entropy has had it's time to work, the lines are not so clear anymore. Like any war, things ebb and flow.</FONT></P> <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">I would say that recently there have been some promotions and other events that I think give the Carbon camp some needed support. Neither side has ever come close to winning this war and I don't either side ever will. Every year at WWDC this comes up and every year the Carbon guys say it ain't so and talk about a number of features that only Carbon has or has first. Apple's biggest developers such as Adobe, Microsoft, Quark, and many others are all Carbon based. As has been previously noted some new Tiger applications are built with Carbon and not Cocoa. Please stop fanning the flames of this war.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Sorry - it's my favorite programming spectator sport. ;^)</DIV><DIV>Or, to put it another way, when something concerns people greatly but they have little control over it they tend to talk about it a lot.</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 I certainly did not predict the X86 switch, I can say I was not at all surprised by Steve's "just in case" plan. Some of you may remember back just after the NeXT merger when Rhapsody was delivered Apple also delivered the "Yellow Box" which allowed what is now called Cocoa to run under Windows. It is pretty clear to me that iTunes for Windows uses this technology.<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Which is interesting as iTunes on the Mac side is a Carbon app. I wonder why it wasn't ported to Cocoa on the Mac side as well.</DIV><BR><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"> I suspect almost all of Apple's applications from Final Cut to Pages now run under Windows and Quicktime has run under Windows for quite sometime. Quicktime uses a port of the "Toolbox" to Windows which has existed for quite sometime. Darwin has always run on X86 machines and Apple has solicited help from the developer community for this. So if you put it all together it hasn't been hard to understand that backup plans have existed since the NeXT merger and that the backup plans have included MacOS X on X86 and Apple delivering it's applications on Windows if they choose, which they did, after "Hell Froze Over".</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Yes, and as has been noted, the headers have been littered with x86 references from the earliest Developer Previews of Rhapsody right through the present. You and others have correctly seen this as a sign of an intel back-up plan.</DIV><DIV><BR class="khtml-block-placeholder"></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">At 11:36 AM -0400 6/10/05, Raffael Cavallaro wrote:</FONT></P> <BR><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">Hopefully Apple will be in a position soon to let Gary and others know if and when a transition to X86-64 is coming which would allow him to skip the transitional step of IA32.</FONT></P> <BR></BLOCKQUOTE><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">You are confused about the differences between IA32, IA64, the 32 bit IA32 architecture and 64 bit IA32 architecture which is called EM64T.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Sorry - I said IA32 when I should have said X86-32 since, as you point out, IA32 has both 32 and 64 bit architectures.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I was referring to Gary's remarks:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>"Based on the (incomplete and vague) information available at this</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">point, I'd be tempted to say that the right strategy is to concentrate</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">on a native X86-64 port and ignore both X86-32 and "Universal</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Binaries" as being irrelevant (or at least of much lower priority.)"</DIV><BR><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">I don't think there should be much confusion about what MacOSX is going to support as far as 32 and 64 bit X86 architecture goes. Darwin is already a 64 bit OS in most respects. In my option there is no doubt that Apple is going do exactly the same thing they are doing today on the G5 with 32 and 64 bit applications. Most libraries and all GUI applications will be 32 bit X86. That's the only way a "simple recompile" to X86 "checkbox thing" in Xcode can work. Apple will offer almost exactly what they do today on the G5 for EM64T. You will be able to build a 64 bit command line application that uses EM64T. Over time, more libraries will be offered in both 32 bit and 64 bit versions.</FONT></P> <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">One thing I think is unclear at this time is if all Apple X86 CPUs will have EM64T. I am not sure how soon we will find that out. I suspect Apple and Intel want to keep their options open on that one. I know that there are some cheaper versions of "Yonah" mobile processors that will not have<SPAN class="Apple-converted-space"> </SPAN>EM64T and Apple may want to use those for iBooks and so on.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Wouldn't this be the uncertainty that Gary was referring to - how soon will all MacIntel machines be X86-64/EM64T?</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">Also there is a further fine point here. Even though Intel may advertise a specific CPU as not having EM64T, it actually may have it, but it's just turned off for marketing and pricing reasons. Intel is doing this today with "Prescott" based processors and has been doing this for years. But of course Apple will be a "special" customer and they may be able to arrange for all their processors to have EM64T.<BR></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This would be good news of course.</DIV><BR><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"> I suspect the pricing isn't close being final yet between Apple and Intel and so all this is up for grabs and probably will be until the last minute, knowing how Apple does what they call "business".</FONT></P></BLOCKQUOTE><BR></DIV><DIV>This would, as usual, be a pain - especially for Gary.</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>