On Dec 3, 12:00pm, Chris G. Demetriou wrote:
> Subject: Re: more on dinode
> > You know, I like that notion. Wasn't the resource fork overall extensible
> > metadata for all sorts of things? Normally what Unix would put into stack
> > based per process environment data as well?
>
> Actually, the resource fork was "everything but pure, real application
> data."  I don't think it has any analogue in UNIX, let along what
> normally goes into the process environment on the stack.
>
> The resource fork included fun stuff like:
>
> * CODE!  Yes, all of the application's code was in resources,
>   and all of it was position independent!
>
> * Icons, pictures, strings (put into resources for easier)
>   localization etc.
>
> * Various other stuff need to implement standard system packages,
>   classes of visual objects (windows, scroll bars, etc.)
>
> There was the notion of multiple open resource forks, and an order in
> which they were searched when you tried to get resources.  This
> allowed you to inherit resources from e.g. the "system" (the system
> resource fork was always open, and later in the search path than the
> application's resource fork or any resource forks the application
> opened explicitly, though that could be moved around).

This is going somewhat off-topic but it is interesting to consider Acorn's way
of doing this sort of thing, which is to make most applications (and some data)
'special' directories and the resources are just files within it (code, fonts,
bitmaps, data, etc). Certain resource filenames are magic but applications can
use anything else for their own purposes. This approach has the advantage that
it requires minimal mangling of the filesystem.

Cheers

Rob