President's Letter
by Andrew Welch





Steve Jobs announced MacOS X, and Apple's future operating system
strategy recently at the WWDC (world-wide developer conference). Our
company went to a local bar to watch it via satellite; it was an interesting
presentation. I'll see if I can cut through some of the jargon, to give a
summary of the announcement, as well as what we think of it from a small
developer's viewpoint. A bit of briefing is required first, however.

API stands for "application programming interface" -- think of it as the way
developers talk to an operating system. Just as Spanish is the language you'd
use to talk to someone from Spain, the MacOS APIs are what developers use
to write applications that will work with the MacOS. APIs define the "words"
that developers use to "speak" to an operating system or device (like a
graphics card or a printer). It takes quite a bit of time to be able to speak a
language such as Spanish fluently, and it takes a similar amount of time to
learn an API, and be able to use it well.

There are all sorts of APIs out there; it's a generic term that is used to describe
how the programmer will communicate with an operating system, graphics
card, or any number of other things. APIs can work across computing
platforms. As an example, for the popular 3DFx graphics cards, there is one
API that you use for it, whether you are running on the MacOS or on
Windows. This is great for developers, because it means they can write their
code once, and it'll work on other platforms.

APIs shouldn't be confused with programming languages such as BASIC, Pascal, C, C++, or Java -- you use APIs from within those programming languages to talk to a particular operating system, graphics card, etc. If we continue our analogy about APIs being languages that developers use to talk to an operating system, then programming "languages" such as those I mentioned before are the letters in an alphabet. You use one to construct the other: we use letters to construct words are used to communicate with people, and developers use programming "languages" to construct (and utilize) APIs that are used to talk to operating systems, graphics cards, printers, etc. Armed with that knowledge, let's move on to the meat of the developer conference announcements:

First, there was a sense of deja vu; we've been here before with Copland (albeit with important differences). MacOS X promises to have all of the underpinnings of a truly modern OS: high speed networking, preemptive multitasking, memory protection, and any other buzzwords you wish to throw in. This is what was promised with Copland some years ago as well, but there is an important difference.

Copland was Apple's modern operating system which was slated to have shipped well over a year ago. The reason why Copland failed is that they tried to make everything work -- all of the APIs that Mac developers knew well would continue to "just work" on the new operating system. There are APIs in the MacOS that date back to 1984, when the idea of running more than one application at a time -- let alone preemptive multitasking them -- was a foreign concept.

ANALOGY: Copland allowed developers to continue speaking the same language (APIs), but because of this restriction, Apple had a very hard time extending it. Imagine trying to change the meaning of words in the English language, while having the sentences they form still make sense.

It isn't always possible to retrofit everything -- Microsoft realized this when they chopped up the Win3.x APIs to create Win32. Win32 is a set of APIs which allows developers to write applications that will work on Windows 95, Windows 98, and Windows NT. Apple is doing something similar with MacOS X.

Apple has created a set of transitional APIs, called "Carbon", which are a subset of the current MacOS APIs. The problematic APIs which caused Copland to be scrapped have been eliminated. This is a good middle ground between Copland (100% compatibility in the APIs, but an engineering nightmare for Apple) and Rhapsody (0% compatibility in the APIs, making developers scrap their code/knowledge). Developers will be able to leverage their existing MacOS code, rewrite small portions of it to use the new Carbon APIs, and they will run on MacOS X, taking advantage of all of the modern OS features.

ANALOGY: Carbon is like modernizing a language's vocabulary, allowing it to communicate new ideas, while eliminating words that are no longer relevant to today's world. Try reading the original version of Moby Dick (colloquial expressions of the times, et al) compared to the modernized version, and you'll have a good idea of what Carbon is all about. It took some work to modernize that classic, but not nearly as much work as translating it into a completely different language.

Users running MacOS 8 will be able to run these applications that have been upgraded to the Carbon APIs through a set of extensions that will be installed on their machines. Applications that haven't been updated to the Carbon APIs will still run on MacOS X, but they simply will not take advantage of the new features. Again, a middle ground approach: moving forward while leveraging existing technologies.

Until I see more specifics about Apple's direction, there are a few issues that haven't been clarified for me, though. Steve mentioned that MacOS X is being targeted at the g3 chip; if this means no one except g3 owners will be able to run MacOS X, I think there will be a number of miffed customers. It's also a bit unclear where Rhapsody fits into this whole equation: Steve mentioned that the two would converge, but didn't specify a timeframe.

It's also unclear where the cross-platform strategy is going, namely the yellowbox APIs. The yellowbox APIs are a set of standards that application developers write to, which allows their applications to run on top of any operating system that has the supporting libraries. I can write an application that runs on MacOS, Windows 95/98, Rhapsody, WindowsNT, and perhaps Solaris (if Sun/Apple offer it) using the yellowbox. It's an extremely nice development environment, which reates applications that run on multiple platforms, with the native user interface of the platform (and without the slowness associated with other such solutions, namely Java).

ANALOGY: The yellowbox APIs are a totally new language; one that allows developers to express things more easily, quickly, simply, and powerfully than anything before it -- and it's a universal language that anyone can understand -- no translation necessary. If you learn the yellowbox APIs, you can write applications that "talk to" any operating system. The problem with this is that developers need to learn this new language to reap the benefits, which isn't something to be underestimated. Look at how long it's (still) taking to convert from the imperial system to the metric system, despite the latter's obvious advantages.

Now, for some questions I have, and my tentative answers:

• Will yellowbox applications run on MacOS X? (One would assume so, but it's not been specifically stated
yet)
• Why would any developer bother to learn the yellowbox APIs now that we have Carbon?
(In order to create applications that are cross platform from a single source code base --
something that Carbon does not offer. Carbon is a set of APIs that let developers transition
their code to MacOS X easily -- it's not a final destination.)
• Why would anyone bother with Rhapsody? (If you want a robust Unix machine as a
server or end-user machine, which has a nice GUI and can run MacOS apps, albeit it not
as fast as native applications)

If a lot of this jargon has made your head spin, I think the bottom line is this: MacOS X will give you a modern OS, and applications which take advantage of it's features without forcing developers to scrap their existing code to make their applications work with it.

P.S. The iMac is about as stylish as a purple polyester leisure suit.




Andrew Welch
Thaumaturgist
Ambrosia Software, Inc.




����