Apple Posts $38 Million Profit — Apple Computer posted a $38 million profit for its first fiscal quarter of 2002, directly in line with analysts’ expectations for the company. Despite an aging product line, Apple shipped 746,000 Macs and 125,000 iPods during the quarter, and posted revenue of $1.38 billion on gross margins of 30.7 percent. Although Apple didn’t break out sales at the 27 Apple retail stores around the U.S., they did say that the stores received over 800,000 visitors in December of 2001 alone. International sales accounted for 48 percent of Apple’s revenues. Notably, Apple said initial orders for the newly redesigned G4 iMac were greater than expected, and they expected revenue would rise in the second fiscal quarter of the year – highly unusual for a computer maker in the current sluggish economy. [GD]

<http://www.apple.com/pr/library/2002/jan/ 16results.html>

<https://tidbits.com/getbits.acgi?tbart=06682>

Apple Issues AirPort, Mac OS X Language Updates — Apple last weekend released a number of updates via Software Update. The AirPort Driver Update 2.0.1 for both Mac OS 9 and Mac OS X includes an updated driver for the AirPort Card that improves robustness and properly prompts for a password when joining a password-protected Computer-to-Computer network. Also included is new firmware for the original AirPort Base Station (Graphite; the new AirPort Base Stations are the same white color as the new iBooks and don’t need the firmware update). Improved in the update for the original AirPort Base Station is PPPoE support; after downloading the update, launch the AirPort Admin Utility, select your base station, and click Configure to start the update process.

<http://www.apple.com/airport/>

Over the weekend Apple also released updated localizations of Mac OS X in Brazilian Portuguese, Simplified Chinese, Traditional Chinese, Danish, Finnish, Korean, Norwegian, and Swedish. Although most people probably don’t need all of these languages, since older versions are probably already installed in your copy of Mac OS X, it might be best to download them to stay up to date for the off chance you need to switch languages unexpectedly. Or, of course, you can just select them in Software Update and choose Make Inactive from the File menu to prevent them from cluttering Software Update’s list from now on. [ACE]

Adobe InDesign 2.0 Now Available — Adobe is now shipping Adobe InDesign 2.0, a major update for the company’s next-generation page-layout application. InDesign 2.0 features object transparency, enabling you to import Photoshop or Illustrator files and retain transparency in feathered edges and drop shadows, for example. The new version also includes enhanced tools for creating and importing tables, expanded support for OpenType fonts, and greater collaboration with other Adobe programs. Perhaps most significant, InDesign 2.0 offers native support for Mac OS X, a claim that rival QuarkXPress seems unlikely to be able to make for some time. Finally, this release also extricates Adobe from a nasty legal situation it ran into at the close of 2001: a U.S. District Court judge prevented it from selling InDesign 1.5 due to a licensing issue with Trio Systems LLC over an InDesign component called C-Index, which led to a quick settlement for undisclosed terms; InDesign 2.0 doesn’t contain the C-Index code. The full retail version of InDesign 2.0 costs $700. Upgrades are available at $100 for owners of previous versions of InDesign, and $300 for owners of PageMaker or PageMaker Plus. [JLC]

<http://www.adobe.com/products/indesign/>

<http://www.triosystems.com/ci2/>

Folks who use Macs to provide Internet email services know the Mac OS has never been able to boast a plethora of email server options, unlike server systems for Windows and Unix. For years the Mac community has had a choice of perhaps half a dozen email servers, the future of which thrown into doubt by Mac OS X. After all, by incorporating Unix under the hood, Mac OS X systems can run high-end Unix-based email servers: robust, but notoriously arcane to configure and administer.

However, long-standing Macintosh email server products seem to be undergoing a bit of a rebirth, thanks perhaps in part to a loyal user base that doesn’t want to give up Macintosh ease of use. It started in 2000 with MCF Software’s acquisition of the venerable ListSTAR mailing list server, and two more mainstay Mac email servers have recently joined the trend: LetterRip and EIMS.

<http://www.mcfsoftware.com/>

<https://tidbits.com/getbits.acgi?tbart=06158>

LetterRip — LetterRip Pro is a popular mailing list server developed by Fog City Software – the same folks who originally created Emailer. LetterRip is distinguished by its stability, performance, and ease of use: although it’s not as flexible as the older and more complex ListSTAR, LetterRip ably meets most mailing list needs and is backed by an enthusiastic user community. (TidBITS actually uses both products: LetterRip handles TidBITS Talk, our translations, and other private mailing lists, while we use ListSTAR to distribute TidBITS issues and perform more complicated mail processing.)

