Re: MS-DOS FST? => Resources

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

vandry@CAM.ORG (Phillip Vandry) writes:

>Exactly. A simple solution would be to make dynamic OMF segments a little
>easier to work with. IMO, the only adavantage (ONLY!) of resources is that
>they can be purged from memory if required. Dynamic segments have this
>functionality. Plus they can do everything else resources do - without
>hacking up the file system.

You're forgetting something: resources aren't read-only and even data files
(i.e. not OMF) can have them. Applications can create and edit their own
resources while they're running; try adding THAT kind of functionality to
OMF ... I don't think it'll be pretty. OMF also has a lot more overhead per
"chunk" than resources do. What would (sorta) work for applications is doing
what win3 does: append the resource section to the end of the executable.
This has lots of restrictions however. For instance, you can't put resources
on a data file -- how would you preserve the resources the next time you
increased the size of the normal data in the file? Sure, it can be done, but
not in an easily transparent way. You're back to where you started.

>On the other hand, I've always found it convenient to have data
>completely seperate from code - in sepearate files. That makes customization
>much easier. Don't like the program's title page? delete the file
>Title.Page and put your own SHR picture in its place.

But that's how resources conceptually work! The only difference is that you
need a program to delete them and replace them because they aren't mapped
into the file system. If you could manipulate resources as if the application
file was a subdirectory (only much more storage-efficient for < 512 byte
objects), wouldn't resources be a lot more attractive?? The next best thing
would be to write command line tools for doing cp/mv/rm/ls type things to
resource forks. How hard could that be? (Uh oh, not another project...)

>Also, look at everything that had to be changed to accomodate resources.
>All the tools had to be rewritten to support them. The operating
>system had to be rewritten.

I don't know about rewritten, unless the O/S was really hacked to begin with.
My guess is that it simplified things by unifying all the logic to deal with
small purgeable stuff. Tools did not have to be rewritten, they just needed
extra calls to load the resource before calling the original toolbox routine.

>It may be easy for the programmer to use resources: just use, for example,
>NewWindow2 instead of NewWindow. But if there had been no resources,
>tons of routines like NewWindow2 wouldn't need to exist. I'm sure
>resources support code accouts for a considerable fraction of toolbox code.

I beg to differ. Hopefully one of the Apple dudes will set the record
straight on this so we don't get into a shouting match about it.

BTW, I agree with you that rez is bad. I won't use resources without Genesys.
For stuff like title pictures, some command line utilities to manipulate
resources would be mind-bogglingly useful.

Todd Whitesel
toddpw @ cco.caltech.edu