marder@rata.vuw.ac.nz (Stephen Marder) (01/18/91)
Reference was recently made in Info-Mac Digest to three new translator modules for StuffIt Classic and StuffIt Deluxe: btoa/atob; DD expand; and MacBinary (encode/decode). These are welcome additions; however, it would appear that the MacBinary module is unable to do one thing: join and decode hqx files in several parts. To do this quickly and efficiently the DA BinHqx 1.02 should be used. Can anyone confirm this? -- Stephen Marder Department of Russian Domain: marder@rata.vuw.ac.nz Victoria University of Wellington P.O Box 600, New Zealand.
johnston@oscar.ccm.udel.edu (01/18/91)
In article <1991Jan17.171813.19497@comp.vuw.ac.nz>, marder@rata.vuw.ac.nz (Stephen Marder) writes... > Reference was recently made in Info-Mac Digest to three new translator >modules for StuffIt Classic and StuffIt Deluxe: btoa/atob; DD expand; and >MacBinary (encode/decode). These are welcome additions; however, it would >appear that the MacBinary module is unable to do one thing: join and >decode hqx files in several parts. To do this quickly and efficiently the >DA BinHqx 1.02 should be used. Can anyone confirm this? MacBinary == BinHex 5.0 format. It does not support encoding/decoding multipart files. However, Binhex 5.0 format is not "hqx" format. The files created with the MacBinary encoder are given the default file name extension "mbin". Frankly, I don't know what BinHex 5.0 is used for. The BinHqx DA encodes/decodes multipart BinHex 4.0 files, as noted above. However, all versions of StuffIt support BinHex 4.0 encoding/decode as well as file segmentation and rejoining. This means that "join and decode" is a two part operation in StuffIt, so it certainly could be argued that the BinHqx DA makes creation of multipart BinHex 4.0 files significantly easier. -- Bill (johnston@oscar.ccm.udel.edu)
peter@viewlogic.COM (Peter Colby) (01/19/91)
In article <42005@nigel.ee.udel.edu>, johnston@oscar.ccm.udel.edu writes: |> MacBinary == BinHex 5.0 format. It does not support encoding/decoding |> multipart files. However, Binhex 5.0 format is not "hqx" format. |> The files created with the MacBinary encoder are given the default file |> name extension "mbin". Frankly, I don't know what BinHex 5.0 is used for. |> -- Bill (johnston@oscar.ccm.udel.edu) Well, I use Binhex 5.0 all the time! First, Binhex 5.0 format is a raw MacBinary (I) file on the Mac. It is identical to a macbinary file on UNIX or COMPUSERVE or .... (within architectural differences). This Macbinary data is entirely contained within the data fork of the file. Binhex 5.0 does locally exactly what most file transfer programs do when downloading a binary file - it converts the Macbinary format into a real Mac format file. It will also do the reverse AND it will decode Binhex 4.0 format as well. As to how I use it... I get a Mac file onto my local SparcStation at work (usually via ftp over the internet.) If this file is in hqx format I use mcvert to convert it to a binary file. I then use binary mode ftp to move the file onto a PC (Novell Netware) file server which I can access directly from a Mac which is also connected to the Novell server. I can then use Binhex 5.0 to convert this binary file on the Novell server to a real Mac file anywhere the mac can access. Simple, eh! ftp ftp source ----> SparcStation -----> IBMPC MAC \ / \ / \ / \ / file server Peter C -- (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O) !the doctor is out! (O) (0) peter@viewlogic.com (0) (O)(O)(O)(O)(O)(O)(O)(O)(O) (O)(O)(O)(O)(O)(O)(O)(O)(O)
jimb@silvlis.com (Jim Budler) (01/21/91)
In article <42005@nigel.ee.udel.edu> johnston@oscar.ccm.udel.edu writes: >In article <1991Jan17.171813.19497@comp.vuw.ac.nz>, marder@rata.vuw.ac.nz >(Stephen Marder) writes... [...] >MacBinary == BinHex 5.0 format. It does not support encoding/decoding >multipart files. However, Binhex 5.0 format is not "hqx" format. >The files created with the MacBinary encoder are given the default file >name extension "mbin". Frankly, I don't know what BinHex 5.0 is used for. BinHex 5.0 is the program that introduced MacBinary. Back in the dark ages of Macintosh telecommunications, a man named Yves Lempereur developed BinHex 1,2,3,4 and 5. He is a principal of Mainstay and gave these programs to the world. Usenet, having mail links that cannot transfer 8 bit data chose to remain at the BinHex 4.0 level. For those who care about the history, BinHex 1 encoded the three parts of a Macintosh file in ASCII, similar to uuencode. (three parts = data, rsrc, and info). BinHex 2,3 and 4 added better binary to ASCII maps, and some forms of data compresssion. BinHex 5.0 abandoned any attempt at binary to ASCII encoding because it was no longer needed on the commercial networks. Yves proposed it as a standard, and it was accepted by a committee composed of sysops from several networks and terminal program vendors. This became MacBinary. Later it became MacBinary I, when a similar committee voted on a downward compatible extension called MacBinary II. New capability was mainly the addition of the new Finder flags in the header introduced with MultiFinder. Back to the original statement: "Frankly, I don't know what BinHex 5.0 is used for." Frankly, I'd be surprised if it's used for anything. Most modern terminal emulators on the Mac provide the function. Most provide the newer MacBinary II. However, don't count it out totally. If you used something like 'mcvert' to create MacBinary files on your Usenet host, downloaded them to a PC, carried them by floppy or something to your Mac, MacBinary 5.0 could decode them, only losing some of the newer Finder flags like 'MultiFinder Aware'. >-- Bill (johnston@oscar.ccm.udel.edu) jim -- __ __ / o / Jim Budler jimb@silvlis.com | Proud / / /\/\ /__ Silvar-Lisco, Inc. +1.408.991.6115 | MacIIsi /__/ / / / /__/ 703 E. Evelyn Ave. Sunnyvale, Ca. 94086 | owner