Feb 00 Factory Floor
Volume Number: 16
Issue Number: 2
Column Tag: From the Factory Floor
Carbon and PowerPlant
By Gregory Dow ©2000 Gregory Dow. All rights reserved.
Web apps with Lasso and FileMaker Pro
Gregory Dow is the senior architect and original author of PowerPlant, which he
started writing for Metrowerks in 1993. Greg works from his home in Berkeley,
Calif., where he has been leading a discussion group of Mac programmers for 12 years.
The group meets every other week in a local restaurant, sharing industry gossip and
technical tips. Greg enjoys helping fellow programmers and he is a regular
contributor to the comp.sys.mac.oop.powerplant newsgroup.
Biography
Gregory Dow is the original author of PowerPlant, which he started writing in 1993.
Greg works from his home in Berkeley, California, where he has been leading a
discussion group of Mac programmers for 12 years. The group meets every other week
in a local restaurant, sharing industry gossip and technical tips. Greg enjoys helping
fellow programmers and he is a regular contributor to the
comp.sys.mac.oop.powerplant newsgroup.
What is your overall opinion of Carbon?
Greg: I think that Carbon is not only a wonderful technology, but also a great name.
Carbon. It's the sixth element in the Periodic Table. It's the basis of all organic life. As
graphite, Carbon is the softest substance. As diamond,
Carbon is the hardest substance. In terms of puns and metaphors, Carbon puts the
Mac Toolbox at the same level as Java.
On the technical side, I think there are two important facets of Carbon. First,
Carbon will run on the upcoming Mac OS X as well as on all systems back to Mac OS
8.1. Programmers don't have to choose between developing for the cutting edge systems
and being compatible with a large installed base of machines - they can do both.
Second, Carbon extends the life of existing source code because it includes a large
subset of the classic Mac OS 8 Toolbox. Over the years, Apple has been very good about
maintaining backward compatibility. When new OS versions come out, existing
programs usually continue to work, or require only minor modifications. You don't
need to rewrite from scratch. Carbon continues this important tradition, although the
required changes are more substantial.
What factors should someone consider before adopting Carbon?
Greg: Moving to a new technology always entails some risks. Remembering ill-fated
technologies as QuickDraw GX, OpenDoc, and Copland, some developers are naturally
skeptical about Apple's commitment to Carbon.
However, Apple has a good track record with Carbon. The Carbon message was
consistent at the Worldwide Developers Conferences in 1998 and 1999. Carbon 1.0
shipped with Mac OS 9, and Carbon is included in the Developer Preview 2 version of
Mac OS X. Also, by the time you read this article, Carbon 1.0.2, which runs on Mac OS
8.1 or later, will be out.
One potential problem is that Carbon does not ship with Mac OS 8. Developers can
license Carbon from Apple for distribution with their products, but this is an extra
hassle that might deter hobbyists. Furthermore, the Carbon library is about 1 MB in
size, considerably large to bundle with a small program.
Another problem is that Carbon does not run on systems prior to Mac OS 8.1 and
supports only PowerPC machines. There is no workaround for this. If you need to
support 68K machines, System 7, or even earlier systems, you cannot use Carbon. You
would need to decide if it is worth the development effort to produce both Carbon and
Classic versions.
Developers with existing programs also need to make that same decision. They
should ask themselves, "do the benefits of Carbon outweigh the costs of porting the
source code?" Carbon is not a runtime feature. It is not like the Appearance Manager
where you are able to weak link a library, then decide at runtime whether to use one
set of routines or another. You cannot gradually Carbonize. It's all or nothing.
In Mac OS 8 and 9, there are not any significant advantages to using Carbon, and
Classic programs will still run on Mac OS X. The advantages come from Carbon on Mac
OS X, where the three major benefits are protected memory, dynamic heap sizes, and
pre-emptive multitasking. The value of these benefits depends greatly on what a
program does, although all programs are better off with protected memory because it
helps insulate a program from bugs in other programs.
Dynamic heap sizes will help programs that use a variable amount of memory.
This includes programs that open multiple documents or otherwise deal with
indeterminate amounts of data. Pre-emptive multitasking can make the entire system
feel more responsive and is very good for programs that perform lengthy computations
or otherwise need regular processing time.
What kinds of changes will people need to make to support Carbon?
Greg: I classify the differences between the Carbon and Classic Toolboxes into three
categories: syntactic, interface modification, and feature replacement.
Syntactic changes usually require only one or two line changes to source code. The
simplest are name changes, where Apple has renamed a symbol in order to be more
consistent with naming conventions. Such changes are not new to Carbon, as they occur
with almost every new version of Apple's Universal Interfaces.
Other syntactic changes result from many Carbon Toolbox data structures being
opaque, meaning that their format is private and not directly accessible. You need to
use an accessor function. For example, in Classic, you can access the font for the
current port as follows:
GrafPtr currentPort;
GetPort(¤tPort);
short currentFont = currentPort->txFont;
Referring to currentPort->txFont depends on the exact size and layout of the
GrafPort struct. Any change to that struct and the above code breaks. In Carbon, you
must call a function to get a port's font:
short currentFont = GetPortTextFont(currentPort);
The GrafPort struct is opaque, and not even defined in the header files for Carbon.
As long as the function GetPortTextFont() continues to return the font for a port,
Apple can change how GrafPorts are implemented without breaking existing programs.
This makes it much easier for Apple to enhance the system software.
Interface modification describes cases where Carbon and Classic have different
ways for accomplishing the same task. A very simple example is initializing the
Toolbox managers. With Classic, you need to call functions such as InitGraf(),
InitWindows(), and InitMenus(). With Carbon, you do not call any of these functions.
Carbon initializes the Toolbox automatically.
Another example of different interfaces is the Scrap Manager for dealing with
clipboard data. For Classic, you use the functions GetScrap(), PutScrap(), and
ZeroScrap(). For Carbon, you use the functions GetScrapFlavorData(),
PutScrapFlavor(), and ClearCurrentScrap(). There are small differences in how you
use the functions, but it's mostly a one-to-one correspondence.
The Printing Manager also has a different interface in Carbon. There are new data
structures and functions. However, there are routines for converting between the
Classic and Carbon data structures. This is very convenient, as a lot of Classic printing
code relies on directly accessing and storing the information in a PrintRecord.
The changes that will probably be the most difficult are feature replacements.
Carbon removes support for some system features such as Standard File, MacTCP, and
balloon help. Developers must convert code to use alternate features that are
supported. For the aforementioned features, suitable replacements are Navigation
Services, Open Transport, and MacHelp. If your programs rely heavily on an
unsupported feature, you will have a lot of work to do.
How have you implemented Carbon support in PowerPlant?
Greg: PowerPlant 2.0, the version in CodeWarrior Professional Edition, Version 5.0,
is being enhanced so that it can be used to build both Carbon and Classic programs.
Carbon is another possible target for a project, along with PowerPC and 68K.
Since Classic and Carbon have different interfaces, there is a lot of conditional
compilation. Universal Interfaces 3.3 and later include Carbon support, controlled by
the preprocessor symbol TARGET_API_MAC_CARBON. PowerPlant defines its own
PP_Target_Carbon and PP_Target_Classic symbols.
For the most part, I have tried to avoid having code within functions that looks
like:
#if PP_Target_Carbon
// Carbon code here
#else
// Classic code here
#endif
Such code is hard to read and maintain.
In cases where Carbon has new accessor functions, I use inline functions with the
same name that are defined only for Classic. For example, using the accessor for the
font of a port previously mentioned, I have defined:
inline short GetPortTextFont ( GrafPtr port )
return port->txFont;
}
This definition, along with all the other accessor functions that PowerPlant uses,
is within a single header file and bracketed by an #if so that it is not only defined for
Classic targets. The PowerPlant sources always call the accessor function. For Carbon,
this is an actual function call. For Classic, the inline function becomes a direct access
of the data value.
In cases where Carbon and Classic have different interfaces, I define a common
interface with separate implementations. For example, I have defined a UScrap
namespace with the functions GetData(), SetData() and ClearData(). There are two
implementations of each of these functions, one for Carbon and one for Classic. Client
code then makes calls such as UScrap::GetData(), with the setting of the conditional
compilation flags determining which function is used.
PowerPlant already has support for both Standard File and Navigation Services
using the same interface. There are three options: always use Standard File, always use
Navigation Services, and use Navigation Services if it is available at runtime
(otherwise use Standard File). For Classic, you can use any of these options. For
Carbon, you must always use Navigation Services.
Likewise, the PowerPlant networking classes have always provided an
abstraction layer that supports both Open Transport and MacTCP. Under Carbon, you
must use Open Transport.
How much work is required to Carbonize PowerPlant programs?
Greg: That really depends on what the programs do. People will need to do the same
kinds of things that I did with the PowerPlant sources. For simple programs, that will
mostly be the syntactic changes of using accessor functions.
Printing is the biggest change. PowerPlant will handle printing the built-in
panes and views. But people will need to update custom views with non-trivial
printing features (anything that accesses the PrintRecord).
Otherwise, updating an existing project requires minimal changes. You need to
create a new target, remove some old files and add some new ones, and set up a prefix
file with the correct options.