🚀 go-pugleaf

In article <60564050@sloppy.rt66.com>, "sloppy" <sloppy@rt66.com> wrote:

> David Findley wrote in comp.sys.powerpc about "Re: Macintosh Resource Forks
> and the BeBox":
> 
> > The resource fork is just an ordered sequence of bytes, exactly like the
> > data fork.  In a single fork file-system, the catalog entry of a file
> > contains a pointer to the first block of the file (among other things),
> > in the MacOS filesystem, there are two pointers instead of one (again,
> > among other things).
> >
> > The difference is that there are routines in ROM for managing the
> > resource fork as a kind of mini-database, and all applications
> > (including the Finder) tend to make use of this.  Of course, you can
> > access the resource fork directly byte-by-byte and use it as just
> > another data fork if you want.  Since there is already a data fork
> > provided for flat access, most (if not all) apps use the resouce fork in
> > the way that it was intended; there is really no need to do otherwise.
> >
> > David Findley davidf@kepler.umsl.edu
> 
> (Sorry, this is getting a little off-topic for the BeBox, and definately
> off-topic for the PPC chips...)
> 
> It seems to me like a resource fork is just a file with a very standardized
> structure, like IFF.

Exactly.  You can get docs to the structure free from Apple via their web site.

>  Why can't the data fork be _included_ in this
> structure?  If the file is a program, it could have an "executable" chunk.
> (Or better yet, a 68k executable chunk, a PPC executable chunk, etc.)  If
> the file is a word-processor document, it could have a text chunk.  And,
> of course, unlimited combinations.

This is exactly the way Mac applications are built (with the exception
that the PPC executable is stored flat in the data fork), the 68K
resources are with a 'CODE' tag, text resources are stored with a 'TEXT'
tag.

Unfortunately the Resource Manager was designed as a _mini_ (and I do mean
_mini_!) database manager.  There is a limit of about 2700 resources/file;
and hard limits on the size of each resource.  They had to leave someplace
for a  programmer to be free to play with any data struture they wanted,
so we got the dual-fork thing.

Generally the rule I use when programming is that Applications are free to
use the resource fork for their stuff (since Mac Apps won't run except
under MacOS anyway), but datafiles should only use the data fork for
important data, and reserve the resource fork for "user settings," such as
window position, printer settings, color preferences for the file and
such; things that don't matter on other platforms.  Works pretty well
really.  Plus I get to keep standard file formats that were developed for
and used on multiple platforms.

David Findley
s868672@umslvma.umsl.edu

> 
> Why not?  By combining the forks, we could get back to a single-fork (i.e.
> more "conventional" *shudder*) file system.  No?
> 
>    Yog-Sothoth Neblod Zin,
>       Sloppy