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

[Raffael Cavallaro]

On Jun 10, 2005, at Fri, Jun 10, 10:44 01 AM, David Steuber wrote:

> I seem to recall that it was also observed that new features in  
> Tiger also exist as Carbon apps (Spotlight) and that Carbon doesn't  
> seem to be going away any time soon.  Instead, it keeps getting new  
> APIs.

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. My personal belief is that Carbon  
will simply be swallowed by Cocoa - you'll end up with a Cocoa Xcode  
project that directly uses any Carbon functionality that hasn't yet  
been wrapped in Cocoa classes.

When Apple strongly suggests that developers do a thing one has to  
realize that Apple is playing with a full hand and we are not. They  
can and do have other reasons which they may choose not to make  
public for doing what they do. So when I see Apple moving as much as  
possible to Cocoa I see this a sign that doing otherwise is swimming  
against the tide. Once again, Apple does not have infinite resources.  
If they have to choose in a pinch whether to make going forward  
easier for Cocoa or easier for Carbon which do you think they'd  
choose? Oh, that's right, they already had to make such a choice for  
the intel move, and clearly, they've been organizing this transition  
around Cocoa and Xcode for years. Carbon legacy apps got the short  
end of the stick here, partly because Carbon is inherently more  
difficult to port to intel than Cocoa, and partly because many Carbon  
legacy apps have been developed and maintained using CodeWarrior.

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.

>
> Xcode also continues to keep Carbon open as a target and apps are  
> allowed to use both Cocoa and Carbon APIs.

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.

>
> If Metroworks can't do Cocoa, then that is indeed a strike against  
> it.  A rather hard strike indeed.  I was thinking more about Apple  
> pushing Xcode over, say, Lispworks or any other possible  
> development environment (like OpenMCL).

Again, Apple had no choice here. To do otherwise would have been to  
inform a number of companies that they were likely moving to intel.  
How long do you think that would stay secret? Apple has the tools in  
place now because they needed them internally to do 5 years worth of  
OS and Apple application builds. Other language implementors will  
have to play catch up because Apple was not in a position to tell  
them they would need to move to intel one day. I know I would not  
have bought the dual g5 tower on my desk if I had known Apple was  
moving to intel down the road. I wouldn't have bought the 17"  
PowerBook I own.  Now multiply this by millions of customers and  
realize that Apple would have gone under in much the same way as  
Osborne did back in the '80s if they put the fortunes of LispWorks   
or MCL ahead of their own.

To bring this back to openmcl, Gary made the right choice years ago  
when he decided to heed Apple's advice and focus on Cocoa not Carbon  
for Mac OS X. Unfortunately Apple were not in a position to tell Gary  
to start developing an IA32 back end 5 years ago even though Apple  
themselves already had one working for every build of Mac OS X.  
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. Until that time I think  
that Gary is wise to wait and focus immediate efforts on how nicely  
openmcl plays with Rosetta's dynamic translation.


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/20050610/e004c0e2/attachment.htm>