🚀 go-pugleaf

Pleas for help are a regular occurrence in this newsgroup.  Would it be
appropriate to post on a monthly basis some kind of help file?  I have
composed such a file which I send to some who ask such questions.
Should this document, possibly with some revisions of course, be considered
for monthly posting?

Because the purpose of this idea is to reduce net traffic, please mail
any responses.

Doug Moore (moore@svax.cs.cornell.edu)

Mac help:
Mac binaries come in "Binhex4" format.  This format (yes, there was a
Binhex 3 and there is a Binhex5, too) allows the transmission of
binaries over 7-bit lines.  Essentially, it takes every 6 bits and
converts them to some printable character; it also encodes Finder
information not intrinsically part of the file (creator, type, etc.)
and does a bit of run length encoding to save a bit of space.  The
Binhex4 format evolved from a shareware program called binhex, but
several programs now exist that can handle the format.  Binhex4
format is essential because some parts of the net can only handle
7 bit wide messages.

Because many postings consist of several related files, people
have developed programs to pack files into collections for transmission
as a group.  The first of these programs to be widely used in the Mac
world was Packit, by Harry Chesley.  Packit I did little more than
concatenate the files.  Packit II used Huffman compression to save space.
Packit III allowed encryption.  All were shareware.  When you see a file
with the .pit suffix, it is a likely to be a PackIt archive.

Raymond Lau's Stuffit has largely superceded Packit.  It uses the
more sophisticated Zempel-Liv compression scheme to save more space
than Packit.  Stuffit archives are considerably more flexible than
Packit archives as well.  Stuffit archives usually have a .sit suffix.
In addition, Mr. Lau has built into Stuffit the ability to encode and
decode binhex4 files and to unpack Packit files.

If you have a complete binhex file on your Mac and you have Stuffit,
you are ready to roll.  Now, let's consider things at the other end.

A 5-part binhexed stuffed file comes across comp.binaries.mac.  Why
5-part?  Because some mailers can't handle >64k messages, that's why.
First, you save them to a file or files.  Personally, I type
wm game.hqx
in rn, because I have an .rnmac file that equates wm to w ~/mac/hqx/.
The first time I issue this command creates game.hqx and subsequent
times concatenate the new pieces to the end of the old.  I have to be
sure to save the pieces in the proper order; pieces occasionally arrive
out of order.  When I have collected the pieces, I have two basic options.
Either I get the binhex file (with a few mail headers in the middle of it)
to my Mac and use Stuffit to decode (Stuffit is supposed to ignore the mail
headers, by the way), or decode on the host and send the result to my
Mac.  The second option is the one I use, and requires some explanation.

My connection to the host I use is 8 bits wide, and I see no reason to
to the downloading with an extra 33% overhead.  There is an 8-bit
protocol, called MacBinary (or binhex5) that several terminal emulators
support that allows the terminal program itself to install the downloaded
program so that, for example, the icon for the game I download appears
on the desktop when I quit the terminal program, without me running
some conversion program on the Mac.  The problem then is to convert
binhex4 files to macbinary files on my host computer.  Happily, there are
programs that run on my host system to do this.  I wrote one called mcvert
that meets my needs.  It's fast, it strips out mail headers, it can unpack
(but not unstuff) files as it goes.  It creates a macbinary file.
I then use xmodem and Versaterm to do a macbinary ymodem transfer to
my Mac.  I could instead, if I chose, use kermit for the macbinary
file transfer.

Xmodem and kermit are the two most common file transfer protocols
for micros, and most bigger computers have one or both capabilities.
The original Mac communications program, MacTerminal, had its own
version of xmodem that was slightly different.  One mac sent a
file to another by 3 separate xmodem file transfers, one for the
resource fork of the mac file, one for the data fork, and one for
the finder info.  A pair of programs called macget and macput
were written in 1984, by Dave Johnson of Brown University, to make a host
machine act like a mac, so that when a mac sent "foo" to a host computer,
the host created files foo.rsrc, foo.data and foo.info.  A program called
xbin allows a binhex4 file to be converted to its .data, .rsrc and .info
components.  Before macbinary, therefore, I would manually strip
out mail headers, xbin the result, and macput the resulting triple of
files to my mac.  After macbinary, someone wrote a utility called macbin to
convert a triple to a macbinary file.  There are also utilities out there
to automatically filter out mail headers, to unpack files, and to unstuff
files.  I wrote mcvert to avoid having to go through all those steps.

My personal procedure, then, is to save the binhex4 pieces together in
a file, mcvert that file, xmodem the result to my mac, and unstuff
if required.  This is the method that minimizes the time spent
downloading.

Free Mac programs come from a lot of places.  Besides the non-profit and
for-profit computer networks, there are archives on the ARPAnet if you can
access them.  The directory info-mac at sumex-aim.stanford.edu is a pretty
good source, although it is cluttered with a lot of outdated stuff and isn't
well organized.  The directory mac at rascal.ics.utexas.edu is sparser, but
better-organized.  Some of the files at rascal are in MacBinary format, so
be sure to use binary ftp to get those files.  There is also an archive at
simtel20.arpa that I haven't tried yet.  They all allow ftp access to user
anonymous (that means you).  They'd probably appreciate it if you did most of
your browsing in the middle of the night.

I hope this has been helpful.  If any points are unclear, or if I can
send you anything to get you started, please let me know.