[Openmcl-devel] More Intel: Rosetta & Universal Binaries

[Lawrence E. Bakst]

I don't believe Raffael's slant on Cocoa and related issues is correct.

At 5:06 PM -0400 6/10/05, Raffael Cavallaro wrote:
>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?

Sorry there are no "secret APIs" in Cocoa or really anyplace else, nor are any needed for Cocoa or Carbon. The APIs are staying the same. The byte sex and ISA are changing. Most modern applications should be insulated from both of these. Sometimes without knowing it, unless you test, byte sex does creep in. Most of the time the ISA doesn't. AltiVec/VMX is one case where is does a bit in some applications, but really they are few, and the code is usually isolated. Look at the architecture of Adobe Photoshop as an example.

Cocoa is a closed source object oriented framework built on top of the same layers that Carbon is, which are effectively both the public and private APIs in CoreFoundation, CoreGraphics, and other libraries or what Apple calls "Frameworks" (capital F).

Carbon is a set of data structures and APIs defined by C header files that call those same libraries/Frameworks. In some cases Carbon is little more than a thin veneer on top of those libraries.

In some cases Cocoa even calls Carbon. The reverse is not true. Some of what used to be called the Toolbox is now in CoreFoundation, CoreGraphics, and other Frameworks. So the boundaries between Carbon, Cocoa, and the Frameworks aren't quite as clear as you might think and Apple is free to factor the code any way they want as long as the public APIs for Carbon and Cocoa mostly stay the same. See my comments about Quicktime below for more info. The reason that Cocoa apps may be easier to port is that it's a higher level framework and object oriented you are more abstracted from data structures and low level constructs.

At 11:36 AM -0400 6/10/05, Raffael Cavallaro wrote:
>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.

You should listen to the keynote again. The word "transitional" was not used. 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".
Remember, the example that was used was Mathematica which is a Carbon application. Granted it was already cross platform code. So I really don't know how you reached your conclusions, but I really think you are wrong here.

At 11:36 AM -0400 6/10/05, Raffael Cavallaro wrote:
>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.

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.

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.

At 11:36 AM -0400 6/10/05, Raffael Cavallaro wrote:
>And I believe  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.

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.

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.

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. 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".

At 11:36 AM -0400 6/10/05, Raffael Cavallaro wrote:
> 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.

You are confused about the differences between IA32, IA64, the 32 bit IA32 architecture and 64 bit IA32 architecture which is called EM64T.

IA32 is another name for the 32 bit version of the X86 architecture
IA64 is another name for the Itanium 64 bit architecture

Intel had hoped it would not have to design a 64 bit version of the X86 architecture, hence the tags IA32 and IA64 which have been around since 1994 or so. With the failure of Itanium and AMD's introduction of a 64 bit version of the X86 architecture, Intel had no choice but to accept and copy AMD's 64 bit extensions. They call it EM64T.

See some very nice charts of what has what:
http://www.tomshardware.com/cpu/20041221/images/cpu_table_intel_big.gif
http://www.tomshardware.com/cpu/20041221/images/cpu_intel_big.gif

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.

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  EM64T and Apple may want to use those for iBooks and so on.

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. 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".

So can we put this all to rest for now?

Best,

leb, no Ph.D.