Re: MS-DOS FST? => Resources

[toddpw@cco.caltech.edu (Todd P. Whitesel)]

vandry@CAM.ORG (Phillip Vandry) writes:

>OK. Tell me in what situation it would be good for a program to write
>information to itself.

Personalization. Lots of applications you can buy these days implement a
guilt method of copy protection by forcing you to type in a name and some
other information (address, company, whatever) before they will run for the
first time. Some of them even print out the warranty registration card on
the printer based on that information. After the product has been
personalized/registered/whatever, it displays the registration info every
time it starts up so that if you copy it around it is instantly obvious
where it came from (unless you typed in bogus stuff in the first place,
in which case your warranty probably won't be valid). For obvious reasons,
software vendors do not want to make this information easily accessible to
the user once it's been entered, and some probably encrypt the data they
put in the resource to discourage people from messing with it.

This is probably the most practical situation, but it is not the only one.
You appear to be so fixated on the unix paradigm that you are unable to
appreciate the potential advantages in any other approach. Unix was not
designed to solve the sorts of problems that resources were designed to
solve, nor were resources designed to do everything the filesystem does.
They both address different yet valid sets of programming issues.

>Or you could.... there are so many other ways of doing it. It really didn't
>need to be hard coded into the file system like it was.

That's true; it didn't need to be hard coded into the filesystem. This is
about the only complaint I can honestly bring against the implementation
Apple used, but even I have to admit that 20/20 hindsight is primarily
responsible for me saying that. Back when Apple first implemented the
resource system, it is not likely that "how are we going to implement this
on the PC, on unix, etc..." was an issue in anyone's mind. Heck, back
then a lot of people thought MS-DOS was a viable operating system...

> But GS/OS had to be very much extended to be able to work with that.

I have yet to see any real evidence to support this. If anything, the Open
pBlock resourceNumber field suggests that GS/OS was _designed_ to support
forked filesystems. Remember, GS/OS was not an extension of Prodos-16, it
was completely new. (P16 was just a wrapper for P8, so even calling GS/OS
a rewrite of P16 would be an insult.)

Todd Whitesel
toddpw @ cco.caltech.edu