How Disk Copy Handled Disk Images in Mac OS 9

In Mac OS 9, Apple’s Disk Copy utility created and mounted virtual disk images by directly capturing raw volume sectors and interfacing with the classic Mac OS Device Manager. Rather than treating disk images as simple archive files, Disk Copy used specialized low-level disk drivers to expose these image files as legitimate block devices to the system. This allowed users to generate floppy and hard drive images—primarily in Disk Copy 4.2 and New Disk Image Format (NDIF) specifications—and mount them directly onto the Finder desktop as if they were physical disks.

Image Formats Used in Mac OS 9

Before the modern Apple Disk Image (.dmg / UDIF) format arrived in Mac OS X, Mac OS 9 relied on two primary format standards handled by Disk Copy:

  • Disk Copy 4.2: Originally built for floppy disks, this format included an 84-byte header followed by raw disk sectors and 12 bytes of floppy disk tag data per sector. It was strictly uncompressed and limited in size.
  • NDIF (New Disk Image Format): Introduced with Disk Copy 6.0, NDIF was the direct architectural precursor to Mac OS X’s DMG. NDIF supported read/write raw images, read-only compressed images (using ADC or zlib compression), self-mounting images (.smi), and volumes much larger than floppies.

How Disk Images Were Created

When creating an image from a physical volume or floppy, Disk Copy bypassed standard high-level file system calls. It queried the physical drive via the Device Manager and the SCSI or ATA Manager to read raw blocks sequentially.

For creating images from existing folders:

  1. Disk Copy calculated the total file size and directory structure overhead required.
  2. It allocated a container file on the host volume, writing a partition map and an empty HFS (Hierarchical File System) or HFS+ file system header.
  3. It copied the requested files into the virtual structure and optionally compressed the data blocks using run-length or dictionary-based encoding if a compressed format was selected.
  4. Finally, it calculated a checksum, appended it to the file structure, and tagged the file with the Mac OS Type code dImg and Creator code dCpy so the system recognized it automatically.

How Disk Images Were Mounted

Classic Mac OS lacked the dynamic virtual file system layer found in modern Unix-based operating systems. To mount an image, Disk Copy implemented a virtual block device driver:

  1. Extension Loading: Disk Copy installed a specialized driver into system memory (or relied on the bundled "Disk Copy Extension").
  2. Drive Queue Registration: When a user double-clicked an image, Disk Copy read the header metadata, validated checksums, and allocated a drive entry in the system’s Drive Queue using the Device Manager API.
  3. Sector Redirection: The File Manager recognized the new drive number and attempted to mount it. Whenever the Mac OS 9 File Manager issued standard read or write requests (_Read or _Write PB calls) to this new drive ID, the Disk Copy driver intercepted them.
  4. Translation and Decompression: If the image was raw (uncompressed), the driver simply translated the requested sector offset into a file offset within the host disk file. If the image was compressed, the driver decompressed sectors into a RAM buffer on the fly before passing the requested data back to the File Manager.
  5. Desktop Display: Once the driver successfully returned the volume's superblock and master directory block (MDB), the Finder accepted the virtual media and drew the drive icon on the desktop, allowing standard file access.