Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!goya!turia.dit.upm.es!esink From: esink@turia.dit.upm.es Newsgroups: comp.sys.mac.misc Subject: Really detailed Binhex format info ?? Message-ID: <1991Apr04.114105.6198@dit.upm.es> Date: 4 Apr 91 11:41:05 GMT Sender: @dit.upm.es Reply-To: esink@turia.dit.upm.es () Organization: Dept. Ingenieria de Sistemas Telematicos, dit, upm, Madrid, Spain Lines: 71 Nntp-Posting-Host: turia.dit.upm.es The following is copied from file-formats.txt, which I obtained from sumex (I have retained only some sections of her paper): ---------- Date: Tue, 22 Jan 91 17:08 CDT From: "Sande Nissen (CompuCtr, SoftServ)" After several days of intensive detective work, I have come to a point where I believe I can explain the BinHex/MacBinary/.hqx confusion. Some of the earliest information may be incorrect because the truth is lost in the clouds of ancient Machistory. Yves Lempereur, a programmer for Mainstay, specified an "Hqx7" encoding scheme and developed the free program BinHex version 4, which uses a filename extension of ".Hqx". Thus the first standard was born. The Hqx7 protocol not only pastes together the data and resource forks of a file, it also converts the 8-bit ASCII into a 7-bit format that can be transferred (and even mailed) across all networks. Because of the widespread use of Lempereur's free utility, this Hqx7 protocol is sometimes called "binhex" encoding. At some point, the author of StuffIt, Raymond Lau, apparently saw a need for a 7-bit encoding of StuffIt archives. (I could not find any information on what prompted this decision.) He added to StuffIt the ability to encode and decode what he called "binhex" files, which expected a filename extension of ".hqx". Unfortunately, he introduced a serious problem in the process: his 7-bit ".hqx" encoding is _different_ from the old BinHex version 4 Hqx7 protocol, despite the fact it has the same extension and common name! Even more unfortu-nately, one of the largest Macintosh software collections in the country, the Info-Mac (sumex-aim) archives at Stanford University, adopted StuffIt's hqx variant as their only acceptable standard. Thus the third standard was born. Sande Nissen Computer Center Carleton College 12/31/1990 ---------- 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. 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. The real test should be : can Binhex 4.0 and StuffIt decode each other's coded files correctly, every time ? 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... Eric Eric W. Sink | Putting the phrase |All opinions Departamento de Telematica | "Frequently Asked" |are mine and Universidad Politecnica de Madrid| in your kill file is |not necessarily esink@turia.dit.upm.es | not recommended. |yours.