Through my technical work and experience with preservation projects [4], I feel that I have a good grasp of migration as a digital preservation strategy. Unfortunately, I have much less functional experience with emulation as a digital preservation strategy. The concept of running a virtual machine within the physical resources of another is intuitive enough, but I have as yet had no real experience with a full emulation environment. Recently I thought about recovering some classic-era Macintosh files that I have had in storage and figured that their recovery could make for an excellent hands-on emulation experience.
I used Macintosh computers from their introduction in 1984 until 1998. My last Mac was a 16 Mhz 78030 machine with 8 Mb RAM, and 80 Mb of hard drive space running OS 7.5. Before disposing of the machine in 2005 (donating it to Goodwill), I copied the entire contents of the hard drive – system software, applications, and all – to a 100 Mb ZIP disc. Simply using one of the several Mac to Windows utilities would suffice for recovering many of the documents that are cross-platform (images, raw text, etc.) or that could be migrated (Microsoft Word, Excel, etc.), but there are some documents that might be better off using the original application environment to make the conversion to a cross-platform format.
A number of programs were discovered during my initial search for Mac emulators, including Softmac [5], PearPC [6], vMac [7], Shapeshifter [8], Executor [9], and Basilisk II [10]. These programs run the spectrum from proprietary to open source, the different types of hardware environments emulated, and the platforms that the software will run on. Additionally, many of these programs have not been maintained in some years. For my experiment, I chose the Windows port of Basilisk II [11] since it met my basic criteria of a free, open source program that is still somewhat current.
The basic concept behind emulators is that they provide hardware encapsulation and interfaces to allow an operating system (OS) to run in a non-native environment. The system requirements for these emulators is quite unassuming for current computing hardware, however there are some extra software requirements that are somewhat peculiar. In many of the programs mentioned above, a copy of the Mac ROM BIOS is required to run the emulator at all, and in every case, a complete copy of the emulated OS is required in order to run software within the emulator.
The ROM BIOS is a physical chip present in the Macintosh hardware that contains the basic machine instructions used by the OS, which is considered by Apple to be proprietary code. The emulators avoid copyright infringement by requiring the user to provide a copy of the ROM rather than embed one into the software, thus violating Apple's intellectual property rights. The ROM can be obtained legally in one of two ways: extract the ROM BIOS from a functional Mac of the correct vintage for the OS version to be emulated; or, purchase a ROM card with an actual Macintosh ROM chip from a commercial vendor. The preservation-minded among us can already see issues for future emulation efforts. Incidentally, the Copyright Office has allowed exceptions to copyright [12] and anti-circumvention provisions of the Digital Millenium Copyright Act (DMCA) in certain circumstances for archives and libraries which would seem to include this very situation. (The exception will be in force until October 2009, at which time it will have to be renewed... would it not be nice to have a permanent exception?)
As for having a copy of the OS, there are also two ways to get a copy: 1) have an existing system disc or copy of a system folder; or 2) get a disc image from another source. Apple still has some older system software disc images, installers, upgraders and the like for download, and it is pretty easy to find pre-made Mac system disc images for emulators out on the net. Fortunately, I already have a system copy on my ZIP disc which will run so long as the emulation environment is of a vintage that supports the OS.
The only issue is how to copy the contents of the HFS formatted [13] ZIP disc, using Windows, to a place where the emulator can access it. There are two steps to this: 1) creating an HFS volume within the Windows filesystem, and 2) accurately copying the contents of the original HFS media to the new volume, preserving all OS-specific aspects of the data. For Macs, this means preserving both the resource and data forks of the files. (see the Joyce project report [4] for more on Mac files and HFS)
Basilisk II uses disk volume images, called hardfiles (file extension: HFV), to simulate an HFS volume within the emulator. The Windows GUI interface (and presumably the command line tools for the non-Windows versions of Basilisk) can create a raw hardfile, but cannot copy anything into it. Fortunately there is a free program for Windows called HFVExplorer [14] that can create HFV files and view or manage their contents by copying to or from Windows volumes or other HFS volumes that are accessible to Windows (including CD-ROMs, floppy, SCSI, removables, etc.).
Unfortunately, HFVExplorer would not mount my ZIP drive – using either parallel port or USB model. I would have to guess that because the program has not been updated since 1999 – before Windows 2000/XP – that the program was unable to correctly access the removable media. It is possible that HFVExplorer running on Windows 98 or NT would not encounter this problem, but I am not about to revert to either of those operating systems. Besides, having to use an older operating system in order to get an emulator to work runs counter to common sense.
Unable to rectify the issue, I tracked down a copy of HFSUtils [15] (Windows port [16]), which is the utility package that HFVExplorer was originally based upon. HFSUtils is a set of command line tools that provide basic file management tasks for mounting and manipulating HFS volumes. I mounted the ZIP volume and moved around using the command line with ease. Copying was laborious, however, because the hcopy program could not recursively copy nested directories. Ideally I would have modified the source to do this, or created a script to use HFSUtils, but then I might as well figure out how to fix HFVExplorer.
In order to move the experiment along, I proceeded by copying the directories and files individually using hcopy at the command line; the most banal of tasks, to be sure, but quite effective. I copied files from the HFS ZIP to a location on my Windows hard drive, then used HFVExplorer to copy the files into an HFV volume file.
Aside from the lack of a recursive directory copy, there were some other annoying problems. Firstly, any characters in the source filenames with characters outside of the standard ASCII range (above number 127) had translation issues. The problems came from trademark symbols, em dashes, and other special characters used in directory and filenames in Mac OS. When the command line utility rendered these characters in a file list, they appeared as question marks by default. Even when using some of the program options for hls (the file listing utility), the characters still did not display correctly in the Windows character set. Attempts to copy files with special characters failed since the DOS command line sent the translated character to the command. As an aside, it is possible to access HFS nodes (directories and files) by their node ID (or node specification pair [17]), but unfortunately, hcopy exposed no means to exploit this feature.
I noticed a second issue that relates to the file metadata, specifically the creation and modification dates for the files copied from the HFS source to the Windows volume. The copies on the Windows volume showed creation and modification dates as the date of the copy operation and not the original dates. Fortunately, the files retained their resource forks during the transfer to the emulation environment, meaning that they had all of the file metadata intact with the original dates. I'm already well aware of inconsistencies in file dates [18] from platform to platform, but it would be ideal from a preservation perspective if the hcopy routine were to access the file metadata in the HFS source and set the correct creation date for the Windows copies.
Incidentally, there are other programs available for copying HFS volume data to Windows: MacDrive [19] and TransMac [20]. Each of these are commercial software, but free demos are sometimes available On a whim I tried a demo version of TransMac, which copied the source files just fine, but I found out upon transferring the files to the HFV volume that the binary (program) files were converted in such a way that they would not function in the emulation environment. Unless I missed something in my attempt, this issue would effectively prevent emulation using files copied using these programs.
With all of the emulator software in place and a testbed of data from the original ZIP disk copied into an HFV volume file, I could test the emulator. The Basilisk GUI program in Windows allows you to define a set of disk or volume images that will be loaded at startup. This is the equivalent of having hard drives installed or discs inserted at boot time. For an initial test, I downloaded and used a bare system 7.0 system disc image. It worked flawlessly on the first try, providing me with a visceral demonstration of the difference between 16 Mhz and 1 Ghz processor speeds – my 1997 self would have been dazzled.
[21]Basilisk II GUI: Selecting volumes at startup
After fixing a directory hierarchy issue with my copied volume (the system folder was not at the root level on the hard drive image), I relaunched the emulator which resulted in an almost perfect reproduction of the mac desktop I last viewed in 2005.
[22]Basilisk II: Running Mac OS 7.5 in Windows 2000
Next step: resolve the transfer issues to try and establish a full, unmodified copy of the HFS source ZIP disk into the HFV volume file. Ideally, an unfettered copy should work flawlessly for all programs, assuming that the emulator is complete. If that is the case, then I will finally be able to access the last remaining documents that I need to convert within the original application environment.
