Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!seismo!rochester!ritcv!cci632!ccird2!rb
From: rb@ccird2.UUCP (Rex Ballard)
Newsgroups: net.micro.amiga
Subject: Re: encoded source codes
Message-ID: <786@ccird2.UUCP>
Date: Wed, 23-Apr-86 10:44:13 EST
Article-I.D.: ccird2.786
Posted: Wed Apr 23 10:44:13 1986
Date-Received: Sat, 26-Apr-86 06:26:03 EST
References: <1759@caip.RUTGERS.EDU> <436@mips.UUCP>
Reply-To: rb@ccird2.UUCP (Rex Ballard)
Organization: CCI Telephony Systems Group,  Roch, NY
Lines: 92
Summary: Pro's and Con's of encoding

Generally, encoding is done on the other groups net.micro.{mac,atari16}
for good reasons.

Encoded source is usually compressed and encrypted in order to save
space and modem time of sending text across the net.  This can be
a serious problem when extra large files come across the net and
have do be distributed to hundreds of sites.

Encoded binaries are usually used for things such as compilers and
languages, where the source is useless without the binary.  A good
example is the various forths that have binary "kernals".  These
are often followed by "forth in forth" files that allow the reciever
to modify and learn from the sources written for that binary.

Often, a binary is sent along with instructions on where to get the
"FTP sources" from.  This is useful when there are hundreds of small
files, include files, and utilities that comprise the "source".  Many
public domain projects and GNU (Copyrighted, but freely available)
projects involve as many as 4 megabytes.

When projects are "trivial", one or two messages worth of source, there
is little problem with distributing sources directly on the net.  When
a project is more substantial, 17 parts each about 64K, net
adminestrators tend to get a bit upset about the cost of sending these
all over the country.  The cost to the network is about $2/K.  There
are a few PD projects that can run 4 to 6 parts of uuencoded binary.
This would translate to about 4 meg of source.  The cost of sending
that much source to all of the net sites would be around $8,000.  An
ftp might only cost $20, less if the site is in the same phone area.

Other less valid reasons include posting of "shareware", "beta-copies",
and "preview copies" of products which will be eventually marketed
as commercial products.  Examples of this include Apple's "Switcher",
Finder upgrades, and various upgrades that might otherwise be available
"over the counter", but are "given" to the net by the copyright owner
with the understanding that the owner shouldn't be expected to give
the usual support.

Another semi-valid reason is when someone uses a non-standard or
very expensive compiler to generate the code.  In this case, if the
language used is strange, or the compiler supports certain
"non-standard" features such as in-line assembly code, passing of
structures by value, et. al., it is often preferred to send the
binary rather than the "funny source".  For example, source written
in lex/yacc or Objective C would be useless if all that was available
was Lattice C.

The worst reason is to distribute "worms", or "pirated copies" of
software.  Unfortunately, this sometimes happens, and there is
little that can be done about it.  If someone does this, flame them
via mail and via follow-up.  In some cases, these "hackers" are using
someone elses account, but at least somebody will know.

Now, assuming that the distribution of binaries is justified for these
"special cases", what are the requirements for encoding?

First, the character set must be limited to the "graphic" characters
of the ASCII character set.  This is because modems, link protocols,
and communication media across the net are very "fussy" about recieving
certain control characters, many of which will be "dropped" or goof
up the link.  Also, some links drop the "8th bit", so seven bits
is all thats safe.

Second, the encryption should pack as much information as possible
into available character set.  This is because more wasteful protocols
such as intel hex format tend to require more space.  These protocols
also have error detection which is already included in the net
protocol.  Remember, encoded binaries are intended to save space.

Third, the encryption should be simple to implement, and should be
machine independent.  The code to encode/decode should be runnable
on either the environment used to read the news, or on the micro
on which the binary will be used.  This way, the binary can be
decoded and the binary transferred via XMODEM or KERMIT, or any
other "file transfer service" available on the News feeder, but
if not available, the encoded file can be simply "captured" and
decoded on the micro.

As was mentioned before, public domain versions of uuencode and
uudecode have been posted to net.micro net.micro.atari and net.sources.
This protocol meets all three of the above requirements.  In addition,
the uuencode/uudecode supplied with UNIX work equally well on these
files.

One variation on this protocol which is a little dubious is using
the "compress" function to further reduce the size of the file.
Although this reduces the size of the files, a good "standard" hasn't
been adopted yet.

The mac group adopted binhex and apearantly use it quite effectively.
I don't know that much about this service other than that it works
for them.