One of the issues covered at the past two APDA Standards conferences, however briefly, is the issue of ProDOS filetypes, their use and abuse. Although the issue may not have been covered in great detail at those proceedings, it is indeed an issue which cuts right to the heart of standards in general P providing a consistent form of data presentation and identification for all users of the computer, including developers. This particular issue, as are many issues of Apple II standards, is frustrating at best and maddening at worst. But we can't define and identify a solution before we have identified the problem. How the problem started A ProDOS filetype is a one-byte storage location in every file's directory entry. This byte is used to categorize the contents of the file. For example, a file whose filetype entry is the hexadecimal value $B3 is defined to be a ProDOS 16 application program for the Apple IIgs. Since the filetype is a one-byte value in ProDOS, there are only 256 ProDOS filetypes. Programmers and developers appreciate the utility of filetypes because they make file identification much easier. If AppleWorks wants to know which files on any particular disk are AppleWorks files, it doesn't have to read each file on the disk and try to decipher the contents. It doesn't have to include some identifying string as part of the filename, nor does it need all AppleWorks data files to be in one specific location. Instead, it can look at the filetype of each file it finds in a particular directory. If the filetype is one of the values $19, $1A or $1B, then AppleWorks knows it has found a data file which belongs to AppleWorks. Correspondingly, BASIC.SYSTEM will not try to RUN a file unless that file has filetype $FC. ProDOS itself knows a file is a directory file if it has filetype $0F, and ProDOS 16 uses the filetype to identify setup files, desk accessory files, application files, device drivers and tool sets. The filetype makes the process of identifying files quicker for the user and easier for the developer. But all of the filetypes mentioned above were used for Apple's purposes (AppleWorks was an Apple product before the creation of Claris). The ProDOS manuals listed all other filetypes as simply "reserved." This implied, and should have stated, that Apple's Developer Technical Support (DTS) group was responsible for the assignment of filetypes. DTS set down two criteria for those developers who wished to have their own ProDOS filetypes: 1. The files in question had to be unique. It wasn't just enough that they not be exactly the same as previously-defined filetypes; developers had to prove that their file's data couldn't fit within existing filetypes. If you wanted a filetype for an Applesoft BASIC program that loaded at a non-standard location, you weren't likely to get it. If you wanted a filetype for programs in a new implementation of BASIC, well, that was another story entirely. 2. The formats of the files in question had to be public knowledge. 256 ProDOS filetypes may have been about (or exactly) thirty-two times as many filetypes as were available in DOS 3.3, but that was still substantially smaller than an infinite number. Handing them out right and left to people for their own private data structures would soon result in no filetypes left to assign. Data that could easily live in an already-assigned filetypeUs file format would be left without a home, since the people to whom the filetype was assigned hadn't made that file format public knowledge. Developer Technical Support was not thrilled by this possibility. However, developers were less than thrilled by the two criteria, particularly the second one, and they didn't hesitate to say so. They said that their file formats were as important to them as any other data structures of their program. They said long, hard, indigestion-inspiring hours had gone into the design of those file structures, and that publishing them would make it easier for others to imitate their programs. It's well known that as soon as one software publisher releases a truly new and innovative program, imitations aren't far behind. After all, imitation is the sincerest form of flattery. However, the imitation can often be superior to the original. If the publishers of an innovative software product are relying on the idea to sell the program, then there's a good chance that there's room for improvement in the implementation of that idea. Few people would argue the point that Lotus 1-2-3 is a more powerful product than the original VisiCalc, but it was VisiCalc that was the original, and 1-2-3 the imitator. Developers know this as well as anyone else, as this is an everyday aspect of the software business. And many of them thought that public file formats were a big boost to the imitators. If the imitators can do all the things the original does, maybe doing them a little better, and do a few more things in addition, then the developer of the original program has a few problems. And if the developer of the original had published his file formats, then the imitators could read and write the original program's files. This might be the last step necessary for the imitator to convince the users of the original package that it was time to switch. Here began a serious misunderstanding between developers and Apple. Developer Technical Support quickly realized that many major developers were not willing to publish their file formats. They also realized that there was nothing in ProDOS to actually prevent anyone from using any filetype at all, whether it was assigned and recognized by Apple or not. (If this were not true, Apple would have to release a new version of ProDOS for each filetype assignment made.) Faced with these realizations, they quietly began also assigning filetypes to those developers who would not disclose their file formats, even as they strongly encouraged disclosure. An examples of this policy is the PFS* filetypes assigned in the range just below the AppleWorks filetypes. However, other developers interpreted what they'd heard (since it wasn't clearly documented anywhere) to mean that if they didn't publish their file formats, they couldn't be assigned types. So they simply "took" their own, picking them out of the 256 types in the hopes that no one else (including Apple) would step on their files in the future. It would be disastrous for both the developer and the user if the filetype the developer liberated was ever used for another reason, as those people who just "took" filetype $B3 have certainly found out. Imagine the confusion of Apple IIgs owners who tried to launch those data files from the Finder*, thinking they were applications! Developer Technical Support was caught between the proverbial rock and hard place. They couldn't enforce the criteria they'd established, and they couldn't announce the new criteria because all 256 filetypes would quickly vanish, just as they'd feared from the beginning. As developers continued to take filetypes without assignment, users began to find files on their disks with strange and unknown filetypes, and had no method to identify them. There was no single place to which one could turn for a comprehensive list of filetypes and their definitions. The one place that should have had it P Developer Technical Support P was as confused as everyone else, occasionally pausing to shake their collective heads in sympathy for a developer who'd made an extremely bad choice of filetypes to steal. It has become painfully clear that significant intervention is necessary to clear up this situation. Without a strongly worded new filetype policy from Apple, the problem can only grow worse as demand for filetypes increases steadily. This is why Apple has decided to significantly intervene with a strong new filetype policy, with advantages to both developers and users. What Apple is doing Developer Technical Support is taking a more active role than ever in assignment and maintenance of filetypes. Developers have discovered on their own what Apple tried unsuccessfully to say all along: users don't want disks full of files that are identified by every other program as "Unknown file(s)". To help avoid this situation, Apple is moving in several directions. Faced with an increasing demand for filetypes and a decreasing supply, Developer Technical Support has adopted a new policy for filetype assignment. Several "generic" filetypes have been established for popular types of applications, and individual applications may be assigned auxiliary filetypes, or auxtypes, within that filetype. The auxtype is a two-byte value also contained in the directory structure, although not as important by convention as the filetype. In the past, the use of the auxtype had been left to the application that created the file. Since most developers who used this field were using it to further identify files within a given filetype, Apple decided to adopt a new convention. Apple now reserves the right to define auxtypes for those filetypes whose auxtypes previously had no definition. For example, the auxtype of a text file is defined by convention to contain the random-access record length, and the auxtype of a binary file is defined by convention to contain the load address (in bank 0) of that file under BASIC.SYSTEM. These definitions will remain the same, but as new filetypes are assigned, Apple may or may not choose to define the auxtypes for them. What all this means is that if you are developing, for example, a word processing program and request a filetype for your data files, Apple will assign you a filetype/auxtype combination. In this particular case, the filetype would be $50 (Word Processing File), and the auxtype would be one that is currently unassigned. Disk cataloguing routines that only display the filetype (or a three-letter mnemonic for it) will identify all developers' word processing data files as "Word Processor Files", and those routines that go further can then identify the file by specific creator application. The Apple IIgs Finder displays icons for a file if it matches criteria specified for the filetype, filename and auxtype, so the Finder works well with this method also. In addition, those programs which import data files from other programs should not have to look past their own filetype to find the data files of other similar programs. This greatly increases the availability of assignable, identifiable files, but not to the extent of that found in HFS on the Macintosh*. HFS identifies files by a four-byte ASCII creator code, and developers need only ask Apple if the code they wish to use is already in use. Developer Technical Support maintains a database of all currently assigned Macintosh creator types, and will inform a developer if the type he has picked is already in use. The new Apple II/ProDOS scheme has no similar analog on the Macintosh P it would be like saying "All word processor applications have to pick types that start with 'W'." It just doesn't make much sense. Therefore, Apple II developers still can't pick their filetype/auxtype combinations and simply register them with Developer Technical Support, but they may be assigned one with little more difficulty than asking. (We offer our thanks to the developers who patiently waited for filetype assignments while this new policy was hammered out.) Also significant to developers is the creation of Apple II Filetype Notes. This program, announced by Apple II Developer Technical Support Manager Rilla Reynolds at the APDA Standards Conference at AppleFest in Boston, is designed to centralize and widely distribute information about filetype/auxtype assignments and file formats. The notes, which will look similar to Apple II Technical Notes, will list which filetypes and auxtypes are assigned to whom, and will include the file formats of those files whenever possible. Information on different file formats, even for Apple's formats, is scattered over several different technical manuals. The Filetype Notes will not only make a convenient collection place for this information; their regular distribution will also provide an easy way for Apple to notify developers of updates to any of the file formats, or of new filetypes which have been assigned. The notes will also be available in Apple II disk format, as will the Apple II Technical Notes later this year. DTS is working to further support those developers who have received filetype assignments from Apple. The Apple II Filetype Notes will receive wide distribution, and each note about a third-party filetype assignment will contain the name and address of the developer to whom the file is assigned, as well as the retail price and a short description of the creating application. The Filetype NotesU wide audience will have more information about each program, and many will adjust their programs to interact with other programs accordingly. This way of sharing knowledge about your applicationUs files will help add value to your application. For example, if your application is a spreadsheet, and another developer is working on a template conversion program so that other spreadsheet users can use templates from, say, AppleWorks, then the knowledge he gains of your spreadsheet files from the Apple II Filetype Notes will help him to support your spreadsheet in his conversion program. The filetype notes will be generated automatically, with no action from the developer necessary, for those who have received filetype assignments from Developer Technical Support. The only action required for your file formats to be included in the notes is to submit them to DTS (see below). The Filetype Notes will give a complete listing, as DTS knows it, of what file belongs to which program, to developers who are writing cataloguing routines. This will allow them to display the proper contents of the file, not simply the ambiguous and frustrating string "Unknown File" or some indecipherable hexadecimal number. In addition, future versions of the Apple IIgs Finder will support the filetype and auxtype combinations listed in the Filetype Notes, so that users can view documents by name, size, kind or date and see phrases like "Whiz-bang Word Processor document" instead of "Unknown". DTS is also moving to help clear up existing confusion. One of the most confusing filetype related areas is that of disk and data compression. Modem users often compress data so that transmission time is reduced. Unfortunately, many of the data-compression programs out there have chosen to steal filetypes for their compressed data files, assuming that an assignment from Developer Tech Support would not be possible. To help straighten out this situation, DTS has declared a kind of amnesty for these data-packing programs. Authors of these utilities simply need to send a copy of their program, a brief description of the packing algorithm (source code is not necessary), and the file format (if at all possible) to the address listed below. A permanent filetype/auxtype combination will be assigned for the program, and future versions of the Finder will recognize all such files as compressed data files. What Apple would like you to do If you are currently using a filetype that's not listed in the ProDOS 8 or ProDOS 16 Technical Reference Manuals, Developer Technical Support would like to know about it. Send the information as to which filetypes and auxtypes you are using, and what you're using them for, to Apple at the following address: Apple II Developer Technical Support 20525 Mariani Avenue, Mail-stop 51-T Cupertino, CA 95129 Attn: Apple II Filetype Registration This request originally went to all Apple Certified Developers in April, and since then, DTS has literally been blown away by a virtual hurricane of indifference. However, realizing that the necessary people may not have received the request, the deadline has been extended to August 31st. After all, Finder can't recognize your files if Apple doesn't know about them. Even if your filetype and auxtype were assigned by DTS, we'd appreciate your information anyway, just so we can double-check that it matches what we have. If you can at all bring yourself to do so, please publish your file formats. No, this is not a mere repetition of old policy. It's very justifiable, especially today. There are times and circumstances when it would be very disadvantageous to a developer to publish his program's file formats, and Apple understands that. However, there is much to be gained from an open file format. Even if your program makes no provision to read and write the files of other applications, conversion programs that do the work for you will soon appear in places like user groups and on-line information services. People with these conversion programs will suddenly be able to use hundreds of previously inaccessible files with your application. That makes your application more valuable to the user. If you intend to revise your program and keep it up-to-date, then you can include importing and exporting routines in your next revision, and eliminate the need for these conversion programs altogether, adding even more value to the application for the user. Although other applications will be able to read your program's files as well, this is not necessarily bad. If a user has an ASCII text file to edit, he may use his favorite word processor, since just about all word processors can read and write ASCII files. Similarly, if a user has a word processor file obtained elsewhere to edit, he would like to use his favorite word processor to edit it P not just the one that created the file. If all file formats are interchangeable, users will have the ability to pick applications because they have the features they want, not because they have the limitation of being the only application that can read that file. Nearly every computer user, at one time or another, has been forced to use a program he didn't want to use just because there was no other way to get at the data. That usually creates a slight feeling of resentment with the user; furthermore, if he only has to use the program for one document, he may feel encouraged to use a pirated copy. Publishing your file formats is easier than ever. Just send a description of them to Developer Technical Support at the above address, and they'll be put into Apple II Filetype Notes. Even if you've already published your file formats (for example, in your documentation), DTS would like to have them for the Filetype Notes. The most prominent example I can point to is AppleWorks. AppleWorks file formats were defined in Apple II Miscellaneous Technical Note #5, and AppleWorks doesn't seem any worse for the exposure. With the support of the Apple II programmers and developers, an end to the confusing situation of filetypes may be at hand. Although the facility to inextricably link each file with a creator type is not possible in ProDOS, we can come very close to a similar situation P one where file identification is handled by the computer at virtually every level, since each application contains the facility to identify all files it encounters. Three things are necessary for this to happen: a clearinghouse to assign filetypes and publish listings of those assigned, applications which use the published listings to identify files, and willingness by developers to request filetype/auxtype assignments rather than attempts to second-guess the clearinghouse. Apple is now acting as the clearinghouse, but the other components fall to you, the developers. Please join Apple in clearing up this messy situation for good. Keith Rollin UUCP: amdahl\ Developer Technical Support pyramid!sun !apple!keith Apple Computer decwrl/ BITNET: keith%apple.com@relay.cs.net "You can do what you want to me, but leave my computer alone!" ProDOS Filetypes Num Name OS Meaning ======================================================================== $00 typeless $01 BAD both BAD blocks file $02 PCD SOS Pascal CoDe file $03 PTX SOS Pascal TeXt file $04 TXT both ASCII text file $05 PDA SOS Pascal DAta file $06 BIN both BINary file $07 CHR SOS CHaRacter font file $08 PIC both PICture file $09 BA3 SOS Business BASIC (SOS) program file $0A DA3 SOS Business BASIC (SOS) data file $0B WPD SOS Word Processor Document $0C SOS SOS system file $0D SOS SOS reserved file type $0E SOS SOS reserved file type $0F DIR Both subDIRectory file $10 RPD SOS RPS data file $11 RPI SOS RPS index file $12 SOS Applefile diskcard file $13 SOS Applefile model file $14 SOS Applefile report format file $15 SOS Screen library file $16 SOS SOS reserved file type $17 SOS SOS reserved file type $18 SOS SOS reserved file type $19 ADB ProDOS AppleWorks Database file $1A AWP ProDOS AppleWorks WordProcessing file $1B ASP ProDOS AppleWorks Spreadsheet file $1C-$5F Reserved $60-$6F ProDOS PC Transporter (Applied Engineering) reserved filetypes $60 PRE ProDOS ProDOS preboot driver $61-$6A ProDOS Reserved $6B NIO ProDOS PC Transporter BIOS and drivers $6C ProDOS Reserved $6D DVR ProDOS PC Transporter device drivers $6E ProDOS Reserved $6F HDV ProDOS MSDOS HardDisk Volume $70-$9F Reserved $A0 WPF ProDOS WordPerfect document file $A1 MAC ProDOS Macrofile $A2 HLP ProDOS Help File $A3 DAT ProDOS Data File $A4 Reserved $A5 LEX ProDOS Spelling dictionary $A6-$AB Reserved $AC ARC ProDOS General Purpose Archive file $AD-$AF Reserved $B0 SRC ProDOS ORCA/M & APW source file $B1 OBJ ProDOS ORCA/M & APW object file $B2 LIB ProDOS ORCA/M & APW library file $B3 S16 ProDOS ProDOS16 system file $B4 RTL ProDOS ProDOS16 runtime library $B5 EXE ProDOS APW shell command file $B6 STR ProDOS ProDOS16 startup init file $B7 TSF ProDOS ProDOS16 temporary init file $B8 NDA ProDOS ProDOS16 new desk accessory $B9 CDA ProDOS ProDOS16 classic desk accessory $BA TOL ProDOS ProDOS16 toolset file $BB DRV ProDOS ProDOS16 driver file $BC-$BE Reserved for ProDOS16 load file $BF DOC ProDOS document file $C0 PNT ProDOS //gs paint document $C1 SCR ProDOS //gs screen file $C2-$C7 Reserved $C8 FNT ProDOS Printer font file $C9 ProDOS finder files $CA ProDOS finder icons $CB-$DF Reserved $E0 LBR ProDOS Apple archive library file $E1 Unknown (unlisted) $E2 ATI ProDOS Appletalk init file $E3-$EE Reserved $EF PAS ProDOS ProDOS Pascal file $F0 CMD ProDOS added command file $F1-$F8 ProDOS User defined filetypes (popular ones include:) $F1 OVL ProDOS Overlay file $F2 DBF ProDOS Database file $F3 PAD ProDOS MouseWrite file $F4 MCR ProDOS AE Pro macro file $F5 ECP ProDOS ECP batch file $F6 DSC ProDOS description file $F7 TMP ProDOS temporary work file $F8 RSX ProDOS linkable object module $F9 IMG ProDOS ProDOS image file $FA INT ProDOS Integer BASIC program $FB IVR ProDOS Integer BASIC variables file $FC BAS ProDOS AppleSoft BASIC program $FD VAR ProDOS AppleSoft BASIC variables file $FE REL ProDOS ProDOS EDASM relocatable object module file $FF SYS ProDOS ProDOS8 system file