🚀 go-pugleaf

Hmm, let me try to simplify the problem.

     Since most of this conversation happens because of the
introduction of Un*x flavored facilities, I will try to explain in Un*x
terms.

     When people produce programs, especially in C, on Un*x systems
they tend to do them in multiple source files, usually with a
'makefile' (command file for the make utility, but make is another
article (:-) which depends on the files having the right names and
being in the right places.

     To mail these files around to other users on the net, the source
files are placed in encapsulated form.  However, simply stacking them
all together in one file leaves the recipient with the problem of
unpacking that file into all of the smaller files.

     So, a format called shar (short for shell archive) was invented,
which is simply to encapsulate each of the files into a huge shell
script (Un*x command file) which the recipient simply feeds to the
shell to get all of the files where they belong.

     To simply the process even further, there are number of public
domain Un*x utilities floating around which will do the packaging for
you.

     A related problem is that some mail systems have an upper limit on
the size of a mail message they will transmit.  This leads to the '1 of
n' mail messages you sometimes see (like the source for uEmacs.)

     The problem with just sending sources is that not everyone will
have the compiler that you used to produce the software.  (I for
instance don't have any C compiler yet, having not figured out which
one to buy (:-()  So some people will send the executable image.

     Since the executable is binary data, any byte in it can have any
of the legal values from 0 to 255 (assume unsigned) but the ASCII
character set is officially only from 0 to 127 and many implementations
will strip off the high order bit when sending data over terminal
lines.

     Also, many mailers have problems with 'nonprinting' (or control)
characters, some of which are treated especially.  The solution to this
problem is to encode binary files such as executable image into various
formats in which the results are all 'printing ascii' characters.

     uuencode and uudecode are opposite ends of this chain.  uuencode
encodes the file (the 'uu' is because they were intended to be used by
uucp on unix systems) and the uudecode decodes them on the other side.

     uuencode also calculates a checksum which uudecode checks. This
gives you some assurance that nothing went wrong with the file (like a
bit getting flipped by a noisey modem) during transmission along the
mail system.

     Another complexity which you didn't mention is how you get the
file from the mail system or buletin board computer to your ST.  There
are two (or more?) competing mechanisms for transfering files, both of
which were designed to get around limitations and problems in using
terminal (RS232) lines to transmit data.

     The first is the *MODEM (for * = x, y, z) family of protocols,
first invented by Ward Christians in the early '70s for use between
microcomputers.  There are public domain XMODEM programs for most
computers, as well as XMODEM facilities included in most 'communication
programs'.  If you want to get files from buletin boards, you'll
probably need XMODEM, since most buletin boards use it.

     The second is KERMIT, a protocol invented at Columbia university,
and placed in the public domain.  Again, there are KERMIT
implementations for most computers, and some of the communications
programs include the KERMIT protocol.

     If you try to get files off of buletin boards you will also
discover that there are alternatives to shar for archiving, to
uuencode/decode for decoding, and all about tools for file compression;
but that's for another discussion (;-)

     Hope this helped more than it hurt.

Marty

----------