The Ins And Outs Of ISO 9660 And High Sierra
The Ins And Outs Of ISO 9660 And High Sierra
BRIAN BECHTEL WITH HIS DAUGHTER MEG
Any CD-ROM can be read at the bit level by any CD-ROM player, thanks to the
existence of standards for the physical format of such discs. Having this physical
format in common is nice, but it's not enough. We also need to be able to find specific
files on a CD, no matter which operating system we are using; we need a standard
file system format. High Sierra and its international equivalent ISO 9660 are
standards that define a file system usable under a variety of operating systems. This
article explores these standards and their implementation on the Macintosh, and
discusses a simple program you'll find on the accompanying Developer Essentials disc
to convert Macintosh files
to ISO 9660 format.
A file system organizes data logically on a CD. Different operating systems use different file systems
to organize data, and thus a CD formatted with a native file system can only be read by one
particular operating system. To overcome this obvious limit to the usefulness of CD-ROM as a
storage and distribution medium, the industry has established standards for a file system that can be
used under a variety of operating systems. The ISO 9660 standard and its predecessor High Sierra
define a file system carefully attuned to CD-ROM characteristics.
In particular, because CDs have a relatively slow seek time and a high capacity, these standards make
trade-offs that reduce the number of seeks needed to read a file, at the expense of space efficiency.
And because CDs are read-only, concerns like space allocation, file deletion, and the like are not
addressed in the standards. The standards apply only to the data track of a CD-ROM, not to audio
tracks; and they do not apply to any media other than CD-ROM, such as erasable-optical drives.
The standards do not favor any particular computer architecture. All significant multibyte numbers
are recorded twice, once with the most significant byte first (msb order, used by Intel processors
such as those in MS-DOS compatible computers) and once with the least significant byte first (lsb
order, used by Motorola microprocessors such as those in the Macintosh). This enables easy
implementation under a variety of operating systems, such as the Macintosh operating system, Apple
II ProDOS 16 or GS/OS, MS-DOS, VMS, and the UNIX operating system. Let's look now at how
the two standards developed.
ISO 9660 AND HIGH SIERRA: SOME HISTORY
A group of industry representatives met at Del Webb's High Sierra Hotel and Casino at Lake
Tahoe, Nevada, in late 1985 to see if companies could cooperate in developing a common file
system format for CD-ROM. The result of this series of meetings was the High Sierra format. This
format is fully specified by the May 28, 1986 Working Paper for Information Processing--Volume and
File Structure of Compact Read-Only Optical Discs for Information Interchange
. For obvious reasons, this
is known as the High Sierra paper.
The world at large then wanted to adopt an equivalent standard. The International Organization for
Standardization pushed High Sierra through its standardization process, resulting in the
international standard known as ISO 9660. (The organization is called the International
Organization for Standardization, but the standard is ISO 9660 .) This standard is described in the
paper ISO 9660--Volume and File Structure of CD-ROM for Information Interchange , known in the
CD-ROM trade as the ISO standard.
Apple's Macintosh operating system and GS/OS, plus Microsoft's operating system MS-DOS,
support both the ISO 9660 standard and the older High Sierra format.
ISO 9660 is the wave of the future--many existing CD-ROMs use the High Sierra format, but
everyone is changing over to the ISO 9660 standard, and most if not all future discs will be in ISO
9660 format rather than High Sierra format. In the meantime, because "ISO 9660" doesn't roll off
the tongue quite as nicely as "High Sierra," many people in the industry say "High Sierra" when
they really mean "ISO 9660" or "whatever that damn format is that my CD-ROM is supposed to be
in." In this article, I do not use the terms interchangeably, but explicitly state which format I'm
referring to. But for practical purposes, what I say about one format also applies to the other, with
the exceptions I note.
HOW THE FORMATS ARE IMPLEMENTED ON THE MACINTOSH
The Macintosh supports both ISO 9660 and High Sierra through the use of a feature in the
Macintosh file system called the external file system hook. This is a low-memory global that contains
a pointer to an external file system handler to which multiple handlers are daisy-chained. To support
ISO 9660 and High Sierra, Apple has written a new set of routines, contained in a file called Foreign
File Access. This file, combined with the files High Sierra File Access and ISO 9660 File Access,
provides complete support for the standard formats.
Because the ISO 9660 and High Sierra formats are supported via Foreign File Access instead of
software that's part of a device driver, you can use any media to create a standard-format volume. In
actual use, ISO 9660 and High Sierra only make sense on a CD-ROM; but you can create a test
volume using any floppy or hard disk.
A LOOK AT THE FORMATSThe ISO 9660 standard and the older High Sierra format define each CD-ROM
as a volume. Volumes can contain standard file structures, coded character set file structures for
character encoding other than ASCII, or boot records. Boot records can contain either data or
program code that may be needed by systems or applications.
ISO 9660 and High Sierra specify
- how to describe an arbitrary location on the volume--the logical format of the
- how to format and what to include in the descriptive information contained by
each volume about itself--the volume descriptors;
- how to format and what to include in the path table, which is an easy way to get
to any directory on the volume;
- how to format and what to include in the file directories and the directory records,
which contain basic information about the files on the volume such as the filename,
file size, file location, and so forth.
The discussion that follows is a reasonably technical description of the standards in each of these
areas; it is not the definitive description. For the one true, proper definition of the standards, read
the original specifications.
THE LOGICAL FORMAT
CD-ROMs are laid out in 2048-byte physical sectors. This physical layout is defined in a standard
published by Philips and Sony known as the Yellow Book, and is independent of the type of volume
formatting used. Under ISO 9660 and High Sierra, the CD is also laid out in 2048-byte logical
sectors. Both formats also have the concept of a logical block, which is the smallest chunk of file data.
A logical block can be 512, 1024, or 2048 bytes. In general, file access information is laid out in
sector-sized units, while actual file data is laid out in block-sized units. On most CDs, the block size is
the same as the sector size at 2048 bytes, so this distinction isn't important. Figure 1 shows the layout
of a volume in ISO 9660 or High Sierra format.
Figure 1 A Volume in ISO 9660 or High Sierra Format
THE VOLUME DESCRIPTORS
Information about the volume itself is contained in an array of 2048-byte entries, beginning at
logical sector 16 on the disc, as shown in Figure 1. These are the volume descriptors. There are five
types of volume descriptors: the primary volume descriptor, the secondary volume descriptor, the
boot descriptor, the partition descriptor, and the volume descriptor terminator. Every volume
descriptor is 2048 bytes long (one sector). The first descriptor in the array is always a primary
volume descriptor, and the last descriptor always a volume descriptor terminator. The other three
volume descriptor types are optional. The boot descriptor and the partition descriptor aren't
supported by the Macintosh, because the Macintosh boot code looks at the beginning of the disk for
boot tracks, not at sector 16.
Each volume has one and only one primary volume descriptor. This descriptor consists of the volume
name, some publishing information, and offsets to the path table and root directory. The primary
volume descriptor also contains a copy of the root directory entry (to minimize the number of seeks
necessary to find out information about a disc). In the directory structure pointed to by the primary
volume descriptor, filenames can consist of the uppercase characters A through Z, the underscore,
and the digits 0 through 9. This is a subset of ISO 646, an international character representation
standard roughly equivalent to ASCII. You will see a sample primary volume descriptor later in this
article in the section entitled "A Simple Formatting Program: ISO 9660 Floppy Builder."
A volume can have zero or more secondary volume descriptors . The purpose of the secondary volume
descriptor is to enable you to press a CD-ROM that can display the directories in a nonroman
character set, such as Japanese Kanji, Hebrew, or Arabic. In the directory structure pointed to by the
secondary volume descriptor, the characters used to represent filenames are not restricted to ISO
646. This directory structure is separate from but parallel to the directory structure pointed to by
the primary volume descriptor. The secondary volume descriptor contains the same information as
the primary volume descriptor--although in a different alphabet--in all but two fields. The
volumeFlag field is used to indicate whether a non-ISO-standard alphabet is being used. The
escapeSequences field contains characters that define which alphabet is being used.
The files ISO 9660 File Access and High Sierra File Access each contain a resource used to
determine if the Macintosh should use a secondary volume descriptor. The NRVD resource contains
a word for the
volumeFlags field, followed by 32 bytes for the
escapeSequences field. If a
secondary volume descriptor exists, and if the volume flags and escape sequences match those in the
NRVD resource, then the secondary volume descriptor is used instead of the primary volume
The boot descriptor was designed to allow the creator of a CD-ROM to include system information
for booting from that CD-ROM. This descriptor is not supported on the Macintosh, since the
Macintosh operating system looks for boot information at the beginning of the disk, in the area
undefined by ISO 9660 and High Sierra. The partition descriptor is also unsupported on the
The volume descriptor terminator is a simple structure that serves to indicate the end of the volume
descriptor array. Each volume contains one, and only one, volume descriptor terminator.
THE PATH TABLE
The path table describes the directory hierarchy in a compact form, containing entries for each of the
volume's directories. Its purpose is to minimize the number of seeks necessary to get to a file's
directory information. The Macintosh caches the path table in memory, enabling access to any
directory with only a single seek.
ISO 9660 allows up to two identical copies of the path table to be stored on the disc, while High
Sierra allows up to four copies. This is useful to operating systems that do not cache the path table
in memory. In this case, copies of the path table can be stored at regular intervals on the disc--say a
quarter of the way in and again three-quarters of the way in--to decrease the seek time necessary for
the optical read head to find one of the copies.
The path table for a simple formatting program is shown later in this article.
Directories are stored in a hierarchical tree. Each volume has a root directory, the parent to all other
directories on the volume. Subdirectories can be nested up to eight levels deep (the root plus seven
Directory records are the basic unit of information kept about each file. Each directory record contains
the offset from the beginning of the disc to the file itself, the size of the file, date and time
information for creation and modification, file attribute flags, information useful for interleaved files,
and the filename (preceded by a length byte). There is also an optional extension field, used by the
Macintosh and Apple II operating systems to store additional information not defined by the High
Sierra and ISO 9660 formats but necessary to the operating system. A directory record for a simple
formatting program is shown later in this article.
Additional file information necessary for multiuser operating systems such as the UNIX operating
system or VMS is retained in a separate field known as the extended attribute record. Extended
attribute records are recognized by the Macintosh, but they are ignored since they contain
information that is irrelevant to it.
A file identifier consists of a filename, a period, a file extension, a semicolon, and a file version
number. File identifiers can use the uppercase English alphabet, numbers, and the underscore
character (_), and can be up to 31 characters long. Either the filename or file extension can be
missing, but not both; if the extension
is missing, the period must still precede the semicolon; and the version number
must exist. This means that valid file identifiers look like THIS_FILE.EXISTS;1
or .ONLYEXTENSION;1 but that file identifiers like NO_PERIOD;1 or NO_VERSION are
invalid. Both standards define a level-1 conformance, designed for compatibility with MS-DOS, that
restricts filenames to eight characters, a period, three characters, a semicolon, and a version number.
There are two types of files: regular files and associated files. A regular file without an associated file
is simply a stream of bytes, like the files used in an operating system such as the UNIX ® operating
system or MS-DOS. An associated file is a file with the same name as a regular file, and with the
associated file attribute bit set in the directory record. This scheme accommodates the data and
resource forks of a Macintosh file, as we'll discuss later.
HOW THE FORMATS DIFFER
The differences between ISO 9660 and High Sierra are slight, and mostly of interest to
programmers. They are as follows:
- The primary and secondary volume descriptors differ in the type and number of
fields they accommodate.
- In ISO 9660, a bibliographic preparer field was added to the primary and
secondary volume descriptors.
- Up to four copies of the path table are allowed in High Sierra, but only two
copies in ISO 9660.
- Two fields changed position in the directory records in ISO 9660.
- All date/time fields have an extra byte in ISO 9660, used to describe the 15-
minute offset from Universal Standard Time (GMT or UTC).
- The order of directory records is slightly different in ISO 9660. In High Sierra,
the associated file comes after the regular file with which it is associated; in ISO
9660, the associated file comes first.
HOW MACINTOSH FILES ARE STORED IN THE FORMATS
The Macintosh uses a file system called the Hierarchical File System (HFS). As its name implies, it is
hierarchical in structure, like that specified by ISO 9660 and High Sierra; it supports subdirectories,
called folders, where files can be logically grouped together. HFS corresponds reasonably well to the
ISO 9660 and High Sierra formats, with some limitations. Let's look at specific parts of the
information required by the Finder and see how the ISO 9660 and High Sierra support handles these
issues. FILE FORKS
Every file in HFS has two forks: a resource fork and a data fork. The resource fork of an application
file contains the resources used by the application (for example, the bit image for an icon or the title
and commands for a menu) plus the application code. The data fork can contain anything an
application wants to store there. Similarly, a document file contains the document's resources in its
resource fork and the document's data in its data fork. In ISO 9660 and High Sierra format, the data
fork of a Macintosh file is stored as a regular file, and the resource fork is stored as an associated file.
A Macintosh application's data fork may be empty. How this should be handled is not stated clearly
in either the ISO 9660 or the High Sierra specification; however, in both cases, an associated file is
defined to exist only in conjunction with a regular file of the same name. If the regular file
(corresponding to the data fork) is missing, the Macintosh operating system handles the case
correctly; however, MS-DOS won't show the file, because the MS-DOS CD-ROM extensions
ignore files with the associated bit set. This is because all files in MS-DOS are regular files.
Like ISO 9660 and High Sierra file identifiers, HFS filenames can have a maximum of 31 characters.
HFS filenames differ from valid ISO 9660 and High Sierra file identifiers in the following ways:
- HFS does not distinguish between uppercase and lowercase letters; the names
"forecast," "Forecast," and "FoReCaSt" all refer to the same file.
- HFS allows any character to be used in a filename except the colon (:). This
means that filenames such as "My payroll file" or "Åéîøü" are perfectly acceptable
on the Macintosh.
- In HFS there is no concept of a filename extension. File types are stored as part of
the Finder information.
These differences mean that many HFS filenames are illegal in ISO 9660 or High Sierra format.
This may cause problems in an application that depends on hard-coded filenames. For example,
Hypercard requires that the home stack be named HOME, but this is illegal in ISO 9660 and High
Sierra. The legal ISO 9660 or High Sierra name is HOME.;1, which won't be found by Hypercard.
Some versions of Videoworks depend upon sounds being in a file named Sounds. The only solution
is to have the user copy such files over to an HFS volume and rename them.
FILE TYPE AND CREATOR
To establish the proper interface with the Finder, when a Macintosh application creates a file it sets
the file's creator and file type. Normally it sets the creator to its signature, which is a unique four-
letter sequence by which the Finder can identify it, such as MACA for MacWrite, XCEL for Excel,
and FNDR for Finder. It sets the file type to a four-character sequence that identifies files of that
type, such as TEXT for plain text or documents of unknown type, APPL for applications, and
WORD for MacWrite documents. When the user asks the Finder to open or print the file, the
Finder starts up the application whose signature is the file's creator and passes the file type to the
application, along with the filename and other identifying information.
This information about each file is not defined in either High Sierra or the ISO 9660 standard. To
preserve this file-specific information, Apple has defined a legitimate extension to ISO 9660 (which
also applies to High Sierra), documented in CD-ROM and the Macintosh Computer , included on the
Developer Essentials disc. The extension specifies how to use the optional
SystemUse field present
in each ISO 9660 directory record to accommodate the file type and file creator.
If a CD-ROM has been pressed in ISO 9660 or High Sierra format without the Apple extension, all
files on the disc are considered to be of type TEXT and creator hscd. TEXT is a generic type that
can be read successfully by many Macintosh applications; hscd is a creator registered with Developer
Technical Support that does not correspond to any application or utility. If the CD-ROM has been
pressed with the Apple extension, then files on the disc can have any arbitrary type and creator.
The Finder flags are defined in Technical Note #40, Finder Flags. Only the invisible bit has an
analogy in the ISO 9660 and High Sierra formats, but with the Apple extension to ISO 9660, the
SystemUse field in the directory record accommodates Finder flags. If the CD-ROM has been
pressed with the Apple extension, only bits 5 (always switch launch), 12 (system file), 13 (bundle bit),
and 15 (locked) can be used. All other bits are either ignored or set due to internal workings of the
file system translator. Flags indicating that a file is on the desktop or in the trash are not supported;
all files are assumed to be in their folders.
The Finder also requires some information describing how files on the desktop are to be viewed, the
icon to display for a specific file, the position of folders and file icons on the desktop, and the default
scroll position when the user opens a folder. This information is contained in the
DXInfo structures documented on pages IV-104 through IV-106 of Inside Macintosh .
File or folder comments are kept in the Desktop file. None of this information can be specified
when pressing a CD-ROM in ISO 9660 or High Sierra format. Some of it is computed by the ISO
9660 File Access or High Sierra File Access software, however.
Due to some deficiencies in the original design of the Finder, the correct icon cannot be displayed
for a file on an ISO 9660 or a High Sierra disc. This is because the Finder does not actually ask for
the icon of a file; rather, it assumes the existence of a desktop database that contains these mappings,
and makes a special call, giving only the file creator and type. The software to provide this
information was designed to be very HFS-specific. Currently, even if the icon bitmap for a file on an
ISO 9660 or a High Sierra disc is defined in the Apple extension, it is not used by the Finder.
Consequently, all files on a High Sierra or an ISO 9660 disc display a generic icon.
If such a file is copied to a hard disk, the correct icon is then displayed on the desktop. If the user
double-clicks on a generic application icon, the application opens correctly. If the user double-clicks on
a generic document icon, and the associated application exists only on CD-ROM and not in the
current directory, the application will not be found; if the application exists on an HFS volume
(because the user has copied it there), it will be found.
Under HFS, the Finder keeps track of the position of a file icon on the desktop or
in a folder by using a special field; under High Sierra and ISO 9660, an icon's position is computed
when the folder is opened, and cannot be changed. File and folder comments are not supported under
the ISO 9660 and High Sierra formats. The view is always assumed to be View by Icon and the scroll
position is always assumed to be at the top of the folder; these items are hard-coded in the file system
As a developer, you don't have to worry about files on an ISO 9660 or a High Sierra CD-ROM
looking different to your application. You may have to worry about filenames, if you have hard-
coded a particular filename into your application (which is always a bad idea anyway.) Except for the
icons not showing up properly (a major exception), your users don't really see a difference between
ISO 9660, High Sierra, and HFS-format CD-ROMs. Names are reported back to the Finder exactly
as found on the High Sierra or ISO 9660 volume; they are not altered in any way, except that they
are truncated at 3 1 characters if they started out longer.
STRANGE BEHAVIOR IN ISO 9660 AND HIGH SIERRA SUPPORT
Version 1 of ISO 9660 File Access and High Sierra File Access had a misfeature that slowed down
volume mounting times on CD-ROMs with a large number of files. Because neither the ISO 9660
nor the High Sierra format contains a count of the total number of files on a volume, the access
software was iterating over the volume to find this number to stuff into the volume control block.
This could make a
CD-ROM with 10,000 files on it take up to 20 minutes to mount.
It turns out that the volume control block field that was being set is used in only one place in the
Macintosh operating system: the file count of the
GetInfo of the volume. Version 2 of High
Sierra File Access and ISO 9660 File Access fixes this problem by setting the appropriate field in the
volume control block to 0. A special hard-coded comment has been added to the volume's
box that says either "The number of files shown is incorrect due to limitations of the
High Sierra format" or "The number of files shown is incorrect due to limitations of the ISO 9660
SO HOW DO I PRESS AN ISO 9660 CD-ROM?
CD-ROMs are actually pressed from an image of a disk. To press a CD-ROM in ISO 9660 or High
Sierra format, you need some premastering software that creates a disk in the appropriate format.
You can either hire a CD-ROM pressing plant to convert your files to the ISO 9660 format, or you
can purchase a system to do it yourself, or you can write your own ISO 9660 formatting software.
If you want to write your own software, you'll find a simple example program on
the Developer Essentials
disc to get you started. The program is called ISO 9660 Floppy Builder and is
written in Think C. It builds disks conforming to the ISO 9660 standard.
A SIMPLE FORMATTING PROGRAM: ISO 9660 FLOPPY BUILDER
ISO 9660 Floppy Builder has a number of features, listed below. The bracketed number after each
feature indicates the section in the formal ISO 9660 document referred to earlier that describes this
feature. You should read that section of the ISO 9660 document for more detail about each feature.
- Assumes that the logical sector size is 2048. [6.1.2]
- Assumes that the logical block size is 2048. [6.2.2]
- Writes a primary volume descriptor. [8.4]
- Writes a volume descriptor terminator. [8.3]
- Supports the Apple extensions to ISO 9660.
- Enables the user to specify a volume name. The volume name is automatically
converted to the proper character subset. [8.4.6]
- Enables the user to choose, via a standard file dialog, files to be added to the ISO
9660 disk. All files are currently put in the root directory.
- Copies both the resource fork and the data fork of a file to the disk. The resource
fork is stored as the associated file.
ISO 9660 Floppy Builder is a demonstration program; it doesn't do many of the difficult parts of
building a disk in ISO 9660 format. Specifically, it doesn't support: subdirectories (folders), keeping
the files in a directory in alphabetical order, a main directory whose total size exceeds one block of
2048 bytes, a block size other than 2048 bytes, secondary volume descriptors (used to implement
non-ASCII alphabets), or more than one logical sector of directory records.
TO USE THE PROGRAM
To use the program, start with a formatted blank floppy. We will unmount and format the disk as
part of the process of making it into an ISO 9660 format disk. All data will be lost from the floppy
Select "Specify Files for Root..." to put files into the root directory. You'll be asked for the names of
the files to be copied over via a standard file dialog. When you've finished selecting filenames, click
the Cancel button.
A CLOSER LOOK AT THE CODE
Let's look at the C structures we'll use to implement ISO 9660. We need three basic data structures:
the primary volume descriptor, the path table, and the directory record. A primary volume
descriptor has the basic data for the entire volume. It looks like this in C:
typedef unsigned char Byte;
typedef unsigned short Word;
typedef unsigned long Long;
Byte VDType; /* Must be 1 for primary volume
char VSStdId; /* Must be "CD001". */
Byte VSStdVersion; /* Must be 1. */
Byte volumeFlags; /* 0 in primary volume
char systemIdentifier; /* What system this CD-ROM is
meant for. */
char volumeIdentifier; /* The volume name. */
char Reserved2; /* Must be 0's. */
Long lsbVolumeSpaceSize; /* Volume size, least-significant
-byte order. */
Long msbVolumeSpaceSize; /* Volume size, most-significant
-byte order. */
char escapeSequences; /* 0's in primary volume
Word lsbVolumeSetSize; /* Number of volumes in volume
set (must be 1). */
Word lsbVolumeSetSequenceNumber;/* Which volume in volume set
(not used). */
Word lsbLogicalBlockSize; /* We'll assume 2048 for block
Long lsbPathTableSize; /* How many bytes in path
Long lsbPathTable1; /* Mandatory occurrence. */
Long lsbPathTable2; /* Optional occurrence. */
Long msbPathTable1; /* Mandatory occurrence. */
Long msbPathTable2; /* Optional occurrence. */
char rootDirectoryRecord; /* Duplicate root
directory entry. */
char volumeSetIdentifier; /* Various copyright and
control fields follow. */
char Reserved4; /* Must be 0. */
} PVD, *PVDPtr;
The path table looks like this in C:
typedef char dirIDArray;
byte len_di; /* Length of directory identifier. */
byte XARlength; /* Extended attribute record length. */
Long dirLocation; /* First logical block where directory
is stored. */
Word parentDN; /* Parent directory number. */
dirIDArray dirID; /* Directory identifier: actual length
/* len_di; there is an extra blank */
/* byte if len_di is odd. */
} PathTableRecord, *PathTableRecordPtr;
Notice that this strucure is difficult to describe in C, because C
requires that arrays of characters have a fixed size, and the character
arrays in these records are variable in size. The path table records are
packed together, so you'll see some grungy code to move a pointer
along in the variable records of the path table.
The directory record looks like this in C:
char signature; /* $41 $41 - 'AA' famous value. */
byte extensionLength; /* $0E for this ID. */
byte systemUseID; /* 02 = HFS. */
byte fileType; /* Such as 'TEXT' or 'STAK'. */
byte fileCreator; /* Such as 'hscd' or 'WILD'. */
byte len_dr; /* Directory record length. */
byte XARlength; /* Extended attribute record length. */
Long lsbStart; /* First logical block where file
Long lsbDataLength; /* Number of bytes in file. */
byte year; /* Since 1900. */
byte gmtOffset; /* 15-minute offset from Universal
byte fileFlags; /* Attributes of a file or directory. */
byte interleaveSize; /* Used for interleaved files. */
byte interleaveSkip; /* Used for interleaved files. */
Word lsbVolSetSeqNum; /* Which volume in volume set contains
this file. */
byte len_fi; /* Length of file identifier that
char fi; /* File identifier: actual is len_fi. */
/* Contains extra blank byte if len_fi odd. */
AppleExtension apple; /* This actually fits immediately after
the fi */
/* field, or after its padding byte. */
} DirRcd, *DirRcdPtr;
Again, this structure is difficult to describe in C. The directory
records are packed into 2048-byte blocks. No directory record is
allowed to span a block, so any extra bytes at the end of a directory
record block are ignored. We'll ignore such details in this simple
Our basic flow of control is simple. The core of the program is in the
file BuildISO.c. (See
CreateAVolume for the main core code.)
When we get a floppy, we check to see if it is formatted. If so, we ask
the user if he or she wants to continue (to make sure we don't
accidentally destroy a useful floppy). We create a primary volume
descriptor (by calling
CreatePVD) and fill in most of the fields with
blanks. We create a simple path table. Because we don't have any
subdirectories, we can build an extremely simple path table with only
one entry (for the root). We make a copy of the path table in both
least-significant-byte and most-significant-byte order.
At this point, we loop, prompting the user for a filename. (See the
CreateFiles for details.) When the user selects a file, we
get the Finder information for that file (
GetFileInfo) and check to
see if the file has a resource fork. If the file has a resource fork, we
create an associated file directory record, and copy the resource fork
to the floppy. We always create a regular file, even if the file in
question has no data fork. (This is an arguable point. The Macintosh
ISO 9660 support works fine on files with only an associated file, but
users of other operating systems get bothered by the fact that files
consisting of only an associated file don't show up in their directory
listings. Creating a regular file, even if the data fork is empty, ensures
that the same number of files shows up on the Macintosh and
MS-DOS or other operating systems.)
Improvements you can make to this sample program include the following:
- Add secondary volume descriptor support.
- Add subdirectories. There are a lot of subtle issues with ordering of records in the
path table that I've managed to avoid by not permitting subdirectories.
- Give the program a real user interface. Ideally, you'd show a Finder-like set of
volumes and let the user drag files (and folders) from a HFS volume onto the ISO
- Allow hard disks to be specified. This requires changing the
drvName constant in
If you've read to this point, you know more about ISO 9660 and High Sierra than you ever thought
your attention span could tolerate. You know where the formats came from, how they're
implemented on the Macintosh, what they specify, how Macintosh files are stored in these formats,
how to press a CD-ROM in one of these formats, and even how to write a program to convert HFS
files to one of these formats. The point of all this is that ISO 9660 (and its older cousin High Sierra) gives you an operating
system independent platform for delivering information, thus opening up new markets for your
applications. If you are trying to penetrate multiple markets without using ISO 9660, you are just
COMPANIES TO CONTACT FOR CD-ROM PRODUCTION
Here's a list of pressing plants that can convert your files to the ISO 9660 format:
3M Optical Recording
St. Paul, MN 55144
Mark Arps/Dick Tendill
1800 N. Fruitridge Ave.
Terre Haute, IN 47804
Linda Watson/Kozo Arai
1120 Cosby Way
Anaheim, CA 92806
Philips Dupont Optical
1409 Foulk Road
Wilmington, DE 19803
Nimbus Information Systems
SR 629, Guildford Farm
Ruckersville, VA 22968
222 New Road
Parsippany, NJ 07054
Nob Tokutake/Ben Garcia
If you want to buy your own premastering system, you can contact one of the following:
Meridian Data, Inc.
5615 Scotts Valley Drive
Scotts Valley, CA 95066
Optical Media Int'l.
485 Alberto Way
Los Gatos, CA 95032
BRIAN BECHTEL works in the Advanced Technology Group, where he applies to his everyday life Wernher Von Braun's
slogan, "Research is what I do when I don't know what I'm doing." His title of Witzelsuchter is derived from an obscure
medical condition (usually caused by brain lesions) in which the patient takes an intense interest in telling long, pointless
stories and jokes. People who know him say this title is appropriate. Brian claims the lesions resulted from nine months of
studying the ISO 9660 and High Sierra standards documents. He also wrote the HyperCard CD Audio Toolkit . He
graduated from Occidental College with an A.B. in math. Meg, his daughter, attends the Apple Child Care Center. His
favorite food is chocolate, as is his favorite color. He says he plays lousy acoustic guitar and roots for the LA Dodgers.
His identical twin, Bradley, manages technical support at some other Silicon Valley company. *
If you're really interested in the standards, you should get copies of the full specifications. You can get the May 28, 1986,
High Sierra specification from
National Institute of Standards and Technology
Gaithersburg, MD 20899
You can get the ISO 9660 specification from any of the following:
American National Standards Institute
New York, NY 10018Sales Department: 212/642-4900
Rue du Rhone 114
Global Engineering Documents
800/854-7175 or 714/261-1455
For the five people out there who really care: Apple's High Sierra and ISO access software supports level-2 interchange,
according to section 10.2 of the ISO 9660 specification. This means it supports interleaved files, but not multivolume sets.*
Thanks to Our Technical Reviewers: Bill Galcher, Matt Gulick, Andy Poggio,
Llew Roberts, Keith Rollin, Helen Wang