[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Disassembling an FST...
Supertimer <supertimer@aol.com> wrote:
> How difficult would it be, in addition to an FST, to rewrite a ProDOS
> *OS* that can be booted and used to run existing 8-bit apps. Even
> if it can only be used on a IIGS, it would be useful. More than that,
> coupled with the ProDOS+/GSFAT FST, you could launch an 8-bit
> program on such a volume (which could be well larger than 32MB)
> and it would run the program under the enhanced ProDOS *OS*
> on the large ProDOS+/GSFAT volume.
I can think of several potential problems (apart from the minor detail
of having even more disassembly and coding to do):
1. Programs which use the BLOCK_READ and/or BLOCK_WRITE calls. These
calls would have to be disallowed on a "GSFS" volume, since the data
read by the application is not likely to be what it expects. New calls
could be added for newer applications that are aware of the potential
differences. (This would rule out using Copy II+ and all current disk
copy programs.)
2. Reading directories would require a simulation layer, providing
directory blocks that look like ProDOS ones. This would only be
supported through the OPEN/READ mechanism, not using direct BLOCK_READ
calls. (Again, a special call could be added to enable GSFS-aware
programs to see the real directory.)
3. ProDOS-8 applications cannot handle files larger than 16 MB due to
the MLI calls only allowing for 3-byte EOF values.
4. Filenames would have to be restricted to ProDOS-8 compatible limits
(uppercase, digits and periods, no more than 15 characters). Normal
ProDOS-8 applications would not be able to access files, directories or
volumes with names that don't comply with these restrictions.
5. File copy utilities could lose information from resource forks,
unless something special was done to simulate the unsupported storage
type, preventing the files from being opened in the first place (except
through a special call). Alternatively, access to the data fork could
be allowed, with the risk of losing the resource fork if the file is
copied.
Now why does all this sound familiar? It is exactly what the AppleShare
support code (PFI) has to do!
--
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand