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

[Chris Curtis]

On Jun 10, 2005, at 11:36 AM, Raffael Cavallaro wrote:

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

As [the] one [of those] who made that observation....

> Once again, Carbon has always been advertised as a *transitional*  
> technology. The keynote made clear that porting a Carbon app to  
> ix86 is

I keep hearing this, and I just don't think it's true. The last time  
I remember hearing the "Carbon is transitional" refrain was back  
around 10.1.

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

I think we need to be careful about ascribing reasons for the  
comparative level of difficulty. CodeWarrior is a red herring here:  
the fact that moving to Xcode and porting to Intel is harder than  
just porting an existing Xcode project is hardly surprising, and says  
nothing at all about Cocoa vs. Carbon.

Apart from that, there may be any number of technical reasons why  
porting a Carbon app is more difficult that have nothing to do with  
whether it is "better supported" or not. They simply express  
radically different paradigms (and thus there are good reasons why  
Carbon will continue to exist as an independent API).

It's probably also worth noting that the *types* of applications that  
tend to be written in Carbon or Cocoa differ as well. I think it's a  
safe bet that the majority of signal-processing-type applications are  
written in Carbon. But signal-processing applications are going to be  
harder to port anyway, and not because Carbon is a "second-class" API.

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

There are entirely independent reasons why Apple builds as much as  
possible in Cocoa... and they are some of the same reasons why we  
like to build as much as possible in Lisp. It's a higher-level tool  
set. Writing your own styled HTML text widget instead of using WebKit  
is not dumb because it's swimming against the stream; it's dumb  
because you (usually) don't need to.

If you mean Carbon *apps* are inherently more difficult to port, then  
see above -- it's probably not strictly because of Carbon per se.

If you mean that Carbon itself is inherently more difficult, then (a)  
I don't see any significant reason why that would be true, and (b) as  
you pointed out, a lot of Cocoa is wrappers around Carbon  
functionality which would need to be ported anyway. All of which is  
moot, since everything has been running internally on both platforms  
from the outset.

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

I doubt Apple particularly cares one way or the other, as long as  
apps get written. Cocoa happens to make that much easier for a large  
class of applications, so they naturally want to support that.

> 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

I agree it was clearly the right choice, but because, for *most*  
applications, Cocoa is a great framework that gives developers a huge  
advantage. Not because Apple doesn't [plan to] adequately support  
Carbon.

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

There's so much unknown yet about what the Mac/Intel will look like,  
that it is indeed wise to wait for more information. And hope for  
more registers.

--chris