MacApp2PPC Developers' Cooperative
Scott Vorthmann, MacApp2PPC Developer

MacApp2PPC Developers' Cooperative

Page Contents

  1. Overview and History
  2. Status of MacApp2PPC Carbonization
  3. Cutting Corners
  4. What Changed, Lessons Learned
  5. Building MacApp2PPC Sample Code
  6. Things To Do
  7. About Me

Overview and History

MacApp2PPC is an Object Pascal framework for developing Macintosh applications. It started life at Apple, but almost a decade ago Apple switched MacApp development over to C++. Soon thereafter, when Apple made the switch to PowerPC, developers still using the old Pascal MacApp 2.0 were out in the cold. At that time, a group of such developers came together to port MacApp to PowerPC. The result was called MacApp2PPC.

Active maintenance of the framework continued for a few years, then essentially halted in mid-1998. Since then, there have only been the occasional queries of "anyone want to Carbonize?" appearing on the mailing list.

At the start of 2000 I brought the framework up-to-date with respect to the latest Universal Interfaces from Apple, in hopes of springboarding into a Carbonization effort. However, nothing else was done until recently (August 2001), when I finally decided to attempt the Carbonization. The effort has been somewhat tedious, but in the end, not as bad as I had expected.

History on MacApp2PPC from prior years can be found at the
MacApp2PPC archive.

Status of MacApp2PPC Carbonization

At time of this writing, MacApp2PPC is Carbonized to the point where the "DrawShapes" sample application runs natively on Mac OS X, and performs its tasks with only a few bugs. Here is the list of those I know of:

MacApp2PPC framework problems

1. Command keys cause crash
The problem is easy enough to see in the CodeWarrior debugger... I just haven't looked into fixing it.

2. Printing is disabled
One of the shortcuts I took. Search for PRINTING_NOT_PORTED.

Unresolved problems (may be in the framework or in the sample app)

DrawShapes bugs

1. Color menu does not work right
Carbon appearance won't let us color the menu items, and I haven't attempted to create some other kind of color table resource.

Cutting Corners

To sustain my interest, I had to get running code as quickly as possible. To that end, I cut a number of corners:

  1. I made only a cursory attempt at porting the printing code, before I decided that was a feature I could easily work around. Look for the PRINTING_NOT_PORTED compile-time variable.
  2. I made no real attempt at consistent or coherent style. Also, I made no real effort at factoring out common idioms for reuse. I would have benefited from the sample Carbon Pascal Units at Pascal Central if I had found them sooner.
  3. About halfway through the effort, I lost patience with my original resolve to put all changes inside of {$IFC} conditionals. I wanted to end up with code that would compile and run for everything from 68K InterfaceLib to OS X Carbon, but it was simply too much. It compiles, links, and runs for Carbon... more I cannot say.

What Changed, Lessons Learned

The bulk of the effort was the typical Carbonization work of replacing access to opaque toolbox structures in Quickdraw and the Window, Menu, and Control Managers. One thing I learned a little too late: GetWindowRegion and GetPort*Region do NOT return a Handle, they simply fill in a Handle you give them.

Carbon accessor function signatures are designed for use in C/C++. Too many of them fill in a VAR parameter AND return a pointer to a structure, and I began to wish I could "ignore" a function return in Pascal like in C. If you're doing any Pascal Carbonization, for pity's sake grab some of the convenience code from
Pascal Central.

While I still had my resolve regarding backward compatibility and conditional compilation, I did make a bunch of changes that switch on when NO_WORKING_DIRECTORIES is set to true. This set of changes probably has the most profound impact on application-specific extensions to MacApp2PPC, since they impacted all of the file and directory code.

Building MacApp2PPC Sample Code

I am providing a CW Pro 4 project file and the MacApp2PPC source (see download links below). Note that the project won't work "out of the box" because the access path for Universal Interfaces 3.4 is outside of the CodeWarrior directory hierarchy. Be sure to look at the MacApp.Carbon.prefix file.

Download the CodeWarrior Pro 4 project:
MacApp.Pro4.mcp.bin (Updated 10/3/01)
Download MacApp2PPC source:
MacApp2Carbon.bin (Updated 10/3/01)

A few notes on the build:

  1. The CW Pro 4 project requires the PostRez post-linker plugin. I don't think the plugin works with CW Pro 6 and 7, in which case I use a separate MPW step... the PostRez MPW tool is in the Tools folder already. Use it on the executable built by CW, to change 'cmnu' resources into MENU resources, etc.

    UPDATE: I've discovered that I cannot build with Pro 4 anymore, apparently since installing Pro 7. I get a crash on completion of the build. I'll add another note with my exact build setup soon. Use the MPW PostRez for now.

  2. The Pro 4 project also claims to require a plugin called Script Executor. This is not true. You can resolve that issue as follows: go to the File Mappings preference pane, then "change" and "remove" the line (usually last) that refers to Script Executor. (You won't be able to "remove" directly.)

  3. I can only debug on OS X using CW Pro 7, although the app and .xSYM file can be built by CW Pro 4. Debugging under CW Pro 6 may be possible too, but I have not been able to.

Things To Do

I think the highest priority items are as follows, in no particular order:

  1. Resolve the command-key problem.
  2. Port the printing code.
  3. do the navigation services dialogs right.
  4. Document my exact build environment and steps.
  5. Post the CW Pro 6.3 project I use to build.

I did not mention #3 in Cutting Corners, but I definitely cut one there.

On a longer term, we need to have a fully scripted, reproducible build process, preferably with easy bootstrapping. Any CW scripting experts out there?

In order to avoid duplication of effort, I suggest that anyone attempting to fix an issue should post your intention to the
MacApp2PPC list.

Please, feel free to "step forward" with opinions, suggestions, complaints, whatever. Post your thoughts on the
MacApp2PPC mailing list.

About Me

I am working on MacApp2PPC because I have a body of legacy code that I cannot afford to port to C++ or Java, naturally. Furthermore, that legacy code is for the one application that I cannot do without... a language-sensitive editor for Java, called SpotCheck. My secret identity is CTO of GenieWorks, LLC, and the author of SpotCheck. My public identity is Senior Architect with an enterprise software company, designing and building XML software in Java.

Back to Contents

Copyleft © 2001 Scott Vorthmann. Share and share alike.