Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cocoa vs Carbon

0 views
Skip to first unread message

Duncan

unread,
Oct 6, 2006, 10:31:20 AM10/6/06
to
Hi all,

I am new to OS X (and macs in general). I have a small active X
control I would like to port to OS X for Firefox and Safari (and using
universal binaries I hope). All the code is currently C++. I've
bought a MacBook and several books on the various technologies, however
these books are of course specific to their technologies and rarely
draw any comparisons. What are the advantages of Cocoa vs Carbon?
Does one provide better access to Quartz, OpenGL, etc? Is the main
difference merely syntax (C++ vs Objective-C)? Will it depend on the
browsers and OS versions I intend to support? Can someone point me to
a good starting point (book, doc, etc.) or breifly summarize the
criteria for choosing an API? I realize this is a vague question
(perhaps a dumb one too), but unfortunately I'm not yet sure of the
right questions to ask ;)

Thanks,
~Duncan

Reinder Verlinde

unread,
Oct 6, 2006, 11:25:37 AM10/6/06
to
In article <2006100610312075249-email@ddresscom>,
Duncan <em...@ddress.com> wrote:

> Hi all,
>
> I am new to OS X (and macs in general). I have a small active X
> control I would like to port to OS X for Firefox and Safari (and using
> universal binaries I hope). All the code is currently C++. I've
> bought a MacBook and several books on the various technologies, however
> these books are of course specific to their technologies and rarely
> draw any comparisons. What are the advantages of Cocoa vs Carbon?

In general, Carbon is C-based, procedural and, at times requires you to
specify many details of which you might think "can't the OS figure this
out for itself?" and carries some history that makes the system look
less coherent (partly because it is incoherent; OpenGL, for instance,
does not look like other APIs); Cocoa is object-oriented, more
high-level, and will infer many default settings for you.

> Does one provide better access to Quartz, OpenGL, etc? Is the main
> difference merely syntax (C++ vs Objective-C)?

No, it is not merely syntax. Semantically, Objective-C is in many ways
closer to Smalltalk than to C++. It also has a (AFAIK) unique way of
memory management
(<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/in
dex.html>)

> Will it depend on the browsers and OS versions I intend to support?

The natural match would be

FireFox -- Netscape API - C(++)
Safari -- Webkit API - Objective C

but you can (sometimes with some glue code) program both APIs in both
C(++) and Objective-C. C++--Webkit may be a bit of an awkward match.

OS-version wise, I do not think there will be many incompatibilities
when looking at it from this far away, especially if you forget about
supporting anything before Mac OS X 10.3 (and probably even about 10.3,
too)

> Can someone point me to a good starting point (book, doc, etc.) or
> breifly summarize the criteria for choosing an API? I realize this
> is a vague question (perhaps a dumb one too), but unfortunately
> I'm not yet sure of the right questions to ask ;)

<http://developer.apple.com/documentation/InternetWeb/Conceptual/WebKit_P
luginProgTopic/index.html>

Also, take a look at the sample code in Developer/Examples/WebKit/
(subfolders NetscapeMoviePlugIn and WebKitMoviePlugIn)

Reinder

Sherm Pendley

unread,
Oct 6, 2006, 2:34:27 PM10/6/06
to
Reinder Verlinde <rei...@verlinde.invalid> writes:

> In article <2006100610312075249-email@ddresscom>,
> Duncan <em...@ddress.com> wrote:
>
>> I am new to OS X (and macs in general). I have a small active X
>> control I would like to port to OS X for Firefox and Safari (and using
>> universal binaries I hope).

...

>> Will it depend on the browsers and OS versions I intend to support?
>
> The natural match would be
>
> FireFox -- Netscape API - C(++)
> Safari -- Webkit API - Objective C
>
> but you can (sometimes with some glue code) program both APIs in both
> C(++) and Objective-C. C++--Webkit may be a bit of an awkward match.

Also keep in mind that no Mac browser supports the huge gaping security
hole that is ActiveX. Most Mac users think of that as a feature, not as a
problem. We switched to get *away* from that kind of security nightmare.

If you absolutely *must* put executable code in your web pages that Mac users
can run, Java applets are your only option. Otherwise you're looking at a
plugin.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Duncan

unread,
Oct 6, 2006, 5:11:41 PM10/6/06
to
On 2006-10-06 14:34:27 -0400, Sherm Pendley
<sh...@Sherm-Pendleys-Computer.local> said:
>
>
> If you absolutely *must* put executable code in your web pages that Mac users
> can run, Java applets are your only option. Otherwise you're looking at a
> plugin.
>
> sherm--

Sorry, poor choice of terminology (force of habit)... I do mean "plugin".

Thanks,
~Daimen

0 new messages