Re: Illogical compression schemes


Subject: Re: Illogical compression schemes
From: Bryn Hughes (linux@mail.cbodycentral.net)
Date: Mon Apr 30 2001 - 13:11:42 MDT


Hi Mike,

Here's the "Why" for you:

Since Mac files have both a data fork and a resource fork, and most
of the operating systems on the net don't have any method of dealing
with that, the files to be transferred need a 'wrapper' around them
so that they stay intact. .bin and .hqx are NOT compression systems,
but rather encoding systems for the net. Most web browsers can
decode the .hqx format. Most Mac web browsers/ftp clients can decode
both .bin and .hqx files.

.sit is Aladdin's compression format. It, like the .zip format, is
pretty much the standard for compression. .sea files (self
extracting archive) can actually be several different formats, but
are usually also Stuffit (.sit) files with a built in extractor.
Now, since a .sea file is an application, it has both a data and a
resource fork. Since the resource fork would be stripped off the
file the second it was stored on a UNIX/Linux/Microsoft machine
(unless that computer was actually set up for Mac files, which I
believe only WinNT and 2K have the ability to do, and even then I
believe support for it is a little flaky) the file must be encoded
some how to maintain the self extracting part of the archive. Hence
the .bin or .hqx.

Because of this Apple has been including Stuffit Expander on their
system CDs now for several years. All new Macs come with it
pre-installed, and some Netscape installations will do it too.

Basically, the problem is the fact that the Mac uses two forks to
store files. In essence, every executable file on the Mac (plus any
variety of other data files that may happen to use resources) has two
separate pieces. Since most other OS's (or more specifically most
other filesystems) can't cope with this and have no method for
tracking the two pieces of the file, the file gets mangled in
transit. Mac filesharing on Linux (specifically Netatalk) deals with
this by creating a hidden folder called .AppleDouble in each
directory that holds files with a resource fork. The resource fork
part of the file is stored in the .AppleDouble directory with the
same filename as the data fork piece.

I don't know what OS version Apple actually started including Stuffit
Expander, I don't see it on my 7.6.1 CD so I think it started some
time around 8.0 or 8.1.

Bryn

>Hi,
> It's me, everyone's favorite Mac illiterate. I still haven't given
>up trying to put Linux on this PPC. I got Appletalk sharing to work
>between the PPC and a Linux box so I can now easily transport files to the
>PPC. Now the trick is *using* them.
>
> Let me see if I have something straight about Macs:
>
> Most of the Mac files and programs you can obtain on the internet
>are available in either MacBinary (.bin), BinHex (.hqx), or Stuffit
>(.sit) formats, right? And you need Stuffit or a comparable program in
>order to decode any of these three formats, right? And all such programs
>are distributed in either .bin, .hqx, or .sit format, right? I just wanted
>to make sure I'm not missing anything before my head explodes from the
>paradox...:) I see that there are self-extracting archives (.sea) files
>which the MacOS can actually handle natively, but can I even download a
>simple .hqx decoder in .sea format? Windows seems to have this
>self-extracting executable idea down pretty well; why is it so difficult
>on a Mac?
>
> And I can't seem to find any of these basic compression utilities
>on the CDs that came with my system (MacOS 7.6 and PowerComputing software
>CD). And this is a fresh MacOS install so I'm left with nothing.
>
> I hope you all find this challenge as amusing as I do...:)
>--
> -Mike Melanson



This archive was generated by hypermail 2a24 : Mon Apr 30 2001 - 13:12:41 MDT