June 96 - Planning for Mac OS 8 Compatibility
Planning for Mac OS 8 Compatibility
STEVE FALKENBURG
One of the most important goals for Mac OS 8 (formerly known by
the development name "Copland") is the preservation of
compatibility with existing applications. Customers consistently
rank compatibility as a critical factor in their decision whether to
upgrade to a new OS release, with good reason. This article sheds
light on what will and won't be compatible, and gives developers a
road map for ensuring compatibility with the Mac OS 8 release.
As one of the driving forces behind Mac OS 8, compatibility is at the forefront of the
minds of Apple engineers hard at work on this system software release. Given the track
record of nearly seamless compatibility with the Power Macintosh, customers will
expect their existing applications to run under Mac OS 8 with few or no problems.
Apple is working hard to deliver on this promise, and we're beginning to succeed. Most
of the specific information for this article was learned the hard way -- by getting
many existing applications up and running.
Of course, tradeoffs must be made to move the platform forward. If Mac OS 8 were to
remain compatible with all Macintosh software, the performance, reliability, and
stability of the system would suffer. While some customers have been impressed by
the stability of System 7, others would like to experience even fewer crashes and are
willing to upgrade some of their software in the process. Apple's system software
needs to be more stable, while still maintaining compatibility with most applications.
Luckily, there are quite a few techniques that you can use today and guidelines that you
can follow to ensure compatibility with Mac OS 8. This way, you can impress your
friends (and confuse your enemies) at compatibility labs by installing your software
for the first time under Mac OS 8, and walking away 15 minutes later saying, "Gee,
that was easy, everything works!" This is when following all of those Inside Macintosh
chapters, develop articles, and Technotes will finally pay off.
Don't panic: Mac OS 8 isn't the compatibility "day of reckoning" that you've had
nightmares about. I'm sure many of you have been told by Developer Technical
Support, "Here's a really cool trick, but it may break in the future." In some cases,
"the future" is in fact Mac OS 8, but on the other hand many techniques that are no
longer being recommended (which we of course like to call "sick hacks") will continue
to work.
Remember that Mac OS 8 is just the first step in modernizing the Macintosh.
Subsequent system releases will include features such as separate address spaces and
full preemption for all applications. In the future, discouraged techniques will become
areas of incompatibility; so even if your application runs under Mac OS 8, it's worth
cleaning it up in preparation for future systems.
In this article, I'll go over a few things that will no longer work under Mac OS 8 as
well as some of the techniques that will continue to work under Mac OS 8 but will
break in future systems. For the more heinous examples of these techniques, I won't
give code samples -- I don't want people saying "Hey, I did it just like they did in
develop" as an excuse. I'll also discuss some specific case histories of application
compatibility problems, to further illustrate the need to be proactive when planning
for compatibility.
For an overview of Mac OS 8, see http://www.macos.apple.com/macos8
on the World Wide Web, or the article "Copland: The Mac OS Moves Into the
Future" in developIssue 22. Other introductory documents can be found on this
issue's CD. Please keep in mind when reading these materials, as well as this
article, that the terminology has evolved over time and some of it may change
again by the time you read this.*
WHAT WORKS AND WHAT DOESN'T
Before diving into guidelines, warnings, and examples, we'll start with an overview of
exactly which types of software will be compatible with Mac OS 8, which will need to
be updated, and which will need to be redesigned. This article focuses on applications,
but an overview of compatibility in general is helpful to set the stage.
First, the good news: Well-written applications conforming to Macintosh development
guidelines should run without any modification. This includes PowerPC(TM)-native
applications as well as emulated applications. Theoretically, you could have written a
Macintosh Solitaire game in 1984 that would also run under Mac OS 8. There are, of
course, caveats to application compatibility, which will be discussed later in this
article.
Component software is becoming an important part of the Macintosh experience, and
Mac OS 8 will support OpenDoc part editors as well as application-specific plug-ins
-- again, without any modification. Depending on the "parent" application, there may
be issues with plug-in compatibility (as discussed later).
Now, the bad news: Existing extensions, control panels, desk accessories, ASLM
libraries, and most drivers are unsupported for the Mac OS 8 release. Compatibility
tradeoffs needed to be made in these areas to move the system forward and improve
system reliability.
Macintosh power users often try to impress each other by comparing how many
extensions load at startup, gracing their "Welcome to Macintosh" screen with several
rows of happy little icons. The proliferation of INITs has made life as a Macintosh user
exciting, if a little hazardous. With Mac OS 8, we're trying to attack the system
stability problem head on by providing new, more reliable mechanisms for
extensibility and patching. While the original Macintosh was presented as a complete
solution, the Mac OS 8 team has realized that third-party extensibility is part of what
makes the system great. This has led us to make ease of extensibility a key goal of the
system.
As with extensions, for each existing code type that's not supported under Mac OS 8, a
new and much improved mechanism will be provided. In other words, we'll still have
MacHack entries for years to come, and they'll be just as cool but more reliable.
Other, less common software types are also unsupported. These include Text Services
Manager input methods, FSM external file system modules, and debuggers. This article
focuses on application-level issues, so I won't go into a lot of detail in these areas, but
a section on migration paths is included in the article.
APPLICATION TAXONOMY
For the Mac OS 8 release, the types of applications that developers write can be split
into several major categories. These categories have been defined by the Mac OS 8
project teams, and work is being done to ensure that each of the application types is
fully supported by the Mac OS 8 design. This article doesn't cover each type in detail,
but we'll use the classifications as guideposts for migration and compatibility plans.
USER INTERFACE APPLICATIONS
type makes up the majority of applications on the Macintosh. These applications use
windows, menus, and dialogs and are usually document-centric. Examples include
ClarisWorks, Quicken, and Microsoft Excel. There are three variants of this
application type: Mac OS 8-savvy, minimal-adoption, and Mac OS 8-compatible.
think it would be: an application that takes significant advantage of Mac OS 8 features,
such as preemptive tasking, improved event delivery, and new user interface features.
Because these APIs aren't available under System 7, a Mac OS 8-savvy application
will not run under pre-Mac OS 8 system releases. Note that Mac OS 8-savvy
applications still must maintain a cooperatively scheduled task so that they can call the
Macintosh Toolbox, and this cooperative task lives in the same address space with all
other System 7 and Mac OS 8-savvy applications. It's possible to have other portions
of the application run in separate address spaces, and servers (such as file sharing)
are completely protected from applications.
Minimal-adoption applications. Not all developers may want to or be able to
make the move to a Mac OS 8-only application immediately. The minimal-adoption
application type is intended for these situations. The characteristics of this category
include "fitting in" with the Mac OS 8 look and feel while still maintaining
compatibility with System 7. Some subset of Mac OS 8 features (not APIs) will be
available to these applications, such as the removal of the fixed-size Memory Manager
heap limitation, and the new-look, theme-specific, user interface elements. This
application type is distinguished from System 7 applications by its correct appearance
under Mac OS 8 and its adoption of Mac OS 8 features on a runtime-check basis.
Mac OS 8-compatible applications. Well-written applications authored
originally for pre-Mac OS 8 systems will continue to work under Mac OS 8. If you
follow the guidelines in this article and adhere to documented Macintosh application
programming practices, your application should be Mac OS 8 compatible. Of course, to
take advantage of Mac OS 8 features in your application, you may need to release a new
version.
REAL-TIME APPLICATIONS
Real-time applications are applications that have time constraints on aspects of their
behaviors. If these constraints aren't met, the application either fails or needs to adapt
gracefully to these operating conditions. Examples include data collection applications
such as LabView, multimedia applications such as Premier, and games such as
Marathon. Under Mac OS 8, real-time applications may choose to take advantage of
enhanced timing services and preemptive scheduling to improve their performance. In
some ways, however, Mac OS 8 provides new challenges to these applications, since
virtual memory is always enabled and preemptive scheduling may cause the
application to lose control of the CPU in unforeseen situations. That said, performance
will be vastly improved from the System 7 Virtual Memory Manager, so this shouldn't
be a concern for most developers.
OPENDOC PART EDITORS
OpenDoc part editors are a relatively new application type. OpenDoc will continue to be
an important direction for document-oriented applications under the Mac OS 8 release.
As you'll see throughout this article, OpenDoc is also a suggested migration path for
several types of existing applications.
SERVERS
Servers are a new concept introduced in Mac OS 8. They're preemptively scheduled and
run in their own protected address spaces. These features provide independence from
the cooperative Toolbox environment and mean that servers have greatly enhanced
stability, surviving the crashes of applications or other, ill-behaved servers. New
reentrant services are provided in Mac OS 8 to make servers possible, including
tasking, messaging, memory allocation, file system access, and networking. Only a
subset of the Mac OS 8 APIs are available to servers, and this subset does not include
the Macintosh Toolbox calls (Window Manager, Menu Manager, QuickDraw, and so on).
This means that servers cannot present a user interface. Candidates for servers
include World Wide Web Internet servers, virus checkers, and high-end publishing
print servers.
UTILITY APPLICATIONS
Utility applications manage a single window for user interface and have no menu bar.
To the user, they aren't usually considered a separate application. Mac OS 8 will
support utility applications as a generalized application type, unlike previous system
releases. An additional use of utility applications is to present a user interface on
behalf of a server. For example, a utility application could be used to configure an
e-mail forwarding server with the proper e-mail addresses. Other examples of this
application type include Apple Guide and configuration control panels.
OTHER NON-APPLICATION CLASSIFICATIONS
Three other classifications that are useful to our discussions but don't refer to
applications are extension libraries, patch libraries, and drivers.
Extension libraries. Extension libraries allow additional code to be introduced into
the Code Fragment Manager (CFM) closure for an application. An example use of an
extension library would be to track software launches and quits through CFM
initialization and termination routines to perform software auditing.
Patch libraries. Patch libraries allow patches to be installed into applications
through data-driven means, simplifying the customization process. Patch libraries
apply their patches in only one context, but can be combined with extension libraries
to achieve global-effect patching. The Get/SetTrapAddress methods of the past have
proven difficult or impossible to maintain and have resulted in greatly decreased
system reliability. The patch library mechanism, with associated extension libraries,
provide a more than capable replacement for the pre-Mac OS 8 patching methods.
Drivers.Under Mac OS 8, the device driver mechanism has been rearchitected to
ensure a high-throughput and flexible I/O system. Pre-Mac OS 8 'DRVR'-style
drivers are not supported and so need to be rewritten. As we'll discuss below, some
software written as a driver today may be better written as another application type.
MIGRATION PATHS FOR EXISTING APPLICATIONS
The first step in preparing for Mac OS 8 is determining the migration path your
application will follow. Depending on what type of application you have today, this
could mean a complete rewrite, minor tweaks, or no changes at all.
The most important point along the Mac OS 8 migration path is the first one:
compatibility. Before determining the best way of moving your application forward,
you should ensure that it runs out of the box on Mac OS 8. We'll discuss compatibility
specifics in a later section.
Each System 7 application type has a unique migration path; the sections below cover
the available options.
USER INTERFACE APPLICATIONS
As shown in Figure 1, a System 7-based user interface application has several
alternatives for migration. The simplest alternative is not to revise the application at
all, or, if needed, do the minimum required to make the application Mac OS 8
compatible.
Figure 1. The migration path for a user interface application
Another alternative is to convert the application into an OpenDoc part editor. I'm not
going to go into OpenDoc in this article; if you choose this route, see the article "The
OpenDoc User Experience" in develop Issue 22 for a good overview of how part editors
work from the user's perspective.
If having a single binary for both System 7 and Mac OS 8 is important, the
minimal-adoption option may be appropriate. By migrating to minimal adoption, you
ensure user interface consistency and may be able to take advantage of a limited
number of Mac OS 8 features. For example, more efficient memory management is