Apple II
File Type Notes
_____________________________________________________________________________
                                                  Developer Technical Support

File Type:         $BD (189)
Auxiliary Type:    All

Full Name:     GS/OS File System Translator
Short Name:    GS/OS File System Translator

Written by:    Matt Deatherage                                 September 1990

Files of this type and auxiliary type contain file system translators for 
GS/OS.
_____________________________________________________________________________

Files of type $BD contains file system translators, or FSTs.  FSTs do not load 
if bit 15 of their auxiliary type is set.

GS/OS calls FSTs to interpret the physical file systems stored on block 
devices.  By asking translation software to read the file system, GS/OS can 
read virtually any file system while having only an abstract file system 
assumed in the operating system code.  Not all released file system 
translators are required, saving space on disk and in memory.

The format for FSTs is Apple confidential and subject to change with every 
system software release; Apple will release all future FSTs for GS/OS.  Third-
party developers may not create GS/OS FSTs--no documentation is available, and 
disassembly of the code for this purpose is not permitted.  This is not an 
easy decision for Apple, which is a company that was built upon and operates 
with the goal to empower individuals through computing.  Not revealing 
information isn't exactly consistent with this goal.  There are, however, 
reasons for this policy.

First, FSTs are not as modular as they could be.  Some GS/OS level changes 
require changes to all of the FSTs to be implemented.  These changes range in 
magnitude from internal system service call changes to adding new parameters 
to existing calls.  GS/OS is not tolerant of FSTs that do not know about such 
changes.  The FST structure is straightforward, but it is also complex enough 
that disassembly of existing FSTs does not cover all the bases.

Second, it can create chaos for users.  Two file system translators for a file 
system is far worse than none at all.  No physical file system exactly matches 
the GS/OS abstract file system, so every FST must have file system specific 
behavior.  Although some of these behaviors are well documented (parameters 
that do not fit in the abstract file system go in the option_list, for 
example), no two independently-designed FSTs for the same file system can 
possibly do such things identically.

For example, if there were two third-party DOS 3.3 FSTs available, each would 
have its own FSTSpecific subcalls, option_list parameters and other 
implementation differences.  Since there is only one file_sys_ID per file 
system, programs that create correct data structures for one DOS 3.3 FST may 
blow up with the other one.

If users somehow manage to figure this out, the only way to change FSTs is to 
enter the *:System:FSTs folder, deactivate one FST, activate another one and 
reboot, which is not acceptable.  Even switching FSTs is unacceptable for 
archival and copying programs which may have stored option_list parameters 
embedded in files.  Futhermore, if the file system is bootable, that makes 
boot blocks and a file system stub which are also tied to an FST, and users 
would have a horrible time changing those.

The best solution to these problems for Apple's customers (who are also your 
customers) is for Apple to maintain control over the development of file 
system translators.  Apple will provide file system translators for other file 
systems.  If you have requests for how certain features of any file system 
should be handled by future FSTs, please contact Developer Technical Support.


Further Reference
_____________________________________________________________________________
  o  GS/OS Reference

