Re: MS-DOS FST? => Resources

[hochstrasse@urz.unibas.ch]

In article <1993May4.222338.8682@fawlty.towers.oz.au>, johnmac@fawlty.towers.oz.au (John MacLean) writes:
> In article <C69o93.Jqw@news.iastate.edu> irsman@iastate.edu (Ian Schmidt) writes:
>>In article <1rp75k$dni@altitude.HIP.CAM.ORG> vandry@CAM.ORG (Phillip Vandry) writes:
>>>Not that resources should exist in the first place.. nothing but problems,
>>>a stupid idea from Apple.

Reading such a statement, I can only say: look at my sig!
> 
>>Like hell.  Resources are THE coolest thing Apple's come out with, excepting
>>the IIgs itself.  They're the only way to go for easy GUI design, and they're
>>damn handy for including a program and all its data in 1 easy file.
>>                                          Ian Schmidt: irsman@iastate.edu
> 
> The concept of resources is great - having data separate from the code
> and being able to edit it at a later date without the need for the source.
> It makes GUI design potentially much easier, and it allows customisation
> of programs for your individual taste and international distribution.

I agree fully.
> 
> Unfortunately, the implementation Apple chose (ie: splitting a file into
> two forks) sucks badly, IMHO.
> It required adding a vast array of support at the operating system level,
> and makes Apple's proprietory file systems very difficult to map to any
> other file systems (such as MSDOS, UNIX, etc).

This can really easily done with separate files on the 'foreign' system.
> 
> Why couldn't they just define a file format for executeables that allowed
> "resources" to be included in the same "fork" as the program, with the
> code being in uniquely identified "resource"?

Files containing only resources, code and data would be a good idea,
but as history went, there were first data-or-program-only files.
Evolving from this directly into resource-only is a big step...
> 
> We don't really need resource on files that are not executeable code,
> do we?

Of course we need them! Look at Teach files with the formatting in resources.

> If it is really necessary to add comments to files, then this functionality
> could be added in variable length directory entries.
> This would then just become an attribute of the file - and it was already
> true that not all file systems support all attributes.

With this method you're moving far away from the prodos file system
(and many others as well!) I think, the mapping problems for such a system
would be even worse...

There is just one point I criticize with resources: Prodos 8 returns
an error when it must read an extended file. Why not just implement
an optional warning, that you could lose data when handling the file
on P8 and that's it. P8 programs could use files that just contain
an rComment or other 'luxurious' resource.
> 
--Urs

|  BRIGHT SOFTWARE          |  * A P P L E   I I   F O R E V E R *  |
|  Urs Hochstrasser         |    'The command line interface is     |
|  Strassburgerallee 79     |    10 year old technology for me!'    |
|  4055 BASEL, SWITZERLAND  |  InterNET: HOCHSTRASSE@URZ.UNIBAS.CH  |