[Openmcl-devel] More Intel: Rosetta & Universal Binaries
raffaelcavallaro at mac.com
Fri Jun 10 15:36:06 UTC 2005
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
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.
Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel