Porting SSA Detailed Calculator to Xcode/Intel: Part 1

For the first post in this series, see Porting SSA Detailed Calculator to Xcode/Intel: Intro

Part 1: Compile the existing project and import into a Git repo

As always with an existing software project, the first step is to get the code to compile. I used my 17” PowerBook G4, running OS X 10.4 (since it’s the newest OS X version supported by CodeWarrior 9).

The existing source code can be downloaded from the SSA. Since the files are distributed in .sitx archives, StuffIt Expander is needed to expand them. In addition, the project uses Boost 1.33.1 (which I believe was the last version that supported CodeWarrior). All these directories need to be put next to each other, like:

With that done, open the CodeWarrior project. I used CodeWarrior 9 since the project files were saved by that version, but I believe CW10 would also work. (You can find a copy of CW9 at the Internet’s favorite botany-themed Mac abandonware site 😛). Note that CodeWarrior 9 needs the latest 9.6 update installed to work correctly on OS X 10.4. Open the project file (anypiamacprojOSX/anypiamac.mcp) and the project window should appear:

Now it’s time to try compiling. Click the green arrow on the top bar (2nd from the right), and it should start building:

10 million lines later, CodeWarrior had a single compile error for me:

The error is actually in Boost: a class that isn’t defined (date_time::microsec_clock) is being typedef’d. The fix is easy, put an #ifdef for BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK around the typedef (this is the same #ifdef that’s around the date_time::microsec_clock class definition):

With that fixed, I ran the project again and it was successful!

A full build takes 13 minutes on my 1.5 GHz PowerBook G4, I suppose not bad for a single-core computer compiling hundreds of files. Keep that time in mind when we port the project to Xcode later on.

With the existing source code proven, my next step was to import it into a Git repository.

OS X 10.4 doesn’t include git (understandable for an OS released in 2004), but the excellent Tigerbrew project is a PPC Tiger-compatible fork of Homebrew, and includes formulas for the latest git version.

So this should be easy, right? Just install git, add the files, and push to github. Unfortunately, Mac resource forks make this more tricky. Dealing with resource forks is a distant memory for current Mac programmers, but code this old means that resource forks will be involved.

git has no support for resource forks: they aren’t stored in the repository, so the resource fork is effectively stripped off. Luckily, most of the files are just plain text C/C++ source code which shouldn’t need resource forks. The oactobjs folder consists entirely of text files, and I was surprised to see that so many had resource forks:

Note: since 10.4, the preferred way to access the resource fork of a file through BSD/UNIX APIs is by accessing file/..namedfork/rsrc

These are text files with resource forks. Huh? I opened one in a resource editor (Rezilla is a free one that’s OS X native) to investigate:

There are only two resources, neither one containing much data. After seeing ‘Monaco’ (the classic Mac monospaced font), I believe these are just editor settings (maybe window position, font, etc) from CodeWarrior. These resources can be stripped off without a problem.

However, the other source folder (anypiamacprojOSX) contains the project files, resources, and more source files:

After checking those files, I found two which have meaningful data in the resource fork: AppResources.ppob and AppResources.rsrc.

Some solution will be necessary to ensure that these files still work correctly after having their resource forks stripped off.

• AppResources.ppob is the PowerPlant resource file, created using Constructor. Luckily, Constructor has an option to “Save as flattened resource file” which puts everything in the data fork. I resaved AppResources.ppob using that option, and the new ppob file doesn’t even have a resource fork.

• AppResources.rsrc contains all the app’s resources (icons, etc.) and would be edited using something like Rezilla or ResEdit. Luckily, Apple already has a flattened format for resource files, and the Rez and DeRez command-line tools are used to compile/decompile to/from the flattened format. I used DeRez to convert AppResources.rsrc, and then replaced AppResources.rsrc in the CodeWarrior project with AppResources.rsrc.r.

With those files fixed, I was able to git add all the files and push to my repository.

Next post: Building a Mach-O binary with CodeWarrior