xmjschm@hscfvax.harvard.edu (MJSchmelzer) (11/07/88)
Thanks to all, especially to ...
_____________________________________________________________________________
Walter C3arlip c3ar@zaphod.uchicago.edu
(the "3" is silent) c3ar%zaphod@UCHIMVS1.bitnet
_____________________________________________________________________________
... who sent me BinHex5.hqx
A lot of the replies indicate a bit of incorrect information going about
so let me clarify.
BinHex4 : encodes and decodes .hqx files
BinHex5 : encodes and decodes .bin (MacBinary) files
decodes .hqx files
Note that BinHex5 has a different icon than 4, but you probably won't
see it because it has the same creator (BnHq) as 4. Therefore, when
displaying the icon, the Finder uses the icon in the Desktop file which
is whichever BnHq your desktop saw first. oru need ResEdit to look at
both of the icons at the same time.
(I thank Yves Lemperer (sp.) for providing me with one of my first
lessons in how the Desktop works.)
Finally, "How to download a MacBinary file:"
0. get a MacBinary from simtel or sumex
1. use Kermit and download "Binary" into your "Data" fork
2. use BinHex5 (not BinHex4) on the downloaded file
3. enjoy your new program
I know VerstaTerm supports a MacBinary xmodem transfer. If your host
also supports MacBinary xmodem, you can skip step two. If your host
doesn't support any specific MacBinary protocol, it doesn't matter how
fancy your terminal program is.
And remember: If you want to use *any* file transfer protocol
(xmodem, pctrans, kermit, even spooling if you want to be technical)
**BOTH** host and Mac must understand how to implement it!
I hope this has cleared things up.--
============== xmjschm@harvspha.BITNET ============= "Your soul is mine,
Mike Schmelzer xmjschm@hscfvax.harvard.edu fork it over."
===================================================== - Salem 66c60a-1cu@web-1a.berkeley.edu (Drew Dean) (11/08/88)
The whole point of MacBinary protocol is that the host doesn't need to know that there's anything special about the file. There's (for MacBinary I, which I implemented on a non-Macintosh, so I do know what I'm saying) a 128 byte header at the beginning of the file, that contains among other things the file name, type and creator, dates of creation and modification, Finder flags, and the DATA fork length, and the RESOURCE fork length.... (For more info see _The Complete MacTutor_ Volume 2.) If a Macintosh is running a MacBinary capable program, it senses this header block and interprets the information. But if any other system is running a standard file transfer, this is just 128 bytes, with nothing special.... [Note that this is why you can run a Mac BBS on a PC, and file transfer works fine: I upload in MacBinary, the PC just stores the header, and someone comes along with another Mac, downloads the file, and it says "Oh, this file is in MacBinary format....I know what to do with that..."] So everyone, just crank up your favorite file transfer protocol, and blaze away, it's actually going to be much easier now, if you just let everything work like it's supposed to..... Drew Dean Internet: c60a-1cu@web.berkeley.edu UUCP: ...!ucbvax!web!c60a-1cu FROM Disclaimers IMPORT StandardDisclaimer;
mholden@ajpo.sei.cmu.edu (Maretta Holden) (11/09/88)
In a previous message I posted, I described several attempts to use Kermit to download a binary stuffed Mac DA from a UNIX VAX host to a Macintosh SE running Kermit 0.9(40) or VersaTerm 3.2 via both a TELENET and a direct dial connection. In no case was I able to get Kermit to work; all failures were identical - bad file address in the Stuffit 1.5.1 file list and failure to unstuff. I remember reading somewhere that some hosts introduce errors in Kermit binary download. Does anyone have any additional information on this? Maretta Holden