rosenkra@Alliant.COM (Bill Rosenkranz) (04/03/88)
-----------
i apologize if this is a real dumb question ( i know precious little about
development and environment on mac at this point).
is binHex in the public domain or is it a commercial/proprietary product?
can source be obtained? if so could it be posted in comp.sources.atari.st?
better yet: has binHex been ported to the atari? if so could someone please
post/email to me?
this is being cross-posted to comp.sys.{mac,atari.st}
thanx in advance....
-bill
p.s. i don't often read comp.sys.mac so could any responses be posted in
comp.sys.atari.st or mailed to me directly.ljdickey@water.waterloo.edu (Lee Dickey) (04/07/88)
In article <1537@alliant.Alliant.COM> rosenkra@alliant.UUCP (Bill Rosenkranz) writes: >is binHex in the public domain or is it a commercial/proprietary product? >can source be obtained? if so could it be posted in comp.sources.atari.st? >better yet: has binHex been ported to the atari? if so could someone please >post/email to me? There are probably many who use BinHex or UU{en,de}CODE without without knowing what they do, and there are probably others who do not know about the existence of the "other" encoding function. BinHex is an easy enough program to write. Its purpose is to turn a binary file into something that has only printable characters, so that it can be e-mailed over networks that might respond to control characters, and, perhaps, ( cough, gasp ) be read! Each OCTET ( 8 bit byte ) of the binary file is split into two nibbles, 4 bits each. Each nibble is used as a pointer to index into the vector "0123456789ABCDEF" with 16 elements. Thus, for each byte of the binary file, you get two hexadecimal characters. The result is a file with twice as many characters as the original file. Some people have become experts at reading this stuff. Their heads have 16 sides. They will become telephone sanitizers. :-) On the other hand, the UUencode program does an encoding that takes each set of three octets (24 bits) and produces 4 printable characters, by a rule that uses each set of 6 bits to index into a vector string with 64 elements. You can see what these are by looking at a UUencoded file. The result is a file 4/3 the size of the original. The inverse function is UUdecode. Most folks that have UUencode-UUdecode are not interested in BinHex. Probably the best functions of this type are UUE and UUD done by J-P Dumas. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@waterloo.edu ljdickey@WATDCS.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP or ...!uunet!water!ljdickey
ephraim@think.COM (ephraim vishniac) (04/08/88)
In article <1505@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >There are probably many who use BinHex or UU{en,de}CODE without >without knowing what they do, and there are probably others who do not >know about the existence of the "other" encoding function. > >BinHex is an easy enough program to write. > >Its purpose is to turn a binary file into something that has only >printable characters, so that it can be e-mailed over networks >that might respond to control characters, and, perhaps, >( cough, gasp ) be read! > >Each OCTET ( 8 bit byte ) of the binary file is split into two nibbles, >4 bits each. Each nibble is used as a pointer to index into the vector >"0123456789ABCDEF" with 16 elements. Thus, for each byte of the binary >file, you get two hexadecimal characters. The result is a file with >twice as many characters as the original file. Some people have become >experts at reading this stuff. Their heads have 16 sides. They will >become telephone sanitizers. :-) Originally (i.e., about fall of 1984), this was a correct description of BinHex (.HEX) format. Since then, the name of the program has stayed the same, but the format of the encoded file has changed repeatedly, first to .HCX (compressed BinHex) and then to .HQX (BinHex 4.0). For ASCII-encoding purposes, the format stabilized with BinHex 4.0 in 1985. BinHex 4.0: (1) uses 64 ASCII graphic characters so as to encode six bits of useful data in each 8-bit byte. (2) uses run-length compression to reduce the size of the encoded representation. (3) calculates a CRC-16 to check file integrity. (4) represents the directory information, data, and resource forks of a Mac file in a single encoded block. So, it's just a tad more complicated than Lee's posting suggested :-). For code to decode BinHex files, get a copy of xbin.c (for Unix) from sumex-aim. There's also a program there for creating BinHex 4.0 files on a Unix system, but it doesn't perform compression. I've also read comments to the effect that it's an awful hack. Looking in my copy of the <info-mac> directory at sumex, I see files called BINHEX4.BAS, BINHEX4.PAS, and BINHEX4-SOURCE-ASSEMBLY.HQX. The first two are dated July '85; the last is dated June '87. These look like promising places to start... Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"
dplatt@coherent.com (Dave Platt) (04/08/88)
In article <19093@think.UUCP> ephraim@vidar.think.com.UUCP (ephraim vishniac) writes: > > Looking in my copy of the <info-mac> directory at sumex, I see files > called BINHEX4.BAS, BINHEX4.PAS, and BINHEX4-SOURCE-ASSEMBLY.HQX. The > first two are dated July '85; the last is dated June '87. These look > like promising places to start... > I suspect that the .BAS and .PAS files won't get your very far. If these are what I think they are, they're MS-Basic and Mac Pascal programs that, when executed, will create a copy of the BinHex 4.0 application on your disk; they were created by feeding BinHex 4.0 into an application called MakeMakers. They were posted on SUMEX for the benefit of people who didn't have any version of BinHex, but did have one of the two language processors. The assembly-language code, on the other hand, could very well be what you're looking for. -- Dave Platt VOICE: (415) 493-8805 USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net
870158a@aucs.UUCP (Benjamin Armstrong) (04/08/88)
In article <1505@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >BinHex is an easy enough program to write. >Each OCTET ( 8 bit byte ) of the binary file is split into two nibbles, >4 bits each. Each nibble is used as a pointer to index into the vector >"0123456789ABCDEF" with 16 elements. >On the other hand, the UUencode program does an encoding that takes >each set of three octets (24 bits) and produces 4 printable characters, >by a rule that uses each set of 6 bits to index into a vector string >with 64 elements. If we are talking about the BinHex I'm familiar with (BinHex 4.0) the encoding scheme looks more like what you have described as "UUencode" than what you call "BinHex". Despite the misleading name, BinHex 4.0 does not encode binary files with the above hex encoding scheme. Take a look at one of the files in comp.binaries.mac for yourself. The code uses a subset of printable characters which looks like it may consist of 64 elements. Does BinHex 4.0 use the UUencode encoding rule? -- Benjamin Armstrong at Acadia University, Wolfville N.S. UUCP: {uunet|watmath|utai|garfield|mnetor}!dalcs!aucs!870158a | In quest of BITNET: 870158a@Acadia | a cure for INTERNET: 870158a@ACADIA.BITNET@CUNYVM.CUNY.EDU | technophobia...
ljdickey@water.waterloo.edu (Lee Dickey) (04/08/88)
Several have written to tell me about marvelous advances in BinHex that include larger character set (64 instead of 16) and cyclic redundancy codes (CRC). Thanks all. I was outdated. No more mail on this topic, please. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@waterloo.edu ljdickey@WATDCS.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP or ...!uunet!water!ljdickey