Files of this type contain File Type Descriptor tables.
As applications continue to be assigned file type and auxiliary type combinations, the task of user file identification becomes more complex. If someone has the list in "About File Type Notes" memorized, simply displaying the file type and auxiliary type in hexadecimal is a suitable way of identification. However, few people have memorized this list. Programs such as the Finder have a need for this information in machine-readable form -- not just a list of ASCII strings describing file types, but a way to take a given file's file type and auxiliary type and turn it into a string which describes the file. The Finder is not alone in this need, as parts of command shells, and sometimes entire programs, exist simply to identify files.
Developer Technical Support (DTS) has taken this opportunity to create a data structure that may be used by the Finder and any other application wishing to identify files. By using a separate file, the file identifiers can be updated between System Software releases, at the discretion of DTS, by releasing new descriptor files. Other applications may use the same file without having to reinvent the wheel. Furthermore, the multiple-file structure introduced and suggested in this Note allows developers to ship File Type Descriptor files with their software that allow the Finder and other applications to properly identify these files without a new release of the Finder (much as developers can supply their own Finder icons).
Note: Updated files, if and when released, will not result in changes being made to the System Software. The files as shipped with the System Software will remain unchanged until the next System Software release. Developer Technical Support reserves the right to release updated files for the convenience of those who wish to use them.
The file's format is designed to give full and fast access to any file descriptor string, while still remaining flexible enough to grow and be indicative of new features. Each file has three main parts: a header, an index, and the strings.
The file begins with a header which describes all the entries in the file:
The descriptions for each file type and auxiliary type assignment are pointed to by index entries for each string. If there is a string in the file that should be displayed for a particular assignment, there will be an index entry for it. If there is not an entry in any of the loaded files (see the section "Having More Than One File Type Descriptor File"), the string for file type $0000, auxiliary type $00000000 should be displayed.
The index contains one index entry for every file type and auxiliary type assignment or range (see below) in the descriptor file. All index entries in a given file are the same length (given in the header) so fast binary-searching algorithms may be performed. Their format is as follows for files with major version 1:
Note: A range uses the file type and auxiliary type combined as a six-byte value, with the file type bytes as most significant. For example, file type $15, auxiliary type $4000 would fall in the range that starts with file type $13, auxiliary type $0800 and ends with file type $17, auxiliary type $2000
Since each index entry contains an offset to a string, it seems only logical that somewhere in the file is a string for each index entry. Apple recommends that the strings be placed in an array at the end of the index for most efficient use of space and ease in creating the file.
So programs using File Type Descriptor files or resources don't have to construct all information about them each time they are opened, certain characteristics will be true of all files. The following are characteristics which will always be true for files or resources with major revision number $01:
More than one File Type Descriptor file may exist in a given directory. However, only one file may exist in a given directory with any auxiliary type from $00000000 to $000000FF. These files are provided by Apple Computer, Inc. and should not be altered by anything containing carbon atoms. Future implementations of System Software reserve the right to assume undocumented properties about File Type Descriptor files with auxiliary types smaller than $00000100. Editing of the strings in these files is not necessary, since other files may contain strings to override the ones in these files.
There is no such restriction on auxiliary types of $00000100 or greater.
To provide flexibility in changing file descriptions, applications should build in the capability to use as many File Type Descriptor files as are present. Files created by third parties must follow the following two rules:
A file with auxiliary type zero must exist. Others should be searched in order of descending auxiliary type, with $FFFFFFFF having highest priority. (This is why no file must contain a match for file type $00 and auxiliary type $0000 except the Apple-supplied one; otherwise, no searching would ever be done beyond the offending file.) In this way, strings in the Apple-supplied files may be superseded by other strings, without replacing or altering the Apple-supplied file (a feat that would be difficult anyway, due to the offset nature of the file structure).
Applications should search the directory for as many of the given files as can be found. If none is found with auxiliary type $0000, then the application should behave as if no files were found. When searching for a description, a separate search can be done on each file, stopping when a match is found. The search algorithm should return the "unknown" string when no specific match is found in the Apple-supplied file, so the search process will always return some string. An application should never run out of File Type Descriptors before finding a match.
Developers who wish to ship their own File Type Descriptor file with their product may contact Developer Technical Support for assistance in creating the file.
An application (especially a ProDOS 8 application) may not wish to spend valuable memory on files for file identification purposes, especially if directory listings are not an important part of the application. Since all offsets in the File Type Descriptor files are offsets from the beginning of the file, they may also be used with the ProDOS 8 or GS/OS SetMark call. Disk-based searches will obviously be much slower, but could be used for special instances (such as printing complete directories of disks as opposed to displaying them, or for specific functions that identify files).
In Apple IIGS System Software 5.0, the Finder uses File Type Descriptor files. The Finder's implementation is somewhat limited, as this is a first pass at this new standard. The following implementation notes apply to Finder 1.3:
This and all of the other Apple II Technical Notes have been converted to HTML by Aaron Heiss as a public service to the Apple II community, with permission by Apple Computer, Inc. Any and all trademarks, registered and otherwise, are properties of their owners.