<https://tidbits.com/getbits.acgi?tbart=05328>

LetterRip Pro was released in 1999 and hasn’t seen major updates since then, leading to speculation the product was more-or-less moribund (although Fog City was still offering prompt support and rapidly addressing problems introduced by new versions of the Mac OS.) The tide seems to have changed, however: as of 01-Jan-02, LetterRip Pro was acquired by a newly formed company, LetterRip Software, for the explicit purpose of bringing LetterRip Pro to Mac OS X and introducing new features. LetterRip development is being headed up primarily by Jud Spencer, one of LetterRip’s original developers back at Fog City; Jud was also one of the primary programmers on the still-much-loved Emailer, as well as Microsoft’s Outlook Express and Entourage. If you’re a LetterRip Pro user, there’s active discussion on the LetterRip mailing list about what features would be most beneficial in future versions: if you want to chime in, now is the time.

<http://www.letterrip.com/>

EIMS — It’s been a long and winding road for EIMS. The program started life as MailShare, a simple SMTP and POP mail server for the Macintosh written by Glenn Anderson of New Zealand, way back before the Internet "broke" into the public consciousness. In 1995, Apple acquired MailShare – along with Glenn – and rechristened it Apple Internet Mail Server (AIMS), back when Apple decided it wanted to play in the Internet server market. (Anyone remember the acronym AISS?) When Apple later decided it did not, in fact, want anything to do with Internet servers, Qualcomm picked up AIMS (and Glenn) in 1997, rechristening it Eudora Internet Mail Server (EIMS). Glenn saw EIMS through two major revisions with Qualcomm, adding support for IMAP, DNS blacklists, remote administration, and a swarm of other features – and EIMS remains a robust, high-performance server.

<https://tidbits.com/getbits.acgi?tbart=01532>

As of 21-Dec-01, EIMS has taken the long flight home again: Glenn Anderson has licensed EIMS back from Qualcomm and has just released EIMS 3.1. Glenn is also creating an EIMS Admin application for Mac OS X (an alpha version of which is available now), although plans for a Mac OS X version of the EIMS server aren’t yet clear. Glenn’s also considering a low-cost, stripped down version of EIMS for folks who don’t need all the features of the full version.

<http://www.eudora.co.nz/>

EIMS 3.1 offers numerous performance improvements, enhanced Apple Event support and performance, NTLM authentication for Outlook and Outlook Express, CRAM-MD5 authentication for POP3, LDAP authentication, delivery status notification information in message bounces, and statistics for queue delays and total messages sent and received. EIMS 3.1 costs $400 new, but upgrades from 3.0.x are available for $60 and from 2.x for $150.

Welcome Back — Even as Mac OS X opens up new vistas for Internet services on Macs, it’s great to see long-time Mac developers breathe new life into these (and other) well-regarded and long-lived products. It’s the kind of thing which essentially happens only in the Mac community, where expectations of sophisticated yet easy-to-use products runs high. Certainly, the Unix-indoctrinated among us will preferentially use Unix solutions for things like email and mailing lists, but the rest of us have always supported – and will continue to support – products designed and developed by people who understand what sets Mac software apart from the herd.

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.

<http://www.apple.com/macosx/>

<http://guide.apple.com/macosx/>

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.

<http://developer.apple.com/macosx/architecture/>

API in the Sky — 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.

Mac OS X can run applications based on Apple’s Classic APIs, which are also available on Mac OS 9 (and earlier), and were previously called the Mac Toolbox. Mac OS X also offers the Carbon 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 Cocoa 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.

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.

<http://java.sun.com/>

<http://www.apple.com/macosx/technologies/ darwin.html>

<http://httpd.apache.org/>

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

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

<http://www.microsoft.com/mac/office/>

<http://www.microsoft.com/mac/officex/>

<http://www.eudora.com/betas/>

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.

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.

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

<http://developer.apple.com/carbon/>

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.

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.

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.

<http://www.interarchy.com/>

<http://www.barebones.com/products/bbedit.html>

<http://www.openssh.org/>

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.

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

<http://developer.apple.com/techpubs/macosx/ Essentials/Performance/Carbon/Carbon_and __OS_X_Events.html>

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

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.

<http://www.omnigroup.com/>

<http://www.stone.com/>

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 TidBITS-601). 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.

<https://tidbits.com/getbits.acgi?tbart=06594>

Not Your Father’s Mac — 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.

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.

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

<http://www.reppep.com/~pepper/>