Re: MS-DOS FST? => Resources

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

vandry@CAM.ORG (Phillip Vandry) writes:

>I don't see good use for either of these things. To have a program write to
>itself would be bad.

Hey, who declared you king of programmers? Just because YOU don't see any
good use for them doesn't mean that other people haven't found lots of great
things to do with them. Resources are great for giving programs their own
private little directory of tiny data files -- stop whining because the O/S
doesn't have memory-resident code to let you 'ls' around in them. Write
yourself some cp/mv/ls/rm utilities for resources and be happy.

>That's why I said it [OMF] would need to be optimized.

Fat chance. OMF has already been upgraded once, and it does a pretty good
job at what it does. Program chunks inherently need more context than do
little things like resources, so an 'optimized' OMF is out of the question
unless you like the idea of doing away with OMF entirely and switching over
to code resources (also not likely, given Apple's current committment to the
IIgs -- insert standard Matt Deatherage response here).

>>But that's how resources conceptually work! The only difference is that you
>Then that's how they should physically work also!

GET A CLUE. If they physically worked that way they'd be inefficient as hell.
Your proposal to "optimize" OMF is not going to give you everything that the
current implementation of resources do.

>Any fd could now refer either to a data fork or to a resource fork. Every

GS/OS already does that. Finder uses it to copy resource forks all the
time. The "Open" call description in the GS/OS reference manual covers it.
Have you been smoking something lately?

>time the os accesses a file by refnum it must check this. Calls like
>GetFileInfo, Open, Create, GetRefInfo have to account for them specifically.
>There's more to change than is apparent at first.

Actually, the os probably has an internal "fork" structure and associates
the refnum with it rather than with the whole file. Directory entry calls
like GetFileInfo are path based anyway, and the FST takes care of fetching
the resource fork info. Besides, GS/OS was written with resources from the
ground up -- look at the Class 1 Open call parameter block (not the old
Prodos-16 one) and try to convince us that the "resourceNumber" space was
tacked on. Good luck.

>I know. Believe me. I'm rewriting the Menu Manager.

What the hell are you doing that for?? Mark Cecys did it too; it's partly
why SynthLab never got anywhere.

>Just about every second call has to take into account the possibility that
>an icon or title or item name of whatever might be a resource. And then
>there's NewMenuBar2, NewMenu2, SetMItem2, etc..

If it is really that much of a problem, you probably just need help. I'll
bet the resource gurus around here would be more than willing to pitch in
if you were man enough to ask for advice.

Todd Whitesel
toddpw @ cco.caltech.edu