🚀 go-pugleaf

In article <73@richsun.UUCP> kenk@richsun.UUCP (Ken Konecki) writes:
>In article <658@hscfvax.harvard.edu> xmjschm@hscfvax.harvard.edu (MJSchmelzer) writes:#>Then it said to run ***BinHex 4.0*** on the file!!!
#>4.0 and 5.0 and knows they're totally different animals.

#Errr, um, I consider myself remotely familiar with BinHex  and  I
#have  no  clue  as  to  the difference between 4.0 and 5.0. Could
#someone enlighten me?

The difference is so great that there is really no relationship.
Or how about:
	binhex4 is like:
		uuencode; mail
	binhex5 is like:
		ftp binary

That really covers it but is actually wrong, sorta.

More detailed analysis:

The macintosh file is composed of a resource fork, a data fork, and
header/directory information.

binhex4 took that information, and passed it through a binary to ascii
transformation. It also checksums each fork, and the header.

binhex5 takes that information, places the header/directory information
in a particular order in the first 128 bytes (padding to 128), then
concats the two forks (data first) after it. Note, there are no
checksums.

The receiving program knows how to undo either, and in the case of binhex4,
verify.

binhex4 could be used by {cat,type} file, and ascii capture, a common
mechanism in the dark ages (a mere 2-3 years ago 8-)), because it
provided a verification. It even ignored headers (there was a bug here,
I recall, which promoted some bug releases), and trailers.


binhex5 expects a reliable protocol transport mechanism to be used.
^^^^^^^^^^^^^^^^^^^^^^^^^^ PERIOD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I hope this answers the question.

-- 
uucp:     {decwrl,uunet}!eda!jim        Jim Budler
internet: jim@eda.com                   EDA Systems, Inc.