Pascal PPC MacApp
Volume Number: 12
Issue Number: 2
Column Tag: Object Pascal
MacApp 2 for PowerPC in Object Pascal 
“Object Pascal is not bad, it just smells funny.” - apologies to F.Z.
By Brian Arnold
Whither Native?
This is an article for developers who have Object Pascal MacApp 2 code and want to
make that code native for PowerPC [or for anyone whose pulse was set racing by
Brian’s and Guy MacCarthy’s preliminary report in the November 1995 issue - man].
Along the way, it will describe the MacApp2PPC developer’s cooperative as an example
of how developers can help themselves when they need it the most. Although the
MacApp framework itself has long since made the switch to the PowerPC, it has done so
at the expense of Pascal Object support. The latest version of MacApp, 3.3, is written
in C++, and has features to make you salivate - drag and drop, AppleScript, PowerTalk
mailers, performance optimizations - and version 3.5 will have OpenDoc container
support. You could convert your source code and upgrade today; many developers have
done this. There are a number of excellent Object Pascal to C++ translators available
on the market to help you in this conversion. But if you’re resource constrained, or
C++ syntax causes a gag reflex, or you have some other Very Important Reason to stay
with your Object Pascal MacApp 2 code, MacApp2PPC provides another alternative.
MacApp 2 for PowerPC
The Pascal version of the MacApp framework is hardly five years old now, and it’s
already doomed to obsolescence. Or is it? Maybe once OpenDoc and SOM arrive in full
force, we can seal the coffin on this version of the framework and look elsewhere for
Object Pascal framework solutions. But until then, the lean and mean MacApp 2 still
has some mileage left in the millions of lines of excellent Macintosh code written using
it.
So what’s so difficult about porting MacApp 2 to PowerPC? To find out, I
announced a developer’s cooperative at the Apple May 1994 WWDC. Immediately,
twenty developers joined. We encountered several difficult obstacles, and by
distributing the effort among the developers, we were able to make the necessary
changes to MacApp 2 in just under 12 months.
Of course this would all be academic if there hadn’t been support from Apple and
the compiler vendors. Language Systems (LS) licensed MPW Pascal from Apple and
further developed a PowerPC back-end; LS is now developing it as a Symantec IDE
plug-in compiler. They were instrumental in providing us with support when we
were just getting started. Apple aided in the development of the project, particularly
at the hack session that helped finalize the port. Metrowerks developed a compatible
PowerPC Pascal compiler, and later added Pascal Object support and made it a plug-in
compiler for the CodeWarrior (CW) IDE.
MacApp 2 for PowerPC has been designed to work with both the LS Pascal and CW
Pascal compilers, and is provided by both Language Systems and Metrowerks for use
with their native Object Pascal compilers.
MacApp 2 Conversion
Here’s the short list of elements in MacApp 2 that had to be changed for PowerPC.
• MacApp 2 makes extensive use of 68K assembly and in-line code that can’t run
(easily) on PowerPC. This code had to be rewritten in Pascal, C, or PowerPC
assembly.
• MacApp 2 relies on AppFile Toolbox calls and has no support for required Apple
events. The PowerPC runtime architecture does not support AppFile calls for
opening documents at application startup, and expects you to support the required
Apple events (open application, open document, print document, quit
application).
• MacApp 2 uses 68K-specific methods for trap patching. On PowerPC, patching a
Macintosh Toolbox trap is a lot less trivial and more costly, so it needs to be done
differently and less often.
• MacApp 2 makes extensive use of ProcPtrs for Mac Toolbox callbacks. Since the
PowerPC Toolbox is designed to operate with both PowerPC and 68K applications,
all callback ProcPtrs need to identify whether they are compiled for 68K or
PowerPC. A toolbox glue routine for each ProcPtr fills in this information, plus
some other housework, and returns a UniversalProcPtr that you use instead of
the ProcPtr.
• MacApp 2 uses old and obsolete Toolbox names extensively. The PowerPC
runtime architecture uses shared libraries (code fragments) that implement
newer, more consistent names for Toolbox calls. Because Toolbox calls are
resolved by name, the new Toolbox names must be used. In addition, the Pascal
QuickDraw globals thePort, gray, etc., now reference the qd global (e.g.,
qd.thePort), as it is in C.
• Developers have relied on unsupported extensions that also needed to be ported.
These extensions include Model Far, floating windows, tear-off menus, and
synchronized scrolling.
• Finally, adding support for PowerPC Object Pascal compilers and IDEs was a
prerequisite. The build process needed to be revamped to support the latest
development environments and tools, and the documentation had to be revised.
This sounds a bit daunting. Frankly, when I announced the MacApp2PPC
developer’s cooperative, I didn’t have the foggiest idea whether or how we were going
to succeed. However, I did know a little bit about what needed to get done and I called