<div id="popup_box_thanks" style="display:none" onClick="close_popup_thanks('popup_box_thanks', 'ts')"><br>Thanks for submitting your tip! All submissions are moderated by an editor before appearing online. We've reset the form so you can enter another tip. Or you can close the tip submission box. <div class="x_close" id="thanks_upper_right"><a href="javascript:void(0)" onmousedown="close_popup_thanks('popup_box_thanks', 'ts'); return true;">Close</a></div></div>
<div class="tbf_row"><div class="tbf_wide_extra_top not_bold">Please submit only technical tips that will help other TidBITS readers better use their Macs, iPhones, and related software and hardware. All product announcements should be sent to <a href="mailto:releases@tidbits.com">releases@tidbits.com</a>.</div></div>
<div class="tbf_left">URL</div><div class="tbf_right"><input type="text" value="" name="tip_link_url" tabindex="3"><span class="tip_description"><br>Enter the URL to a Web page that supports your tip.</span></div>
</div>
<div class="spacer"></div>
<div class="tbf_row">
<div class="tbf_left">Linked text</div><div class="tbf_right"><input type="text" value="" name="tip_link_label" tabindex="4"><span class="tip_description"><br>Enter the name of the page linked above.</span></div>
<div class="tbf_wide"><input type="submit" value="Preview Your Tip" name="preview_tip" onClick="fill_preview('tipbits_enclosure_preview', 'ts', this.form); return false;" tabindex="7"> <input type="submit" value="Send Us Your Tip!" name="submit_this_tip" onClick="handle_tip_submission('ts', '', this.form, 'tip'); return false;" tabindex="8"></div>
</div>
<div class="spacer"></div>
<div class="tbf_row">
<div class="tbf_wide"><span class="fine_print">When you submit a tip, you give us permission to use it. Read <a href="javascript:void(0)" onClick="generic_show_hide('tip_terms')">our terms</a> for more details. All submissions are reviewed before publication.</span></div>
<div class="tbf_wide"><span class="fine_print">Our terms: By submitting a tip, you agree to assign TidBITS Publishing Inc., a non-exclusive, worldwide, perpetual license to reproduce, publish, and distribute your tip in connection with the TidBITS Web site and associated products in any media. You agree that you created the content you submitted, and that you have the right to assign us this license. You give us permission to use your name, but your email address won't be publicly displayed or shared. We review all submissions before publication, and reserve the right to select which submissions we feel are appropriate for our readers and to edit those we publish.</span></div>
<div id="comment_thanks" style="display:none" onClick="close_popup_thanks('comment_thanks', 'comm')"><br>Thanks for submitting a comment! Please check your email for a link that, when clicked, will verify that you're a real person and cause your comment to appear immediately. <div class="x_close" id="comment_upper_right"><a href="javascript:void(0)" onmousedown="close_popup_thanks('comment_thanks', 'comm'); return true;">Close</a></div></div>
<div class="tbf_wide"><span class="fine_print">Our terms: We reserve the right to edit or delete any comment, so please post thoughtfully. We use your email address <i>only</i> to send you a one-time verification message confirming that you posted this comment. We also store your address to allow you to verify using other Web browsers in the future. For more info, see our <a href="http://db.tidbits.com/privacy.html">privacy policy</a>.</span></div>
<li><a href="/feeds/tidbits.rss" title="Subscribe via RSS" class="gettb">RSS <img src="/images/feed-icon-12x12.gif" width="12" height="12" border="0" class="nav_img" alt="Subscribe via RSS"></a></li>
<li><a href="http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=276986548" title="Subscribe to the podcast" class="gettb">Podcast <img src="/images/feed-icon-12x12_podcast.gif" width="12" height="12" border="0" class="nav_img" alt="Subscribe to the postcast"></a></li>
<li><a href="http://www.twitter.com/TidBITS" title="Get Article Updates via Twitter" class="gettb">Twitter <img src="/images/feed_icon_12x12_twitter.png" width="12" height="12" border="0" class="nav_img" alt="Get Article Updates via Twitter"></a></li>
<li><a href="http://www.facebook.com/pages/TidBITS/195314925519" title="Go to the TidBITS Page at Facebook" class="gettb">Facebook <img src="/images/feed_icon_12x12_facebook.gif" width="12" height="12" border="0" class="nav_img" alt="Go to the TidBITS Page at Facebook"></a></li>
<li><a href="javascript:void(0)" title="Sections" class="tabhead" onClick="return showhide('articleslist')">Sections <span id="articleslist_triangle"><img src="/images/nav_triangle_open.gif" width="9" height="9" border="0" class="navtriangle" id="articleslist_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<li><a href="javascript:void(0)" onClick="return showhide('stafflist')" title="Staff" class="tabhead">Staff <span id="stafflist_triangle"><img src="/images/nav_triangle_closed.gif" width="9" height="9" border="0" class="navtriangle" id="stafflist_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<li><a href="javascript:void(0)" title="Issues" class="tabhead" onClick="return showhide('issuelist')">Weekly Issues <span id="issuelist_triangle"><img src="/images/nav_triangle_closed.gif" width="9" height="9" border="0" class="navtriangle" id="issuelist_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<li><a href="javascript:void(0)" onClick="return showhide('abouttidbits')" title="About TidBITS" class="tabhead">About TidBITS <span id="abouttidbits_triangle"><img src="/images/nav_triangle_closed.gif" width="9" height="9" border="0" class="navtriangle" id="abouttidbits_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<li><a href="http://www.tidbits.com/about/support/contributors.html">Readers Like You!</a></li>
</ul><div class='sponsor_sidebox_bottom'> </div>
</div>
<!-- end sponsor_sidebox -->
</div> <!-- end leftcolumn div -->
<!-- end left column -->
<!-- begin centercolumn_border -->
<div id="centercolumn_border">
<div class="center_top">Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling <a href="http://www.takecontrolbooks.com/?pt=TB-TAGLINE" style="color:yellow">Take Control</a> ebooks.</div>
<!-- begin centercolumn -->
<div id="centercolumn">
<!-- begin rightcolumn_container -->
<div id="rightcolumn_container">
<!-- begin rightcolumn -->
<!-- rightcolumn is embedded within centercolumn so featured text wraps around it -->
</div><!-- end tearoffbox_wide_container for watchlist items -->
<!-- begin tearoff box wide -->
<div class="tearoffbox_wide_container">
<div class="tearoffbox_wide_tips">
<div class="tip_display">
<div class="tips_sponsor_logo">
</div>
<h6>Find Graphics in TextEdit .rtfd Files</h6>
<p><p>Want to find the graphics in a TextEdit document in the .rtfd format? The document is actually a package - a special kind of folder that looks like a file. To see and extract just the graphics, Control-click the document and choose Show Package Contents. A new window opens showing you just the embedded images, along with a TXT.RTF file that contains the text of the file.</p></p>
</div>
<div class="tearoffbox_wide_bottom_tips">
<div style="padding-bottom:35px"><div class="tip_display" style="float:left"><p><br><a href="/tipbits/243">Link to this tip</a></p></div><div class="tip_display" style="float:right; width:150px">
<p class="credit">Written by<br><a href="/author/Adam%20C.%20Engst">Adam C. Engst</a></p></div></div>
<div class="tbf_wide_80" id="hc_rc_5310">To help us avoid automated posts and misuse of our site, please enter the words below.</div><div class="x_close_row" id="hc_upper_right2_5310"><a href="javascript:void(0)" onmousedown="HidePopupContent('hc_5310', 'hc', '5310'); return true;">Close</a></div>
<div class="featured_meta"><div class="meta_article">21 Jan 2002 | <a href="/article/6694?print_version=1">Print <span class="shift_up"><img src="/images/printer_icon.gif" alt="Printer-Friendly Version of This Article" border="0" width="9" height="10"></span></a></div></div>
<div id="article_box_5310"><P>As we discuss Apple's new operating system, there's a strong awareness that, no matter how good Mac OS X itself might be, it can't succeed without applications created outside Apple. As a result, Apple has put a great deal of effort into both encouraging and pressuring developers to produce software that takes full advantage of the new operating system and requires Mac OS X to run - which will in turn convince users to switch. Unfortunately, since Mac OS X and Carbon (the technology that enables programs to run under either Mac OS 8.6/9.x or Mac OS X) are still relatively new, developers have found themselves stuck between the rock of Apple's Carbon rhetoric and the hard place of its incompleteness. Mac OS X 10.1.2 is a major improvement in terms of maturity, but can't yet compare to the Classic Mac OS's two decades of refinement - begun even before the Macintosh, with the initial development of Apple's Lisa computer.</P><P><<A HREF="http://www.apple.com/macosx/">http://www.apple.com/macosx/</A>><BR><<A HREF="http://guide.apple.com/macosx/">http://guide.apple.com/macosx/</A>></P><P>Mac OS X combines several earlier products into a new and modern operating system, and each brings its own identity and user community along. To make things more interesting, some of the threads Apple has woven into Mac OS X have historically gone in different directions; contrast the Classic Mac OS, designed for non-technical people, with Unix, which was intended for programmers. The end product is a surprisingly successful blend, but Mac OS X's mixed ancestry shows up in some interesting ways. Because each of the different elements includes its own interfaces, biases, and applications, it's impossible to get a good grasp of Mac OS X without keeping in mind the varied heritage of its programs. In part one of this article, I'll go over the three application breeds familiar to most Mac OS users - Classic, Carbon, and Cocoa - and explain their strengths and weaknesses regarding the Mac OS as a whole. In part two, I'll talk about the advantages of Mac OS X's Java support and look at applications written purely for Unix, the heart of Apple's new operating system.</P><P><<A HREF="http://developer.apple.com/macosx/architecture/">http://developer.apple.com/macosx/architecture/</A>></P><P><STRONG>API in the Sky</STRONG> -- The defining characteristic of a Mac OS X application today is the set of APIs (Application Programming Interfaces) it uses, the group of requests an application can make of the operating system - from "what time is it?" and "draw this paragraph in Palatino 12 in that window" to "open this URL in Help Viewer." To avoid redundant effort, programs use APIs as much as possible. This means, for instance, that most applications don't need to deal with fonts directly, because they can have the OS generate font menus and display text. Because of Mac OS X's long and complex history, programmers can choose among several different API sets, each of which manifests some of its own characteristics in programs using the API.</P><P>Mac OS X can run applications based on Apple's <EM>Classic</EM> APIs, which are also available on Mac OS 9 (and earlier), and were previously called the Mac Toolbox. Mac OS X also offers the <EM>Carbon</EM> APIs, a subset of the Mac Toolbox, designed to offer compatibility with Mac OS 9 while also making specific incompatible changes that make possible major benefits under Mac OS X. Carbon's changes enable preemptive multitasking, superior virtual memory, and crash protection for applications in Mac OS X - none of these additional features are available to Carbon applications running in Mac OS 9. In addition, Mac OS X includes the NeXT-developed <EM>Cocoa</EM> APIs - in fact, many of today's Cocoa applications were previously available under NeXTstep, the operating system developed by Steve Jobs's former company, NeXT.</P><P>All three of the above API sets are proprietary to Apple, but Mac OS X also supports a couple important public API sets (covered in part two of this article). First, Mac OS X supports the Java APIs, designed by Sun to enable the creation of programs that use the Java programming language and run on multiple operating systems. Then there's support for Unix APIs through Darwin, Apple's open source Unix operating system foundation. Based on BSD Unix, the Unix API layer is what enables Mac OS X to run the powerful Apache Web server. This richness of APIs gives Mac OS X many more applications than one would expect in a new operating system - but keeping track of the various types of programs can be confusing.</P><P><<A HREF="http://java.sun.com/">http://java.sun.com/</A>><BR><<A HREF="http://www.apple.com/macosx/technologies/darwin.html">http://www.apple.com/macosx/technologies/ darwin.html</A>><BR><<A HREF="http://httpd.apache.org/">http://httpd.apache.org/</A>></P><P><STRONG>Classic</STRONG> -- The most familiar programs under Mac OS X - for now, at least - are Classic programs. These are mostly written for Mac OS versions 7 through 9 and tend to run the same as they would in Mac OS 9. To accomplish this, a copy of Mac OS 9 runs as an invisible Mac OS X program (called, appropriately, Classic). The Classic layer of Mac OS X is good enough that most programs run exactly the same under Mac OS X as they would under Mac OS 9. The exceptions are mostly programs that control hardware directly, such as CD recorders, since Mac OS X has new and incompatible drivers to manage such devices.</P><P>The broad compatibility offered by Classic is critical for the success of Mac OS X, since the many existing Classic programs enable people to use Mac OS X on a daily basis, getting work done with familiar tools instead of waiting years for programs to be rewritten. Microsoft Office 2001 and Eudora 5.1 are two excellent examples of important Classic programs - the Office applications enabled people to use Word, share Office documents, and crunch numbers normally when running Mac OS X until Microsoft released the carbonized version of Office X in mid-November of 2001. In a similar vein, the Classic version of Eudora is still being widely used in Mac OS X while Qualcomm works on the Carbon beta of Eudora (recent releases of which have improved significantly).</P><P><<A HREF="http://www.microsoft.com/mac/office/">http://www.microsoft.com/mac/office/</A>><BR><<A HREF="http://www.microsoft.com/mac/officex/">http://www.microsoft.com/mac/officex/</A>><BR><<A HREF="http://www.eudora.com/betas/">http://www.eudora.com/betas/</A>></P><P>Because the Classic APIs are based on Mac OS 9, Classic programs can't take full advantage of Mac OS X's new capabilities. In addition, since Classic works by running an entire copy of Mac OS 9 inside Mac OS X, there is a great deal of duplication - some of which is managed well, and some of which isn't. For example, you can connect to file servers through the Classic Chooser, or through the Carbon Finder. Either way, file servers are available to both Classic and Carbon programs, but they show up in different places depending on how you are navigating. The Carbon Finder shows them on the desktop, or under the Computer top-level folder; old Open/Save dialogs and Navigation Services show them at the top level, but lack a Computer container; in Terminal and Unix-based programs, they're under the top-level Volumes folder.</P><P>To run Classic programs, it's first necessary to "boot" Mac OS 9, which adds significant startup time for the first Classic program launch; Classic can then stay running until logout or restart, but a Classic crash can still bring down all Classic programs (only Carbon and Cocoa programs gain the benefits of the new protected memory model). Additionally, since there are separate clipboards for Classic/Carbon applications and Cocoa applications, there is a brief delay before synchronizing them, so it's possible to copy from a Classic program and then paste the wrong thing in Cocoa program, or vice-versa.</P><P><STRONG>Carbon</STRONG> -- Carbonized programs running under Mac OS X are more interesting, because they automatically take advantage of improvements introduced with Mac OS X with less effort than a complete rewrite in Cocoa. Some of the major changes are implicit and automatic for all Carbon programs - such as improved memory management and live window dragging. (Taking advantage of other changes in Mac OS X requires explicit support that must be added to any application that's ported to Carbon.) In addition, Apple is now putting essentially all of their operating system development effort into Mac OS X, so the benefits of Apple's ongoing development work have shifted from Mac OS 9 (which is now being revised primarily to support Mac OS X better) over to the new platform. Mac OS X is rapidly getting better, and these improvements are focused on Carbon and Cocoa applications.</P><P><<A HREF="http://developer.apple.com/carbon/">http://developer.apple.com/carbon/</A>></P><P>Once developers have carbonized their Classic programs and become familiar with the new environment, we'll see a resumption of the normal process of development and improvement, instead of the current stage where existing applications are moving to Carbon, but not acquiring many new features. Developers are starting to cease work on their Classic programs and shift attention to Carbon and Mac OS X. The rate at which this transition occurs is important to Apple - if it's too slow, people will continue to use Mac OS 9 for "real work" and consider Mac OS X a toy. As key developers gradually cease Mac OS 9 development, as Microsoft has done, pressure to upgrade will grow stronger.</P><P>Distinguishing Carbon programs from their Classic counterparts is made easy by the different window interfaces. Classic programs use the old 2D Platinum appearance (rectangular windows, grey borders, zoom boxes in the upper right), while Carbon (and Cocoa) programs use the Aqua interface, with rounded edges, drop shadows, 3D style buttons, and the colored close, minimize, and zoom buttons in the upper left.</P><P>The improvements in Mac OS X open up new possibilities for Mac applications. Most Carbon programs are currently just prettier versions of Classic programs, but Apple doesn't draw attention to that. After attaining feature completeness in Carbon, developers start introducing new features unique to Mac OS X. This was the case, for example, with Interarchy 4.1 and BBEdit 6.1 - both programs merely attained Carbon parity with an existing Classic version. Then came Interarchy 5, which offered OpenSSH encryption for FTP transfers thanks to Mac OS X, and BBEdit 6.5, which included better integration with external programming tools, a Unix shell worksheet window, and a tool for controlling BBEdit from the command line. Because Mac OS X is so rich in new APIs, it offers tremendous opportunities for growth.</P><P><<A HREF="http://www.interarchy.com/">http://www.interarchy.com/</A>><BR><<A HREF="http://www.barebones.com/products/bbedit.html">http://www.barebones.com/products/bbedit.html</A>><BR><<A HREF="http://www.openssh.org/">http://www.openssh.org/</A>></P><P>Looking beyond the immediate need to migrate programs, Apple is attempting to make Carbon a superior platform for developing new applications, as illustrated by changes in the underlying way the system handles events such as mouse clicks, keystrokes, window drags, and so on. The way Classic programs work is that they run in a tight loop, waiting for the user to do something. During that time, they also voluntarily cede processor cycles to other applications. Even though a Classic application may not be doing anything, it's still wasting processor cycles waiting for events.</P><P>In contrast, Carbon applications in Mac OS X can take advantage of a different approach to handling events, called Carbon Events (the same approach Cocoa applications use). With Carbon Events, programs register with the operating system the types of events they will react to and how they will respond to these events. When such an event occurs, the system triggers the right application response, but if nothing relevant happens, the program doesn't consume <EM>any</EM> processing time. The idea is that this will make programming simpler, since the programmer only has to deal with the specific stimuli they're interested in, and also make the system faster since it will only give programs processor cycles when they have something to do.</P><P><<A HREF="http://developer.apple.com/techpubs/macosx/Essentials/Performance/Carbon/Carbon_and__OS_X_Events.html">http://developer.apple.com/techpubs/macosx/ Essentials/Performance/Carbon/Carbon_and __OS_X_Events.html</A>></P><P><STRONG>Cocoa</STRONG> -- After Steve Jobs left Apple, he founded NeXT, which built computers that resembled Apple prototypes - cutting-edge hardware, with many of the same technologies as Macs (Motorola processors, PostScript, etc.). To match this advanced hardware, NeXT developed the NeXTstep software, which was essentially three things, a Unix-based operating system, a windowing system based on Adobe's Display PostScript, and a programming API that enabled the fast development of graphical applications. That API has evolved over the years, becoming OpenStep when NeXT gave up on the hardware business, and then Cocoa when Apple acquired NeXT.</P><P>So Cocoa was mature well before it was integrated into Mac OS X, while Carbon was designed and written at Apple starting in the early phases of Mac OS X development. For this reason, Cocoa applications from NeXT developers like The Omni Group and Stone Design had a considerable head start over their Carbon counterparts. As Apple has fleshed out the Carbon environment in Mac OS X 10.0 and 10.1, Carbon and its applications have reached a kind of parity with Cocoa, but each has strengths and weaknesses. Cocoa applications require significantly less work on the programmer's part because of everything Cocoa provides, but writing a Carbon application is a more familiar process for a Macintosh developer. Plus, there are some things Macintosh programmers expect to be able to do that are possible only in Carbon. As Apple continues to work on both, the differences between programs written in either environment will decrease.</P><P><<A HREF="http://www.omnigroup.com/">http://www.omnigroup.com/</A>><BR><<A HREF="http://www.stone.com/">http://www.stone.com/</A>></P><P>It's increasingly difficult to tell the difference between Carbon and Cocoa applications, both of which use the same Aqua appearance, but here are some clues. If it's relatively small, uses drawers (like Mail), has a Font panel for selecting fonts, it's almost certainly a Cocoa application. Another minor distinction that exists currently is the difference between the way Carbon and Cocoa applications let the user navigate Open and Save dialogs (for more on the discrepancies see "Apple's Dirty Little Secret" in <A HREF="http://www.tidbits.com/tb-issues/TidBITS-601.html">TidBITS-601</A>). Apple is wisely trying to iron out the remaining discrepancies in application behavior. In the long run, it shouldn't matter to an end user if an application has an object-oriented NeXT heritage or the Classic Mac OS in its ancestry, although Cocoa applications will always be significantly smaller than Carbon applications, given that so much of the necessary code for a Cocoa application is built into Mac OS X.</P><P><<A HREF="http://db.tidbits.com/article/06594">http://db.tidbits.com/article/06594</A>></P><P><STRONG>Not Your Father's Mac</STRONG> -- As of this writing, Classic is still essential to Mac OS X, since there are many Classic applications without carbonized versions or Cocoa equivalents available. As developers release Carbon and Cocoa programs, Classic will become a vestige of Mac OS history. Already, major software releases for the Mac OS - with the Classic-only QuarkXPress 5.0 being a notable exception - are generally Carbon apps, due to large existing code bases and lack of familiarity with Cocoa. But NeXTstep/Cocoa developers have another opportunity to demonstrate the advantages of their favorite programming environment, and they're hoping to woo existing Mac developers over to Cocoa, which provides all the advantages of Mac OS X for far less effort than writing a new Carbon application.</P><P>Mac OS X goes beyond Classic, Carbon, Cocoa, with support for native Unix and Java programs as well. Macintosh development in those environments is just getting started, but as developers previously unfamiliar with the Mac discover what's possible in Mac OS X, Apple's best-of-both-worlds operating system is garnering increasing attention. Part two of this article will take a look at these developments.</P><P>[Chris Pepper is a Unix System Administrator in New York City. He's amused and somewhat surprised that Mac OS X has turned out to be such a great management workstation for the Unix systems he works with. Chris is involved in various documentation efforts, including those for Interarchy and the Apache Group.]</P><P><<A HREF="http://www.reppep.com/~pepper/">http://www.reppep.com/~pepper/</A>></P><!-- Mac OS X: Breeds of Programs, Part 1 Chris Pepper --></div>
<!-- end article text -->
<!-- PayBITS -->
<p> </p><div class="sponsorbox">
<div class="sponsortext"><A HREF="http://nuance.com/dragon/mac"><IMG SRC="http://db.tidbits.com/images/badges/dragondictatelockup_vertical_onlight.png" ALT="" HEIGHT="50" WIDTH="50" BORDER="0" ALIGN="left"></A>Dragon speech recognition software for Macintosh, iPhone, and iPad!<br />Get the all-new Dragon Dictate for Mac from Nuance Communications<br />and experience Simply Smarter Speech Recognition.<br />Learn more about Dragon Dictate: <<a href="http://nuance.com/dragon/mac">http://nuance.com/dragon/mac</a>></div>
