Earlier this year, I wrote about how I rescued a special recovery partition from an old Macintosh Performa 550’s dead hard drive. This partition had been lost to time and it was a race to try to save it before the remaining Performa 550 machines out there with their original hard drives were reformatted or destroyed. It has now been preserved on the Macintosh Garden. I have a few updates to that post that I’d like to share.
The first update is that some extra discussion took place in the comments of my original post. Reader “Greg” pointed out that there was an Apple employee named John Yen who worked on the Mac OS during the System 7 era, and suggested he might be the “jy” in the associated “msjy” creator code. That would leave “ms” potentially being Microseeds, which is the company that developed Apple Backup.
This led me to search further, and I stumbled upon Apple’s patent for the automatic OS recovery functionality filed in 1994. It was granted in 2002 and expired in 2019. John Yen is listed as the inventor. The patent contains some screenshots of the exact UI that I experienced while testing the functionality. I never thought to look through patents, but I should have. They are definitely a useful tool for historical research on this type of stuff. I thought that was a really cool discovery. Thanks, Greg!
Now, onto the second thing. After my research had seemingly concluded, I never turned off my eBay alerts. Last week, I received a notification about a damaged tray-loading Performa 550 (manufacture date February 1994) being parted out. Sure enough, one of the seller’s auctions was a working 160 MB hard drive from the same machine. Of course, I couldn’t resist snatching it up.
As soon as it arrived, I dumped all the contents. I was in for a very pleasant surprise: this hard drive also had the invisible recovery partition intact!
Better yet, unlike the last one, it still had all of the original Performa software, including Apple Backup, sitting in the Applications folder.
At one point during my initial search, I was really concerned that I might never find the lost recovery partition. Now everything has changed, and I’m pleased to be able to say I found it twice!
This second hard drive is a huge discovery because I now have two data points, which has led me to gain a little more confidence about how I think the special recovery partition was created in the first place. You may recall from my previous post that Apple’s own tech notes said that Apple Backup was responsible for creating it, but I was never able to find any evidence supporting that claim. Unfortunately, the original owner had deleted Apple Backup from the first hard drive before I got my hands on it, so I couldn’t draw any conclusions.
This new-to-me hard drive was exciting because Apple Backup had not been deleted! I was half expecting to find a weird unpreserved version of Apple Backup hanging around on it, but nope. It’s just the same version 1.2 from System 7.1P6 that I had already looked at in depth, right down to the creation/modification dates and the exact number of bytes used.
The hidden partition’s contents are exactly the same as what I found on the first hard drive. The file sizes are all precisely the same, and the icons are positioned identically too. That solves one mystery: the weird icon positions inside the invisible partition were not something the original owner caused. They were just weird on all machines.
The only difference I found is that the creation and modification dates of the files are slightly different between the two drives. The easiest place to show this is in the Get Info window of the partition. On the left is the first hard drive, and on the right is the second hard drive.
You can see that the exact same number of bytes have been used, but the partition on the second hard drive was created about 21 hours later. Also, it appears that on both machines, it took about 4-5 minutes to finish populating it.
One of the things I called out in my first post on this subject was that the System file strangely had a modification date several months later. It turns out that something similar happened with the second hard drive, but it ended up being a date way back in the past — the August 27, 1956 date that some Macs default to if the PRAM battery goes bad. Again, hard drive #1 on the left and hard drive #2 on the right:
I still don’t have a great explanation for why the System file’s modification date changed on both of these partitions. Maybe a third-party utility or installer happened to tweak the modification date at some point. In my earlier post, I had suggested that the At Ease ‘INIT’ resource being missing from the System file could have potentially explained the modification date change, but that resource was also missing from the second hard drive’s recovery partition System file. Plus, At Ease had not been uninstalled from the second machine. So that blows that theory out of the water. Clearly, the At Ease INIT was never part of the recovery partition’s System file.
One other interesting thing I found was that the main Hard Disk volume had the exact same creation date on both drives:
Obviously, I would love to be given the opportunity to analyze a third hard drive in the future to gain even more confidence. With all that in mind, I think I’m much closer to being able to reach a conclusion today:
I still can’t be 100% sure, but I think this latest hard drive analysis hammers the final nail in the coffin to the theory that the partition was created based on an action the user performed. I now believe the recovery partition was added by Apple in the factory, and the technote was just wrong about Apple Backup being involved. I can’t find any code in Apple Backup that does it, and this second hard drive gives me a good reason to doubt that a customized Performa-550-specific Apple Backup version is hiding out there in the wild somewhere.
I’m still weirded out by the other initials in the creator code being “MS” given that Microseeds developed Apple Backup, but all signs are pointing to this being a factory-programmed thing. I think that makes the most sense anyway. If you’re Apple and you’ve developed this functionality, why would you only enable it after the user has bought a zillion floppy disks and manually performed a backup? Why not just give it to everyone and allow them all to benefit from it?
The fact that the creation date of the recovery partition was not exactly the same between the two hard drives, but it was still within less than a day, is fascinating to me. This means the recovery partition wasn’t simply imaged onto every machine at a block level, or the dates would have been exactly the same on every machine. Maybe one of the operations performed at the factory during testing was to run a script that created the partition? This would explain why the creation date of the recovery volume was slightly different between the machines.
Another data point in favor of this theory comes from a recently-preserved Apple Restoration CD: Market Software Series Volume 1 from March 1994. It has a bunch of factory Performa software bundles. I found a quick comment about “action atoms” for a backup partition not being included in the configuration that goes with the ultra-rare Performa 560 Money Magazine Edition:
I suspect it’s referring to the recovery partition, and it’s implying that Apple did have some kind of restore/imaging script that created it, and they specifically chose not to put it into this configuration.
Unfortunately, the Performa 550 recovery image on this same CD doesn’t mention anything about the recovery partition, and doesn’t create it. It’s also directed to be used for several other Performa models, so I don’t think Apple intended for this recovery CD to comprehensively restore a machine to the exact state it was in when it left the factory. It was just meant to restore it to something operable that was close enough.
With all that out of the way, there’s one last update I want to talk about. In the first post, I mentioned that Apple published another tech note describing a bug where an educational Dinosaur Safari CD game would accidentally cause the machine to jump into recovery mode. I went so far as to buy the game, reproduce the problem, and post a video demonstrating it.
Looks like Creative Multimedia Corporation beat Apple to the punch at having a Mac app named Safari by almost a decade!
Several people were interested in learning more about why Dinosaur Safari did this. What would even cause an app launched from a CD to trigger the system to enter recovery mode? It’s definitely an odd bug, and worthy of a little more investigation.
I spent a little bit of time in MAME tracing what the game did leading up to the machine deciding to reboot. After looking through some CPU execution logs, I found that it was happening in the middle of InitResources(). When I mentioned this in #mac68k on Libera, Josh Juran quickly explained to me that apps aren’t supposed to call InitResources() in the first place. Inside Macintosh Volume I confirms this:
So that’s the problem. The app is calling a system function that it’s not supposed to, which results in the re-initialization of a bunch of system stuff, and somehow this causes the Mac to reboot into recovery mode. Strangely, the problem only happens if the app runs directly from the CD. It doesn’t happen if you copy it to your hard drive and launch it from there. Weird. Here’s the relevant part of the code as viewed in ResEdit:
It’s alongside a bunch of other standard toolbox initialization routines that are often called early during a classic Mac app’s lifetime. The developers of Dinosaur Safari inadvertently added a call to InitResources(). It’s kind of funny how it’s sitting there near the top of Apple’s public Resources.h header file, even though it’s not supposed to be called by programs. It’s almost like they were just daring someone to do it.
Anyway, to test this theory, I patched the CD to replace the InitResources trap instruction with a nop instead:
Using this modified CD, Dinosaur Safari runs perfectly fine and doesn’t activate the recovery partition.
I decided not to dive deeper and figure out the underlying sequence of events that leads to the reboot. It would be way too much reverse engineering work inside the bowels of the classic Mac OS for very little payoff. This experience might be a good clue about why Apple didn’t go forward with this functionality. I’d be shocked if Dinosaur Safari was the only program with this bug. Maybe it was too easy to inadvertently jump to recovery mode and confuse users.
This should be the end of my investigation into the Performa 550 recovery partition functionality, unless I happen to stumble upon a third hard drive in the future that radically changes my understanding of everything.
My blog isn’t turning solely into an Apple archaeology project, so if you’re not interested in old Mac stuff, never despair. I’ll write about lots of other fun stuff too. But as a forewarning, I do have another upcoming post about more obscure Apple software from the ’90s that was lost and is now found. This time, it was something that I doubt too many people even remembered existing. It’ll be a nice little blast to the past.
