Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!ntg!dplatt
From: dplatt@ntg.uucp (Dave Platt)
Newsgroups: comp.sys.mac.misc
Subject: Re: Really detailed Binhex format info ??
Message-ID: <45@goblin.ntg.uucp>
Date: 6 Apr 91 00:24:05 GMT
References: <1991Apr04.114105.6198@dit.upm.es>
Reply-To: dplatt@ntg.UUCP (Dave Platt)
Organization: New Technologies Group, Inc.  Palo Alto CA
Lines: 80

In article <1991Apr04.114105.6198@dit.upm.es> esink@turia.dit.upm.es writes:
>
>Basically Sande states that StuffIt's 'binhex' encoding is not the
>same as BinHex 4.0, even though StuffIt inserts the standard header
>
>(This file must be converted with Binhex 4.0)
>
>on things it encodes.  I find this thought intolerable; so much so
>that I have wondered if it is true or not.  I sent mail to Sande
>some time ago, asking for further evidence.  What I think Sande said
>is that the StuffIt encoding of a file does not match the Binhex 4.0
>encoded version.

Sande's observation (that the two programs create different encodings)
is correct.  Sande's conclusion that the two encodings are incompatible
is _not_ correct.  Sande jumped to Conclusions (and, as Milo found out,
it's easy to do but you must usually swim back ;-)

>After studying the Binhex file format, I realized that such a
>match is not necessary.  Due to run-length encoding, different
>Binhex encodings of the same file are conceivable.

And, in fact, this is precisely the reason that BinHex 4.0 and StuffIt
do not produce identical encodings.  BinHex 4.0 implements run-length
encoding.  StuffIt does not use run-length encoding when it hqxifies
a file.  Hence, the encodings differ.

However, _both_ of these programs can correctly decode a file produced
by the other, since both of them _do_ implement the run-length decoder.
It doesn't matter to _either_ decoder whether the input file uses RLE or
not.

>                                                      The real
>test should be :  can Binhex 4.0 and StuffIt decode each other's
>coded files correctly, every time ?

Yes, with one exception that I'm aware of.  There's a bug in the decoder
in BinHex 4.0 and BinHex 5.0, which causes problems if the name of the
encoded file is between 27 and 31 characters long... the decoder loses
sync with the file, reports a CRC mismatch in one of the two file
forks, and scrambles the decoded file.  This will occur even if BinHex
4.0 was used to do both the encoding and decoding... it's not due to an
incompatibility between StuffIt and BinHex.

>
>Does anyone know the details of the file formats and algorithms
>used to encode/decode said formats which are used by these two
>programs ?  Can anyone verify whether or not these two tools
>are or are not compatible ?
>
>Suspicion tells me they are...

Your suspicion is correct.  These two tools are compatible with one
another, and with quite a few other tools which have been engineered to
mimic the BinHex encoding.  "xbin" and "unxbin" and "mcvert" are
available on Unix, and at least two desk-accessory decoders are
available on the Mac.  As far as I know, Yves never officially posted
the documentation for the BinHex encoding... it has been successfully
reverse-engineered by a number of people.

I've even implemented a BinHex encoder myself, as part of a mail-agent
which acts as a front-end for uupc 2.1 or Mac/gnuucp 4.3, so I can
simply issue an "Attach binary file" command when composing a message,
and have the file converted to ASCII and appended to the message
"automagically".  It's not terribly hard to do.

However, I chose _not_ to implement the run-length encoding... following
Ray Lau's lead in this respect.  RLE doesn't buy you all that much in
many cases... especially if the file in question has already been
processed through a compression utility such as StuffIt or Compactor.
The run-length encoder is a rather gnarly thing to implement, due to the
amount of state information that must be kept around, and the
interactions between the 8-to-6 encoder, data/resource fork gobbler, and
ASCII line builder.  Writing a run-length decoder is a good deal
simpler (and is _not_ optional if you want to be BinHex-compatible!)

-- 
Dave Platt                                                VOICE: (415) 813-8917
                    UUCP: ...apple!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303