Re: what are .sdk archives?

[Gregory Weston <uce@splook.com>]

In article <okDcj.13327$_o6.5019@trndny06>,
 "Charlie" <charlieDOTd@verEYEzon.net> wrote:

> "Gregory Weston" <uce@splook.com> wrote in message 
> uce-80E76E.17091026122007@comcast.dca.giganews.com">news:uce-80E76E.17091026122007@comcast.dca.giganews.com...
> > In article <SOycj.17006$HQ6.14297@trndny01>,
> > "Charlie" <charlieDOTd@verEYEzon.net> wrote:
> >
> >> "Michael J. Mahon" <mjmahon@aol.com> wrote in message
> >> t56dnerBrK49gu_anZ2dnUVZ_jidnZ2d@comcast.com">news:t56dnerBrK49gu_anZ2dnUVZ_jidnZ2d@comcast.com...
> >> >
> >> > Snip <
> >>
> >> > Have I mentioned how much I wish the Mac would not add forks to
> >> > files that don't have them?  ;-)
> >> >
> >> > -michael
> >>
> >> I agree and for that matter I never understood Apple's obsession with 
> >> forked
> >> files.  They seem to serve no useful purpose and in fact only complicate
> >> things.
> >
> > They serve the purpose of providing a mechanism to attach arbitrary
> > ancillary data streams to a directory entry without polluting the
> > primary stream, which may be a standard, commodity format.
> 
> I'm hard pressed to see that as a "useful" purpose.

And yet every major OS under active development today (as well as more 
than a few defunct ones) ships with a recommended file system that 
includes it.

The power comes not from being able to *write* the arbitrary streams of 
information, but from being able to read them back again and do 
interesting things like filtering. BeOS, for example, included a file 
system interface that let the user define which of the arbitrary named 
forks would show up in a list view. Mail messages were simple text 
files, with several header fields replicated into external named 
streams, stored in a folder configured to show those fields. Right in 
your file system windows, you could sort by the sender, or the date 
sent, or the priority ....


> > The
> > implementation details of the Macintosh resource fork are increasingly
> > anachronistic, but the abstract benefit of forks is something that most
> > vendors seem to be agreeing on lately.
> 
> I suppose I'm just dense, but I don't see any abstract or real benefits to 
> resource forks.

The benefit to the traditional Mac resource fork specifically was that 
it provided a standardized method of modularizing application and data 
files such that on a resource-starved machine you could load things on 
demand instead of all at once. And, as noted earlier, you could augment 
data files without actually compromising the structure of the data 
stream. An excerpt from Bruce Horn's discussion of the Resource Manager:

"The Resource Manager was a solution to several problems: managing 
dynamic data for the Finder; factoring out localizable information 
(strings, icons, and so on) from applications, and finally, managing 
memory use as frugally as possible."

More, including unexpected benefits, here:

<http://folklore.org/StoryView.py?project=Macintosh&story=The_Grand_Unifi
ed_Model.txt>

> > And for what it's worth, the only situation I can recall Mac OS adding a
> > resource fork to a file that didn't already have one is when the user
> > pastes a custom icon onto a file.
> 
> My experience with resource forks comes from using (and programming) an 
> Apple IIgs.  I've never used a Mac but a recurrent theme on this newsgroup 
> seems to be that it adds forks to files (disk images) that pass through it 
> on their way from the internet to an Apple II.

Probably a misunderstanding. Shouldn't be adding forks to the files, but 
it was likely tacking on a small header filled with file system 
metadata. You could think of it as an additional fork, if you wanted, 
but it was really a way for a file that came from a Mac to be robustly 
stored on a weaker file system. It wouldn't be something that "the Mac" 
did itself, but whether it happened and how the user could control it 
would be on the terms of the specific application driving the file 
transfer.