Oct 99 Getting Started
Volume Number: 15 (1999)
Issue Number: 10
Column Tag: Getting Started
Catching up with Carbon
by Dan Parks Sydow
The Current State of the Carbon API
Back in January of this year we looked at Apple's then-new Carbon - the application programming interface (API) meant to be a replacement for the Macintosh Toolbox. At that time we said that Carbon existed so that a programmer could write an application that would run on either a Mac hosting Mac OS 8 or on a Mac hosting the upcoming Mac OS X. That's still true. But now, with the release of Mac OS 9 from Apple and the release of support files from Metrowerks, a programmer can move from theory to application. Carbon isn't completely finalized, but the bulk of it is in place. So now you can start writing and compiling code to verify that your program is indeed Carbon compliant.
About Mac OS X and Carbon
If you aren't at all familiar with Mac OS X or with Carbon, and you have access to the Getting Started article in the January 1999 issue of MacTech, go ahead and give it a read. If you don't have that article, or just want a very quick summary of these two Apple software technologies, make sure to read this section.
Mac OS X is the soon-to-be-released version of the Mac operating system that is to bring on important and necessary enhancements that both programmers and users have been waiting for. Chief among those improvements are increased stability (via a protected address space for each process, or running application), increased responsiveness (by way of preemptive multitasking so that the processor can better serve each process), and dynamic resource allocation (via a "use-as-needed" scheme where a process uses system resources such as memory only as needed). Mac OS X has three separate application areas, or environments:
Classic This area, formerly called the Blue Box, allows for the running of any Mac OS 8 application. If a program runs on Mac OS 8 now, then a software developer need make no changes to an existing program in order for it to run on Mac OS X. There is a key drawback to leaving Mac OS 8-compatible applications untouched, however. While such a program runs fine on a Mac hosting Mac OS X, it won't take advantage of the new features of Mac OS X (as mentioned in the above paragraph).
Carbon This area allows for the running of Mac OS 8-compatible applications that have been recompiled, or fine-tuned, for Mac OS X. Such a program does take advantage of the new features of Mac OS X. Such a program can also be run on Mac OS 8, though of course when it does it won't retain Mac OS X features such as enhanced performance (since the benefits of Mac OS X of course won't be present on the Mac OS 8 Macintosh).
Cocoa This environment, formerly referred to as Yellow Box, is for new programs that, like Carbon applications, take advantage of the new features of Mac OS X. A Cocoa application, however, won't run on a Mac hosting Mac OS 8 or 9.
The difference between a Classic application and either a Carbon or a Cocoa application are obvious - a classic application isn't upgraded to capitalize on the benefits of Mac OS X. The difference between a Carbon application and a Cocoa application aren't so obvious. To an end user the differences aren't noticeable at all. That's because the differences are found in the source code used to create both types of program. A Carbon application is built from code that uses the Carbon API - the modified Toolbox API. A Cocoa application is instead built from an entirely different API - one based on the NeXT OpenStep API. While a Carbon application is typically written in C or C++ (or possibly Java), a Cocoa application is typically written in Java or Objective-C. Because this column has for years featured the Macintosh Toolbox API (the only API there was for creating Mac programs sporting the Macintosh graphical user interface), we'll be focusing on Carbon. That way almost everything you've learned in previous Getting Started articles still applies to your future Carbon programming endeavors. More advanced programmers, or programmers familiar with NeXT's OpenStep API would be wise to learn Cocoa - it's tools (primarily Interface Builder, which let's you "draw" your application's user interface and add common functionality before you start writing code) aid in the rapid development of Mac OS X applications.
Converting to Carbon
Apple's goal in developing the Carbon API: to give programmers an easy means to make their existing applications ready for Mac OS X. By starting with the time-tested, and very familiar, Macintosh Toolbox, Apple knew that a programmer's learning curve would be minimized. When you look at the routines that make up the Carbon API you will notice that they look pretty much like the routines that make up the Macintosh Toolbox API. Carbon, it turns out, is simply a cleaned-up and enhanced Macintosh Toolbox. That's great news for those of us familiar with the Toolbox.
The Macintosh application model (event-driven, menu and window interface) is essentially unchanged in Carbon. Mac OS 8 (and now Mac OS 9) and Mac OS X are built on different cores, though, so how an application accesses system services does differ in some respects. To write an application using Carbon, or to Carbon-tune an existing application, there are a few issues you need to be aware of.
Separate Application Address Spaces
A chief advantage of Mac OS X is that each application runs in it's own protected address space. When one application crashes, other running applications remain unaffected. A Carbon application takes advantage of Mac OS X features, so a Carbon application runs in its own protected address space. If your application uses system memory or temporary memory, you'll need to make some changes. Simple applications, like the ones we've been writing here in Getting Started articles, don't take any liberties with memory, so this issue won't affect our (and perhaps, your) trivial programs.
If you're writing more complex applications, check your source code for use of the FreeMem(), PurgeMem(), and MaxMem() Toolbox functions. These routines are supported in Carbon, and will deliver expected results when your Carbonized program runs under Mac OS 8. But when that same program runs under Mac OS X, these routines do essentially nothing. You'll want to evaluate their use in your application to see if the tasks they are expected to accomplish are important under Mac OS X.
68K Code and the Mixed Mode Manager
When Apple made the transition from 68K to PowerPC processors, the concept of the universal procedure pointer (UPP) came about. A UPP is a pointer to a data structure that holds information about a function. One of the pieces of information specifies the instruction set architecture of the function. That is, whether the function can be handled directly by the PowerPC processor or whether the Mixed Mode Manager must pass instructions to a 68K emulator for preliminary processing. Mac OS X does not run 68K code, so the Mixed Mode Manager is of no use to an application running under Mac OS X. If your application includes the use of the Mixed Mode Manager, though, you shouldn't need to worry. Carbon supports UPPs transparently (meaning that you can still use UPPs so that your application runs properly on Mac OS 8).
Printing
If you application includes the ability to print, then you'll need to make changes to it - Carbon includes a new Printing Manager. By using the new Printing Manager your application will be able to print on Mac OS 8 using existing printer drivers and be able to print on Mac OS X using new printer drivers. Detailed coverage of the new Carbon Printing Manager is well beyond the scope of this article - but you can take a peek at this manager's functions and data types by looking at the header file PMApplication.h.
Callback functions
A callback routine is an application-defined function that the system executes when some task is completed. Back in this year's March Getting Started article we provided an example of a callback routine - we wrote one that the Sound Manager invoked to let our program know that a sound had completed playing. Carbon supports such application-defined callback routines, so the callback code of an application (such as our March example AsynchPlayer) will not need modification.
Carbon and Opaque Data Structures
Much of the Carbon API consists of Toolbox routines that have been made Mac OS X compatible. But Carbon also includes new routines as well. A big change brought on by Carbon is that many commonly used data structures are now opaque. That is, their internal structure - the fields or members that make up the structures - are hidden from the programmer. For instance, while a window still consists of a WindowRecord, your application should not attempt to directly access the fields of that record. The same holds true for dialog boxes, menus, controls, and the QuickDraw globals.
To allow your program to access opaque data, Carbon introduces new accessor functions. Here's an example. In the past, you could directly access a WindowRecord field by first casting a WindowPtr to a WindowPeek, and by then examining a field of the WindowRecord. If your program defined a few different types of windows, you could keep track of what type a window was by storing an application-defined constant in the windowKind field of the window's WindowRecord. Like this:
#define kDrawingWindow 1
#define kTextWindow 2
WindowPtr theWindow;
theWindow = GetNewWindow( 128, nil, (WindowPtr)-1L );
(WindowPeek) theWindow->windowKind = kDrawingWindow;
The above snippet creates a new window and specifies that this window be considered to be a drawing window. Attempting to compile the above code using the Carbon API will result in errors. That's because Carbon won't let you access the opaque fields of the WindowRecord. Instead of using a WindowPeek, you'll use the new SetWindowKind() function:
theWindow = GetNewWindow( 128, nil, (WindowPtr)-1L );
SetWindowKind( theWindow, kDrawingWindow );
Carbon introduces a number of new routines to make life with opaque data structures manageable. You'll be seeing a lot more of them in future articles.
CodeWarrior and Carbon
Compiling your Carbon code and building an application results in an executable (a program) that can run on Mac OS 8 or 9, and can run on Mac OS X. You don't need to keep two separate sets of code, or build two applications. If you're fortunate enough to have a Mac running Mac OS X, you can do your work on that machine. If you have Mac OS 8 or 9, you can now also take care of business. This wasn't possible a while back because the tools for non-Mac OS X development didn't exist for Mac OS 8. Now they do - if you have a recent version of Metrowerks CodeWarrior, such as CodeWarrior 5.0..
CarbonLib Shared Library
To build a Carbon application you'll create a new CodeWarrior project based on CodeWarrior's Carbon stationary. Doing that results in a project that includes a Carbon Support folder which holds a number of files that may be unfamiliar to you. Figure 1 shows the project that results from the Carbon stationary. Note that if you're using an older version of CodeWarrior, you won't have the Carbon Support folder in your Metrowerks CodeWarrior folder.
Figure 1.A CodeWarrior project based on Carbon stationary.
Of key interest here is the CarbonLib and LiteCarbonLib shared library files. The CarbonLib shared library provides the Carbon functions that your project will be using. LiteCarbonLib holds a subset of the functions found in CarbonLib. Mac OS 8 does support all of the existing Carbon functions. As of this writing, Mac OS X doesn't include support for all of the Carbon functions. LiteCarbonLib holds only those functions currently supported by Mac OS X. If you want to build an application that is Carbon-compliant, and you don't need to test it under Mac OS X now, then your interested in CarbonLib. If you need to test your Carbon-compliant application on Mac OS X now, you'll want to build it with LiteCarbonLib to ensure that it will run on Mac OS X now. Once Mac OS X fully supports all the Carbon functions (remember, Mac OS X Client version for consumers isn't shipping as of this writing), this dual-library issue will disappear - we'll all only need the full set of functions found in CarbonLib.
Project Targets
The project target menu near the top left of the project window is used to determine what type, or types, of applications get built when you choose Run or Make from the Project menu. For Mac projects you've typically selected a 68K, PowerPC, or fat application. As shown in Figure 2, here in a Carbon project, you'll select a Mach-o, CarbonLib, or LiteCarbonLib application (or all of those types). Here's how you'll decide which target to select.
CarbonLib When you perform a build on a project (when you choose Run or Make from the Project menu), CodeWarrior creates an object file from each source file and then links these separate object files (along with the resources in project resource files) to form a single executable, or application. For Mac OS 8 application development, the resulting object files are in Code Fragment Manager (CFM) format. These code fragments are stored in Preferred Executable Format (PEF) containers and are managed by the Code Fragment Manager. CodeWarrior pretty much hides those details from you - so don't feel bad if acronyms such as CFM and PEF are new to you. Mac OS X supports the Code Fragment Manager, so this way of creating an application that runs on Mac OS X still works. In fact, if you're creating a Carbon application that is to be able to run on both Mac OS X and on Mac OS 8, you must create an application using CFM object files (otherwise the resulting application couldn't run on Mac OS 8). To tell CodeWarrior to generate a Carbon application that runs on both Mac OS 8 and Mac OS X, you'll choose the CarbonLib item from the project window's target pop-up menu. That's what's being selected in Figure 2 (there the menu item is named BasicApp CarbonLib because the CarbonLib item is prefaced with the project's name).
LiteCarbonLib If you're building the application on a Mac running Mac OS 8, and you may be soon testing the application on a machine running Mac OS X, you may want to instead use the LiteCarbonLib menu item (the last item in the menu shown in Figure 2). Recall that Mac OS X doesn't support all Carbon routines at this time, so creating a LiteCarbonLib application ensures that when you run the resulting application on Mac OS X it won't attempt to access unsupported routines. When Mac OS X fully supports Carbon, there'll be no need to build a LiteCarbonLib application.
Mach-o Mac OS X supports CFM object files and the Code Fragment Manager, and thus CarbonLib applications. But it also supports the Mach object file format, also referred to as Mach-o. Mac OS 8 doesn't support Mach-o, so you can only target Mach-o if your application is only meant to run on Mac OS X. A more likely reason to target Mach-o is for debugging purposes. At this time Mach-o is the best format for debugging an application on Mac OS X.
BuildAllTypes Hopefully this target type is self-explanatory - choosing it results in the building of all three types of executables.
Figure 2. Mac OS X/Carbon targets in CodeWarrior.
Source Code
If your application is a simple one, as many of our Getting Started examples are, you may be able to make its code Carbon-compatible very easily. In fact, just a few alterations to your code may do the trick. One addition you will need to make is the following line of code to the top (before any #includes) of one of your source files:
#define TARGET_CARBON 1
Other changes you need to make to your source code are dependent on just what your program does. In this article we've provided a few instances where you'll need to watch for Carbon-compatibility.
Testing For Carbon Compatibility
Back in January we discussed how you can easily test your code for Carbon compatibility. The steps for doing so remain essentially the same - you'll Carbon Date your code using Apple's Carbon Dater. A free download of this software program is available from Apple at <http://developer.apple.com/macosx/dater.html>.
To use the Carbon Dater software you simply drag and drop your program (not the source code, but rather the ready-to-run standalone application itself) onto the Carbon Dater application icon. Carbon Dater will launch, examine the application that was dropped on it, and generate an output file. This output file needs further analysis. Apple does that free, quickly (usually in less than an hour), and by an automated process if you e-mail the Carbon Dater output file (which ends with the extension .CCT) to CarbonDating@apple.com (note that Apple recommends that you send the .CCT file as a stuffed file).
In exchange for your submission of a .CCT file, Apple sends you a report in HTML format. Open the report in your favorite Web browser to see how Carbon-compatible your application is. Figure 3 shows a part of that report for a small application named BasicApp.
Figure 3. A Carbon report from Apple.
Apple examines the Carbon Dater output file in order to determine all of the Toolbox functions your code accesses, and to then tell you which calls you need to update or replace. Every objectionable, or questionable, Toolbox call your program makes appears listed in the report. After looking over the report you'll have an idea of how much work (or how much more work) is needed in order to make your application fully Carbon-compliant.
Till Next Month...
Apple is very well along in its job of creating the Carbon API - but the Carbon API is not yet finalized. When that time comes (and it will be soon), we'll have one more Carbon-related Getting Started column. In that article we'll look back at a previously written Getting Started example program, and look forward at what it takes to Carbonize it. We'll provide the complete source code listing - with detailed discussion - one just what changes are needed to get the program ready for Mac OS X and for Mac OS 8 and 9. Until then, we'll move on to other topics...
