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 volume;
• 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. ThevolumeFlag field is used to indicate whether a non-ISO-standard alphabet is being used. TheescapeSequences 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 descriptor.

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 Macintosh.

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
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 levels).

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 FORKSEvery 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.

FILE IDENTIFIERS
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.

FINDER FLAGS
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.

DESKTOP INFORMATION
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 FInfo, FXInfo,DInfo, and 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 translators.

SUMMARY
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'sGetInfo 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 format."

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 inserted.

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;

typedef struct
{
    Byte    VDType;                 /* Must be 1 for primary volume
                                       descriptor. */
    char    VSStdId[5];             /* Must be "CD001". */
    Byte    VSStdVersion;           /* Must be 1. */
    Byte    volumeFlags;            /* 0 in primary volume
                                       descriptor. */
    char    systemIdentifier[32];   /* What system this CD-ROM is
                                       meant for. */
    char    volumeIdentifier[32];   /* The volume name. */
    char    Reserved2[8];           /* Must be 0's. */
    Long    lsbVolumeSpaceSize;     /* Volume size, least-significant
                                       -byte order. */
    Long    msbVolumeSpaceSize;     /* Volume size, most-significant
                                       -byte order. */
    char    escapeSequences[32];    /* 0's in primary volume
                                       descriptor */
    Word    lsbVolumeSetSize;       /* Number of volumes in volume
                                       set (must be 1). */
    Word    msbVolumeSetSize;
    Word    lsbVolumeSetSequenceNumber;/* Which volume in volume set
                                          (not used). */
    Word    msbVolumeSetSequenceNumber;
    Word    lsbLogicalBlockSize;    /* We'll assume 2048 for block
                                       size. */
    Word    msbLogicalBlockSize;
    Long    lsbPathTableSize;       /* How many bytes in path
                                       table. */
    Long    msbPathTableSize;
    Long    lsbPathTable1;          /* Mandatory occurrence. */
    Long    lsbPathTable2;          /* Optional occurrence. */
    Long    msbPathTable1;          /* Mandatory occurrence. */
    Long    msbPathTable2;          /* Optional occurrence. */
    char    rootDirectoryRecord[34];   /* Duplicate root
                                          directory entry. */
    char    volumeSetIdentifier[128];  /* Various copyright and
                                          control fields follow. */
    char    publisherIdentifier[128];
    char    dataPreparerIdentifier[128];
    char    applicationIdentifier[128];
    char    copyrightFileIdentifier[37];
    char    abstractFileIdentifier[37];
    char    bibliographicFileIdentifier[37];
    char    volumeCreation[17];
    char    volumeModification[17];
    char    volumeExpiration[17];
    char    volumeEffective[17];
    char    FileStructureStandardVersion;
    char    Reserved4;               /* Must be 0. */
    char    ApplicationUse[512];
    char    FutureStandardization[653];
} PVD, *PVDPtr;

The path table looks like this in C:

typedef char   dirIDArray[8];

typedef struct
{
    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
                               is */
                    /* 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:

typedef struct
{
    char    signature[2];       /* $41 $41 - 'AA' famous value. */
    byte    extensionLength;    /* $0E for this ID. */
    byte    systemUseID;        /* 02 = HFS. */
    byte    fileType[4];        /* Such as 'TEXT' or 'STAK'. */
    byte    fileCreator[4];     /* Such as 'hscd' or 'WILD'. */
    byte    finderFlags[2];
} AppleExtension;

typedef struct
{
    byte    len_dr;         /* Directory record length. */
    byte    XARlength;      /* Extended attribute record length. */
    Long    lsbStart;       /* First logical block where file
                               starts. */
    Long    msbStart;
    Long    lsbDataLength;  /* Number of bytes in file. */
    Long    msbDataLength;
    byte    year;           /* Since 1900. */
    byte    month;
    byte    day;
    byte    hour;
    byte    minute;
    byte    second;
    byte    gmtOffset;      /* 15-minute offset from Universal
                               Time. */
    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. */
    Word    msbVolSetSeqNum;
    byte    len_fi;         /* Length of file identifier that
                               follows. */
    char    fi[37];         /* 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 example.

Our basic flow of control is simple. The core of the program is in the file BuildISO.c. (SeeCreateAVolume 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 callingCreatePVD) 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 routine 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.)

POSSIBLE IMPROVEMENTS
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 9660 volume.
• Allow hard disks to be specified. This requires changing the drvName constant in iso9660.h.

IN CONCLUSION

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 pounding sand.

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
Building 223-5S-01
3M Center
St. Paul, MN 55144
612/736-3274
Mark Arps/Dick Tendill
AppleLink: D2462

DADC
1800 N. Fruitridge Ave.
Terre Haute, IN 47804
812/462-8100
Linda Watson/Kozo Arai
AppleLink: D2125

Disctronics
1120 Cosby Way
Anaheim, CA 92806
714/630-6700
Wan Seegmiller

Philips Dupont Optical
1409 Foulk Road
Suite 200
Wilmington, DE 19803
800/433-3475
Jill Jones
AppleLink: D2173

Nimbus Information Systems
SR 629, Guildford Farm
Ruckersville, VA 22968
800/782-0778
Larry Boden

Denon America
222 New Road
Parsippany, NJ 07054
201/575-2532
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
408/438-3100
Dean Quarnstrom

Optical Media Int'l.
485 Alberto Way
Los Gatos, CA 95032
408/395-4332
Applelink: D1490

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
Administration 101
Library E-106
Gaithersburg, MD 20899

You can get the ISO 9660 specification from any of the following:

American National Standards Institute
1430 Broadway
New York, NY 10018Sales Department: 212/642-4900

ECMA Headquarters
Rue du Rhone 114
CH-1204
Geneva, Switzerland

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