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

[Raffael Cavallaro]

On Jun 12, 2005, at Sun, Jun 12, 4:37 05 AM, Lawrence E. Bakst wrote:

> 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,

There were whole secret OS builds for 5 years. That's a bit more  
clandestine than a couple of undocumented APIs.

> nor are any needed for Cocoa or Carbon.

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.


> In some cases Cocoa even calls Carbon. The reverse is not true.

Which is why I said that I believe that Cocoa will eventually swallow  
Carbon.

>  So the boundaries between Carbon, Cocoa, and the Frameworks aren't  
> quite as clear as you might think

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.

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

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

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.

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.

> Remember, the example that was used was Mathematica which is a  
> Carbon application. Granted it was already cross platform code.

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.

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

Yes I agree that Apple was very keen to control its own development  
tool chain.

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

Sorry - it's my favorite programming spectator sport. ;^)
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.

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

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.

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

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.


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

Sorry - I said IA32 when I should have said X86-32 since, as you  
point out, IA32 has both 32 and  64 bit architectures.

I was referring to Gary's remarks:

"Based on the (incomplete and vague) information available at this
point, I'd be tempted to say that the right strategy is to concentrate
on a native X86-64 port and ignore both X86-32 and "Universal
Binaries" as being irrelevant (or at least of much lower priority.)"

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

Wouldn't this be the uncertainty that Gary was referring to - how  
soon will all MacIntel machines be X86-64/EM64T?

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

This would be good news of course.

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

This would, as usual, be a pain - especially for Gary.

regards,

Ralph

Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20050612/6a4496c0/attachment.htm>