TOADUU.DOC

Author:		David Kirschbaum, Toad Hall
		kirsch@usasoc.soc.mil
		(See Credits below)

Function:	UUE.COM: Uuencode binary files to ASCII text files.
		UUD.COM: Uudecode uuencoded files to original binary form.
		Both are compatible with the Unix (and other) uuencode/
		uudecode utilities.

Usage:		UUE.COM:
		  UUE<RETURN>
		    Displays usage message, prompts for input file name.
		  UUE [-o ][d:][\path\]filename.bin
		    Produces filename.uue in current directory.

		  If you recompile, enabling the STDOUT switch,
		  redirection is enabled, requiring the following:
		  UUE [d:][\path\]filename.bin [>filename.uue]
		  Uuencodes filename.bin, sends uuencoded product to
		  standard output (console) or wherever redirected.

		UUD.COM:
		  UUD<RETURN>
		    Displays usage message, prompts for input file name.
		  UUD [-o ][d:][\path\]filename.uue
		    Produces a uudecoded file, with the filename taken from
		    within the uuencoded file (which might include a path).

|		  Both programs will not overwrite existing files unless
|		  you use the "/O" (or "/o") switch.  (Not applicable
|		  for the STDOUT UUE, of course.)
|		  Both programs have a "/?" (or "-?") switch that will
|		  write a brief help screen to STDOUT and terminate.

		Both programs accept an input path\filename up to 80 chars
		long, and will prompt if none is specified.

		A uuencoded filename is created by stripping the ".typ" (if
		present) from the original filename and appending ".uue"
		as the file type.
		A uudecoded filename is taken from the uuencoded source file
		and is written to the current directory (or to the path
		included in the file header).

		You can recompile UUE.ASM to send output to the DOS standard
		output ('>wherever') if you desire.  (It's currently compiled
		as UUE.COM to produce "filename.uue".)

		Input files may be any length.

		When using UUD to decode uuencoded files:
		    Uuencoded file headers (mailing headers, etc.) need not
		  be removed.  However, any spurious lines between the
		  "begin" and "end" lines MUST be removed.
		  Anything beyond the "end" line is ignored.
		  If no "end" is found, the output file is saved,
		  but an error message is displayed.
		    Certain uuencoders append a "checksum" character to the
		  end of each uuencoded line.  UUD ignores these.
		    Uuencoded files generated or moved through a Unix system
		  may have LF (ASCII 10) line endings instead of the DOS-
		  convention CR/LF (ASCII 13/10) endings.  UD will handle
		  those LF ends of line as well.  You MAY get a "end not
		  found" message, but the uudecoded file will be intact.
		    Certain systems and mailers will strip off trailing
		  spaces on lines.  UUD now attempts to replace them.

Credits:	Credit to Theodore A. Kaldis (kaldis@topaz.rutgers.edu),
		the original author of UU.ASM (the source and inspiration
		of this code.
		UUD is basically his UU, SEVERELY tweaked!  However, since
		it significantly resembles UU, Theodore's copyright
		constraints apply.
		UUE is my own, so I freely release it to the public domain.


UUE

v2.0, 10 Mar 91
- Keith Petersen asked that the "no overwrite" feature from TOADXX
  be incorporated in the TOADUU family.  Done.

- He also reported a problem with "no cmdline filename" handling,
  usage reporting, filename prompting, etc.  Cleaned up, fixed.
  Added the "-?" help just to be nice.

- Error msgs now to to STDERR (like TOADXX).  Except for the
  "< DOS 2.0" error and "-?" help, which both are displayed
  via Svc 9, INT 21H anyway).

v1.9, 29 Jul 89
- Changes all in UUD, but bumped UUE's version number
  just to stay in synch.

v1.8, 5 Jul 89
- Version number bumped to v1.8 (skipping v1.4 thru v1.7)
  just to get in synch with the companion uudecode program.

- Thanks to Karl-L. Noell <NOELL%DWIFH1.BITNET@CUNYVM.CUNY.EDU>
  for two bug reports:
    1 - Target filename prompt bug:

|  When I call up UUE12 or UUD17 without filename, a prompt appears:
|  Input path/file:
|  but answering to that prompt always yields the message
|  "Input file error."

  Dumb error, fixed.

    2 - Excessive uuencoded line length at the 45000-byte input point:

|  There is one effect, but it doesn't cause any harm:
|  when I uuencode large binary files, the resulting *.UUE always has
|  line 1001 3 bytes longer as you'll see from the following cut:

