xmjschm@hscfvax.harvard.edu (MJSchmelzer) (11/05/88)
HELP!!!!!
Has anyone actually READ Simtel20's "information" file??
(For those who just tuned in, SIMTEL has changed its archives
to a binary format to save space and time. I do not have any
problem with this, by the way :-))
Anyway, it suggests (after getting the file from simtel) using
kermit in Binary Mode and download the file into the Data Fork.
Then it said to run ***BinHex 4.0*** on the file!!!
Anyone even remotely familiar with BinHex knows the difference between
4.0 and 5.0 and knows they're totally different animals.
So anyway, I decided to try 4.0 on it anyway (knowing full well it
would fail, of course :-)) and it choked as expected.
Next I said, "Okay, let's try 5.0 on it..." But found that I had
long ago discarded all copies of 5.0 as useless wastes of space.
"No problem," I thought. "I'll just get binhex5.hqx from sumex or
simtel or whatever." Alas alack, binhex5.hcx is the only thing there
that's close. (They did have binhex5.bas but I don't have basic.)
So I decided a different tack. I got all the files dealing with
MacBinary and Unix, hoping to find something that would run
the MacBinary transfer protocol. No dice. Lots of stuff about the
hopelessly antiquated macget, macput, and that wonderful format they
use (filename.rsrc filename.data and filename.info ). But nothing
to run a MacBinary transfer on my Unix host. Not even anything to
convert something to BinHex 4.0 so I could download it.
I'm at the end of my rope.
I need one or more of the following:
1. BinHex5.hqx : some kind soul could BinHex 4 their BinHex 5 and
send it to me
2. tobinhex4 : (this doesn't exist as far as I know)
A program that would take my MacBinary file and
make a BinHex 4.0 file out of it.
3. MacBinaryPut : (again, this doesn't exist as far as I know)
A program that would perform a MacBinary transfer
in conjunction with, say, VersaTerm
(Then I'd have to get VersaTerm ,but that's ok. I've
been meaning to anyway :-) )
4. mctrans : This would work with the Tin Can terminal emulator.
Are there any unix versions that could handle a binary transfer?
5. Whatever I'm not understanding here.
Thanks in advance, all net people.
("No thanks neccessary, just doing our duty. All in a day's work" :-) )
--
============== xmjschm@harvspha.BITNET ============= "Your soul is mine,
Mike Schmelzer xmjschm@hscfvax.harvard.edu fork it over."
===================================================== - Salem 66kenk@richsun.UUCP (Ken Konecki) (11/07/88)
In article <658@hscfvax.harvard.edu> xmjschm@hscfvax.harvard.edu (MJSchmelzer) writes: >Then it said to run ***BinHex 4.0*** on the file!!! >Anyone even remotely familiar with BinHex knows the difference between >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? Thanks, -Ken K -- Ken Konecki kenk@richp1.UUCP -or- ...!uunet!richsun!kenk "A squeegee by any other name wouldn't sound as funny"
jim@eda.com (Jim Budler) (11/08/88)
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.