[Openmcl-devel] More Intel: Rosetta & Universal Binaries
enderx12 at mac.com
Fri Jun 10 12:53:45 EDT 2005
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
> 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
> 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 information about the Openmcl-devel