> 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).

All in all, i'd say it was bloody cool, especially for its time.

The closest analog I can think of in UNIX (and this isn't a good one)
is, say, the X app-defaults mechanism.


(I spent ... a lot of time as a Mac hacker before I even discovered
the existence of UNIX...  Imagine my surprise when I discovered PIC
code in UNIX and its apparent "specialness," then realized eventually
that that was what the Mac had done all along...  8-)



chris