Intel-based Macs, Classic, and HyperCard

Ever since the Intel-based Macs were announced, there was concern about whether those new machines would be able to run old, pre-Mac OS X software. Now the first Intel-based iMacs are shipping, and this concern has shifted from theoretical to real.

The problem is that Apple is not supporting the Classic environment on Intel-based Macs. This essentially means, [as Jorg Brown put it](a href=”, that

…no Mac program written prior to 1999 will run - at all - on the new Intel-based Macs. In fact, most 2001 programs won’t either. (By contrast, many 1984 apps do run on today’s machines.)

Well, this isn’t good. I’ve used Macs since 1984, so I have a huge archive of files that I want to be able to continue to access. But in my case it’s an archive, not stuff I’m using every day, so it’s not a big deal to keep an older machine around just to access those files.

But it’s a different story if you have software you rely on every day that was never ported to OS X. For example, HyperCard stacks. HyperCard stacks were fairly unique because they contained both data and programming code. HyperCard stacks were also very popular in educational settings because it provided a fairly easy way to design and create custom software. For its time, HyperCard enabled a great deal of innovation within the educational technology community.

Porting a stack from HyperCard to something else wasn’t simply a matter of exporting the data; someone also had to reengineer the stack’s HyperTalk source code by hand. That made the process more expensive and explains why a lot of HyperCard stacks are still in use.

People who had the time and money probably moved away from HyperCard years ago. SuperCard eased the migration to OS X, and MetaCard (later Runtime Revolution) even supported limited porting of HyperCard stacks to Windows and Unix. In fact, Runtime Revolution has been suggested as a migration path for HyperCard users who want a new Intel-based Mac.

In some cases, that may work, but there’s one caveat. Many HyperCard stacks relied on small compiled plugins called XCMDs that handled certain tasks that HyperTalk could not. There were several freely available XCMD libraries, including the Dartmouth XCMDs, Frederic Rinaldi’s XCMDs, a set from Apple Developers, and others. Anyway, the ease with which one could grab these XCMD librarie and integrate them into their own stacks meant that a lot of stacks depended on these XCMDs. And here’s the problem: virtually all of these XCMDs consist of 68k code, not PowerPC. That means that while Runtime Rev may be able to port the bulk of a HyperCard stack and run it on Intel hardware, it will not be able to port the XMCD, leaving a nice, gaping hole in the middle of the stack.

Some developers will be able to work around this limitation, but again, those folks probably moved away from HyperCard years ago. What’s really needed is a simple, bombproof way for non-developers to run those stacks (and, while I’ve been running on about HyperCard, all those other pre-1999 applications too). Something kind of like, well, the Classic environment.

There are a couple of emulation projects that look very promising for doing this. SheepShaver has the current buzz, as it basically emulates a PowerPC processor (PearPC is another open-source project emulating a PPC). Add a ROM from an older Mac and an older Mac OS (supposedly 9.0.4 is ideal) and you’re set. The installation and setup process is a bit ugly right now, but I’d expect that to improve rapidly now that it’s getting so much attention.

But for HyperCard (and actually for a lot of software that is pre-1994 or so) SheepShaver really isn’t the right solution. That’s because pre-1994 software was written for 68k CPUs, not PowerPCs. When Apple made the transition from 68k to PowerPC, it made sure to include emulation code that let the PowerPC-based Macs run 68k code — albeit slowly.

So if you use SheepShaver to run old 68k code on an Intel-based computer (Mac, Dell, whatever) what you’re doing is emulating a PowerPC chip emulating a 68k chip. You’d better believe it’s going to be slow… supposedly PowerPC-based apps run at about an eighth of the native processor speed, so 68k-based apps are going to be even slower.

That’s why I think Basilisk II is going to turn out to be a much better solution for running ancient Mac apps. Basilisk is a 68k emulator, so we’re only dealing with one level of emulation, not two. Basilisk shares some code with SheepShaver and takes a similar approach. The main difference is that Basilisk targets a 68k CPU running Mac OS 7.5/8.1, where SheepShaver targets a PowerPC running Mac OS 9.0.4.

The only case in which Basilisk won’t work is if the application you need to run is PowerPC-only. But I’d bet that most, if not all, of the software people run under Classic today is either a fat binary (PowerPC code and 68k code in one application) or a 68k-based application. (I’d welcome any counterexamples.) So while it may be counterintuitive to downgrade to the older 68k binary, doing so may actually improve performance.

Hopefully, with Basilisk and SheepShaver, we’ll be able to continue to run legacy Mac applications. In some ways, having Apple drop Classic support is a blessing, because it means these emulators, which run on Apple and non-Apple hardware, are getting more attention. Just remember to grab your old Mac’s ROM before you retire it for good!

posted February 10, 2006 by eric

View comment:

Hi, very interesting to read.

Did I understand you right - that Basilsik II works TODAY?

Have anyone tested toward old HC 68K-code?!?

Were can I get it?

Best regards
Bjarne () - 30 03 06 - 07:37

Remember personal info?

Comment:Emoticons /
Comment spam is an unfortunate problem on our site. Making you answer an Obvious Question is one way to defeat the spambots.
Obvious Question: How many states are in the United States (50)?

Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.