|  Line
|   1000:  M!)(0A")3S,<EVET'2%/THAT7@AOB$0AIY[+*1@)6S(I<)",-ZPD(\J`JAWPH
|   1001:  P1SJAV\VFJ+/YP6:,0$$!-Q]T0J?D3%2F<XHO2V>&.=RN#%OYP!:<(H8\P$9*F"E#
|   1002:  M%UA5L3N,TR%C\*86_8E$%!#4(E(JYY.BA$XSJ-.2`72G;K82@GDBQ9YEP"=S

|  Obviously it has to do with your "READSIZE 45000" which is reached in
|  that line (1000 lines * 45 bytes).  Anyway the UUDECODE works fine, I've
|  tried it with your UUD12 and with UUDECODE 2.14 .  The byte count 'P'
|  (instead of 'M') tells us, that there are 3 bytes more in this line.

  Karl-L was right .. I should've checked to see if we had a full line
  (60 chars) of uuencoded bytes BEFORE we check if our binary buffer's
  been used up.  That'll insure the full line gets written out as soon
  as it becomes full.

  The fix seems to be working fine, testing with various odd sized files
  (to include monster ones that insure that 45000-byte refill).

  Added a little logo at the end (overrun by buffers) just to identify
  the program.

v1.3
 - Wasn't handling non-MOD 3 sized source files (e.g., wrong binary count
   character in the uuencoded file for the last line).  Fixed.
 - Tweaked more for speed.

v1.1
 - Original release.

UUD

v2.0, 10 Mar 91
- Keith Petersen asked that the "no overwrite" feature from TOADXX
  be incorporated in the TOADUU family.  Done.

- Keith also reported a bug:  if the "begin 644 filename.typ" line
  is something like "begin 0600 filename.typ", UUD fails!
  He then found the bug.  Fixed.

- Keith also reported problems with "no commandline filename" states,
  usage messages, prompting for target filenames, etc.  Fixed them,
  cleaned up the logic a little, added better usage, tightened displays,
  etc.

v1.9b, 01 Nov 1989 (TapirSoft, Gisbert W. Selke, Germany)
 - tweaked for speed, or rather, style. No noticeable increase in
   overall speed...
 - fixed a bug with file names starting with a slash (and no other slashes
   in the name) or consisting of one character only (without extension).

v1.9, 29 Jul 89 (TapirSoft, Gisbert W. Selke, Germany)
- Had a strange bug in UUD.
  In the process of fixing that, took a relook at this code
  and did a little tweaking.

v1.8, 5 Jul 89
Thanks to Karl-L. Noell <NOELL%DWIFH1.BITNET@CUNYVM.CUNY.EDU>
for a bug report:

|  When I call up UUE12 or UUD17 without filename, a prompt appears:
|  Input path/file:
|  but answering to that prompt always yields the message
|  "Input file error."

Karl-L's right .. stupid .. donno how I missed it.  Fixed.

Added a little logo at the end (overrun by buffers) just to identify
the program.

v1.7
 - Bugs weren't fixed, plus found new ones.  Turns out nothing's been
   working right since about v1.3 (and that wasn't right either!).
   - Now correctly creates an output file the same size as the original
     file before uuencoding.
   - Still handles 'truncated' lines, strips headers and trailers,
     handles End-of-line types CR/LF, CR, LF.
 - Tweaked a little for more speed.
 - 'Dynamic' sizing of input buffer (to use most of available 64K
   code segment.

v1.6
  - Stupid bugs crept in with v1.4's "pad truncated line" function.
    Fixed now.  More thanks to Brad Keister.

v1.5
  - Added ability to process uuencoded files with LF end of lines
    (from Unix systems).
  - Added ability to accept (and ignore) checksum characters appended
    to uuencoded lines.  (Had to sacrifice the ability to catch garbaged
    uuencoded lines longer than expected.)
  - Just noticed paths will work if they're part of the file name in the
    uuencoded file's "begin" line.
  - Was suggested UUD provide a default ".UUE" file type if none given.
    Not gonna do that .. my Unix uudecode doesn't, so why should I?
  Thanks to Brad Keister, P150BK19@VB.CC.CMU.EDU, for his bringing up these
  problems (mainly with the UU219.ARC package on SIMTEL and his own Unix
  host's uuencode).

v1.4
  - General tightening
  - Added checks for "truncated" uuencode files.  Some older uuencodes
    (NOT my UUE) use space characters (which can be trimmed off by various
    mailers and systems).
    If such a truncated uuencoded line is found, it's padded back to its
    original length with spaces.
    Thanks to Keith Petersen for that suggestion.