Volume Number: 16 (2000)
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.

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(&currentPort);
	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).