         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
