Category : Utilities for DOS and Windows Machines
Archive   : UU31.ZIP
Filename : UU.DOC

Output of file : UU.DOC contained in archive : UU31.ZIP
UU version 3.1 -- A small, fast, and smart uudecoder for DOS
Copyright (C) May 1994 -- ir.drs. Benjamin J. Walbeehm

May 24, 1994

UU is shipped in a package called UU??.ZIP, where ?? is replaced by the version
number. Until further notice, whenever I have a new version of UU, I shall
upload it to
FTP : /pub/bryanw/pc
FTP : /pub/usr/zboray/coding
FTP : /pub/MSDOS_UPLOADS/uucode

Pointer messages announcing the new release will be posted to
USENET: alt.binaries.misc

In addition to the UU??.ZIP packages, I also post UU??.EXE packages to the newsgroup. These are self extracting archives,
which means that they unZIP themselves. Moreover, the UU??.EXE postings can
even be decoded by those that do not yet have a uudecoder!

If for some reason you are unable to obtain the UU package in any of the
aforementioned ways, feel free to ask me to e-mail it to you. My e-mail
address may be found at the end of this manual.

UU is a freeware program; please read the file INFO.TXT for more information
on what I mean by this. If the file INFO.TXT was not included in your UU
package, then you can obtain it by e-mailing (which is preferred), writing,
or calling (which is least preferred) me. IN SHORT, THE ONLY THING I ASK FROM

Yes, I know... This manual has become rather long... I apologise for that,
but I think that all things considered, it is best this way. Besides, nobody
has complained about it so far. ๐Ÿ™‚

I have written this program primarily for my own convenience; the first time
I downloaded (a lot of) uuencoded files from the USENET binaries, it took me
over four hours to edit everything in such a way that the only uudecoder I
had then (a very naive one) could process them. That was a once-but-never-
again experience.

Starting with version 2.3, UU runs even on 8086 and 8088 processors, so I am
once more obeying my "rule" to write programs that are 8086/8088 compatible.
(Versions 2.2 and below required at least an 80286.)

As for memory requirements: The amount of RAM free for executables should be
at least 96k for this program to work correctly: Amongst others, UU uses two
32k buffers to speed up reading and writing, as well as a 14k buffer to store
filenames of input files. UU will check if there is enough RAM free, and
complain if there is not. (I hear some people asking: "96k?"... Yes, I know
we are talking .COM here, but that does NOT mean we are restricted to 64k now,
does it?) Starting with version 3.1, UU will be even faster if there is more
than 96k free, since it will use the remaining amount of conventional RAM for
additional buffering.

I have finally figured out what the minimal DOS version is that this program
requires: MS-DOS 2.00. Since I learnt that there still are people using an
8088 based machine, and running MS-DOS 2.10, but I have not heard of any
lower versions of MS-DOS still being used, I think that (considering UU's
processor, memory, and DOS requirements) I can safely say that UU will run
on just about any PC and compatible. UU also runs flawlessly from the DOS box
under Windows... Moreover, several people have reported UU running flawlessly
from the DOS box under OS/2, and even on DOS emulators on other systems!

I suppose I should insert a line here stating that MS-DOS is a registered
trademark of Microsoft Corp.

As with all the programs I write, a short usage message is included in UU.
This message will be displayed by entering either of the following three
UU /?
UU -?

Starting with version 2.0, UU no longer displays a usage message when one
merely enters "UU". The reason for this is that I think that one should never
get accustomed to invoking a program without parameters or switches just to
get help, for there are numerous programs that really do something then. In
fact, I have written a program (REMDIR.EXE) that can (depending on whether
one really wants it to do what it does then) have disastrous effects then.
What I am trying to say is: Never rely on a program to give you help by
invoking it without any parameters or switches...

On the uuencoding standard
In my opinion, the uuencoding standard is not very well thought-out. As long
as an encoded file consists of only one section (in the early days, splitting
an encoded file up into more than one section was most probably not allowed),
there is not much wrong with the standard, but as soon as the necessity rose
for files to be split up, the standard should have been changed as well.
To start with, there is no standard way of designating non-section parts,
so the standard provides us with no means whatsoever to distinguish between
encoded sections and mere comments. Also, the standard does not describe a
way of deciding which sections belong together, nor in which order. Most
uuencoders put such additional information in the files, but with the lack
of a standard, almost every single one of them has its own way of doing this.
A number of encoders will also put one or more checksums in the file, but
again, this has not been standardised. It would have been very easy to devise
a standard for adding such additional information, but it has not been done,
and it may be far too late now...

Command line parameters and switches
Although the usage message says
UU [drive:][path]filename[.ext] [/1] [/A] [/D] [/I] [/K] [/O] [/S] ,
UU allows all kinds of variations on this: Instead of a slash ("/"), a dash
("-") is accepted as well. UU of course accepts both uppercase and lowercase,
and ignores irrelevant blanks (spaces). Also, using a switch twice or more
has the same effect as using it only once. Moreover, switches (currently, the
switches are /1, /A, /D, /I, /K, /O, and /S) may be combined, and the order
in which the filename and the switches (if any) appear on the command line is
irrelevant. This means that, for instance, all of the following commands are
treated identically:
UU example.uue /I /S
UU example.uue -I -S
Uu exAmplE.Uue/s -I
uu/s example.uue/i
uu example.uue -is
uu /is example.uue
uu example.uue /s/i
uu/i -sisssis example.uue

Please note that if the dash ("-") is used to precede a switch, it must be
preceded by at least one blank, since DOS allows dashes also to be part of a
filename. Although DOS also allows a dash as the first character of a filename
(yes!), UU will not accept an input file with such a name, so if files with
such names are to be fed to UU, then they will have to be renamed first. Since
dashes are allowed to be anywhere else in the filename, this means that the
following two commands are NOT identical:
uu temp-i
uu temp/i

The former command processes a file called "temp-i" using no switches, while
the latter will use the switch "i" on a file called "temp". So if the latter
interpretation is meant, and one wants to use the dash, then make sure that
at least one blank precedes it, as in:
uu temp -i

What UU does, and does not do
UU is extremely fast, and is even faster when disk caches or RAM disks are
used. To illustrate this, I have taken a large uuencoded file (5,915,740 bytes)
containing only one part of 93,906 encoded lines, and I have ran UU on it in
its fastest mode (i.e. without using any switches) while using different
settings. Here is what I came up with on my system (i486DX2-66, VLB, 20 megs
RAM, 256k cache):

Free memory (kb) 19801 15673 9520 10004 788
SMARTDRV (kb) 0 4096 10240 0 0
RAMDISK (kb) 0 0 0 10240 19456
time required (s) 17.5 16.3 8.4 4.8 4.8

This also illustrates that UU spends most of its time reading from and writing
to disk (at least on my system), so using faster disk drives (network drives,
for instance) can make UU faster yet.

UU is extremely robust: Since there is not a well-defined standard on the
format of uuencoded files, or on how these should be split up, there are
numerous small variations commonly used. The fact that uuencoding is used
on most platforms makes things even more complex. (A more detailed description
of the kinds of variations that one frequently sees in encoded files may be
found in the remainder of this chapter.) I have done my best to make sure
the user does not have to worry about all this. Usually, the user only becomes
aware of this if he tries other uudecoders, or if (god forbid) UU fails to
uudecode a file correctly. I think I can safely say that there is no other
decoder that can deal with so many variations in uuencoded files. I just wanted
to have one single program that can deal with all common (and even uncommon)
"types" of uuencoded files, and not need to choose between a lot of uudecoders
every time there is a slight variation in the encoded files. If you do not
believe me, just download a lot of uuencoded binaries from USENET, test all
your uudecoders on the lot, and judge for yourself which decoder successfully
decodes the most files...

Of course UU processes both UNIX style ASCII files and MS-DOS style ASCII
files. In addition to this, UU also accepts Mac style ASCII files, as well
as any mixture of all of these styles.

Frequently, files are encountered that have a blank line every other line.
This is probably due to the fact that these have been posted from one platform
to another without making the necessary adjustments. UU will process such
files WITHOUT the need for the user to edit out all these blank lines.

Unlike what I have seen in some other uudecoders, UU does NOT assume an
extension of .UUE if no extension is given. This is for my own convenience,
since most of the files I get to process have no extension.

Although UU was primarily designed to process many multi part uuencoded files
all contained in *one* huge file, it can also deal with multiple input files
through the use of wildcards. For more information on how UU deals with these,
please refer to the chapter on wildcards. Since there is no real difference
between UU's handling of single input files and multiple input files, in most
of this manual I shall only talk about single input files.

The sections in the input file(s) need not be in the correct order at all if
UU is used in its "unsorted sections" mode. For more information on unsorted
sections, see the appropriate chapter in this manual.

If neither of the switches /I and /S are used (and ONLY then), UU does not
allow sections to be in any other than increasing order in the file. (Again,
please refer to the chapter on unsorted sections for information on how to
handle these.)

UU always allows the source file to contain more than one uuencoded file, and
each of these files may consist of any number of sections. If no switches are
used, then these sections MUST be in the correct order. So in this case, a
file containing the following sections:

will be handled correctly by UU (and result in two files), whereas


will not. Again, this restriction does NOT apply when UU is told that the file
may contain unsorted sections.

When used in the "sorted order" mode of operation, UU can handle any number of
sections contained in one input file; there is no limit. The only thing that
may happen (apart from your hard disk getting full), is that some of the
numbers that UU displays will not be correct, but this only happens if the
number of sections in one file exceeds 9999. (Yes, I know I used the number
65535 in a previous manual, but that was a mistake. That is what happens when
you socialise with computers too much.)

If the program terminates or aborts after having detected some error, an
ERRORLEVEL of 1 is returned; a successful termination results in ERRORLEVEL 0.

Some platforms do not have the restriction of filenames being only at most
8+3 characters long, so the filename in the header of the first section of
an encoded file may not be DOS-compliant. UU recognises this, and prompts
the user for a new filename.

Some platforms allow spaces in filenames. Although it is possible to create
filenames containing spaces in DOS (earlier versions of UU would do just that,
but only if DOS 5.00 or below was used), starting with version 3.0, UU will
replace such spaces by underscores, as filenames containing spaces are just
a pain to deal with for most people and programs -- try renaming such files,
for instance... Yes, I know it is possible through the use of disk editors
or wildcards, but it is more cumbersome than renaming files with "normal"

Some programs and/or systems chop off all trailing spaces from text lines
in a misplaced attempt to save storage space (which is why most uuencoders
nowadays use backquotes (`) instead of spaces). Starting with version 3.1,
UU correctly decodes these stripped lines. Please note that this makes it
possible that UU now decodes files that were considered corrupt before, and
that sometimes, these files REALLY were corrupt, so the decoded file will be
corrupt too. So realise that if a decoded file is corrupt, that the encoded
file usually was corrupt to begin with. There is one exception, however:
Suppose that an encoded file contains a line consisting only of an "M", and
suppose that this line is NOT an encoded line, but some strange comment line.
In this case, UU will think that the line is a chopped encoded line. In UU's
"sorted order" mode of operation, this line will then wrongly be decoded,
causing the decoded file to be corrupt. Fortunately, this will almost never
happen; I have ran UU on many dozens of megabytes of encoded files, and the
situation described here did not even occur once! And even if the situation
does occur, then please realise that in its "unsorted sections" mode of
operation (so when using the switches /I and/or /S), this "section" will
usually be skipped because it cannot be identified, so everything will still
be alright then. For more information, please refer to the chapter on unsorted

If the filename for an encoded file already exists, the user is informed of
this, and may then choose to overwrite the old file (by pressing Y), rename
the new one (by pressing N), or skip this file and proceed with the next file
(if any) (by pressing S). At this point, CTRL-Break (and also CTRL-C) may be
used to abort the process. Specify the /K switch if UU is to skip existing
files without prompting. Specify the /O switch if UU is to overwrite existing
files without prompting for confirmation. Note that the combination of these
two switches is meaningless, so UU will issue an error message in this case.

If the /D switch is specified, UU will delete all input files that have been
successfully processed. This also means that if the sections of some file that
cannot be successfully processed are divided over multiple input files, then
none of these input files will be deleted. Just like UU processes hidden and
read-only files, the /D switch will also delete such files. Files that were
skipped (either from specifying the /K switch, or from pressing S when UU
asks to overwrite an existing file) also count as being successfully processed.
Please note that there is a small difference between UU's handling of the /D
switch in its "unsorted sections" mode and in its "sorted order" mode. To wit:
In its "unsorted sections" mode (i.e. when using the /S switch), UU will delete
only those input files of which ALL sections have been processed, and will NOT
delete files that do not contain any sections. In its "sorted order" mode, UU
will simply delete all files that have been successfully processed, so EVEN
input files that do not contain any sections.

As opposed to some other uudecoders, UU does not choke on CTRL-Z characters.

UU ignores lines that are not uuencoded, typically before and after sections.
I saw somewhere that a uudecoder written by someone else could be notified
that (for example) "---" is not a decodable line, as it seems that this line
is used as a cut line on several BBS systems. With UU, it is not possible to
designate such a non-decodable line... merely because UU does not need that
information to determine that a given line is not to be treated as a uuencoded
line. UU uses four ways to determine whether a line is a mere comment or not,
and treats the line as an encoded line only if all four ways show it is not a
comment. These tests are partly performed simultaneously, and always in such a
way as to require hardly any additional time (e.g. when the data required for
a test is available due to some other action currently being performed).

Some uuencoders have the nasty habit of putting one lowercase alphabetic
character at the end of every uuencoded line. (These characters are NOT part
of the set of characters allowed in uuencoded lines.) UU recognises this
without losing any of its intelligence (as meant in the previous paragraph).

Although the "standard" requires the "end" line of a uuencoded file to be
preceded by a line containing only either one space or one backquote (`),
some programs and/or systems replace a one-space-line by an empty line.
UU will also process such "illegal" files correctly.

Although UU is quite intelligent, it is possible to fool it, but I think that
this is purely academic, for the chances of it being fooled are astronomically
small (unless someone intentionally fooled UU). Even if one decoded hundreds
of thousands of uuencoded files, it would most probably occur not even once
that UU was fooled. And if it should ever occur that UU is fooled, then,
please, do not blame UU or me, but blame the one who invented the uuencoding
standard for not making it more strict. Or, put in another way: All uudecoders
can be fooled, but mine must be one of the most reliable ones as I can easily
show by a simple computation of probabilities. Of course, UU cannot perform
miracles, so if the uuencoded file is corrupt to begin with, UU will be
helpless too. But... UU should NEVER actually crash on corrupt files.

Handling unsorted sections
UU can also handle files containing randomly ordered sections. For this mode
of operation, two switches are available: /I and /S. When invoked with /I only,
UU will scan the source file, and it will subsequently report what it has found
there, but it will not actually decode anything. When invoked with both /I and
/S (or any equivalent notation -- see the chapter on command line parameters
and switches), it WILL start decoding after having reported the information.
A less verbose, but equally efficient result is obtained by specifying only
the /S switch.

If the /I switch is specified, but not the /S switch, then specifying one or
more of the switches /D, /K, and /O does not make much sense. In these cases,
UU will act as if only the /I switch had been specified. In particular this
means, that in these cases UU will not write or delete anything.

There is a maximum to the number of sections that UU can handle using this
"unsorted sections"; more details may be found later in this chapter.

This mode of operation, however still very fast, is slower than the "sorted
order" mode. Starting with version 3.1, the order in which the sections appear
does not matter as far as speed is concerned; the "unsorted sections" mode
takes approximately twice as long as the "sorted order" mode (versions before
3.1 would take AT LEAST twice as long, but often longer), but the difference
may be less on systems using disk caches.

Since the "sorted order" mode uses one very powerful assumption (viz. the
sections being in sorted order), whereas the "unsorted sections" mode can (at
best) only rely on whatever information it filters out of the source file, it
is possible for UU to obtain better results in the former mode. So I recommend
using the "sorted order" mode whenever one is sure that every section appears
in the correct order (which, as noted earlier, also is faster). However, one
should realise that in very rare cases, UU may "think" that a line is encoded
when in fact it is not. This will typically happen with a text line that starts
with an "M", has a length of at most 61 characters, and contains no lowercase
characters (all these conditions should be satisfied). The "sorted order" mode
will then decode this line, so the decoded file will be corrupt. The "unsorted
sections" mode would just skip this "section" because there is not sufficient
information available on it. Note that the line does not have to have a length
of 61 for this to happen, since it will be considered as a line from which
trailing spaces have been stripped if the length is less than 61.

So how does UU obtain its information? The current version of UU recognises
some 30 different uuencoders and posting programs. (For the ease of discussion,
I shall use the term "uuencoders" whenever I mean "uuencoders and/or posting
programs" in the remainder of this manual.) These include uuencoders used on
PCs, UNIX systems, Macintoshes and Amigas. Below follows a list of (some of)
the uuencoders supported by UU:
- EnUU, versions 1.3, 1.4, 1.5, 1.6, and 2.02 by Marko Pinteric
- Hermes FILESERV by Martin P. Ibert
- POST, versions 1.1.0 through 2.0.0 by John W.M. Stevens
- post-bin, revision 2.2.2 by Terry W. Thero (REV 2.2 by Rich Thompson)
- QUUNCD Ver. 1.4 by Theodore A. Kaldis
- SplUU V01.16 beta by Psilocybe Systems Inc.
- UU-ENCODE, versions 4.02 through 5.25 by Richard E. Marks
- UUCODE, versions 2.0 through 3.0 by Sabasoft, Inc.
- UULite version 1.6 by Jeff Strobel
- UUSPLIT version 1 by David Uy
- UUXFER ver 2.0 by David M. Read
- Wincode, versions 1.2, 1.4, 1.5, 2.2, and 2.3 by George H. Silva
- WinVN, versions 0.90.4 and 0.90.5 by Mark Riordan, Sam Rushing, and others
- xmitBin, versions 1.8 and 1.9 by D. Jim Howard
Please note that there are many more uuencoders and version numbers of these
that are recognised as well by UU, so this list is far from complete. I have
listed only the ones that I know by name, and only the version numbers of which
I am sure that UU supports them. I just do not have all versions of all these
programs, nor uuencoded files produced by all these.

If it cannot recognise the uuencoders that were used, or if these have not
included all of the necessary information in the file, UU tries to use the
"Subject:" lines (if it finds any) that may be included if the file contains
postings from USENET. Instead of "Subject:" lines, some newsreaders produce
"Description:" lines; these are also supported by UU. In the remainder of this
manual, I shall no longer refer to "Description:" lines, but whatever holds
for "Subject:" lines, also applies to "Description:" lines.

If postings from USENET are used, I recommend NOT chopping off the headers
(and thus the "Subject:" lines) for a higher chance of success. "Subject:"
lines are used only if all else fails, because of the higher chance of these
containing errors. For instance, someone may have erroneously given a five part
file a subject line of "EXAMPLE.ZIP (4/6)" indicating that there are six parts.
But even when things like this happen, there is a good chance that UU will

successfully decode these files all the same. In particular, this means that
UU will usually successfully decode a file containing a series of postings
with "Subject:" lines such as the following:
Subject: niceprog.exe (2/3)
Subject: niceprog.exe (1/3)
Subject: niceprog.exe (3/4). Sorry, there are four parts!
Subject: niceprog.exe (4/4)
Note that this is only an example; all kinds of variations (and also when
there actually are LESS parts than the poster originally indicated) of this
will usually be processed correctly by UU as well. To end this subject (no pun
intended), some examples of "Subject:" lines, and how they will be processed
by UU:
- Subject: EXAMPLE.ZIP (4/6)
UU sees this as part four of a six part file called EXAMPLE.ZIP.
- Subject: Re: PICTURE.GIF {Just another picture} [01/10]
As expected, UU will see this as part one of a ten part file called
- Subject: Repost:AGAIN.EXE(Part3of20).Reposted on popular demand.
Yes, UU will assume it is dealing with part three of a twenty part file
called AGAIN.EXE.
- Subject: >FOOBAR.JPG (b/w) {Another picture} (part 3/5.
UU is not fooled by "(b/w)", nor by the ">"; it will correctly assume
this is part three of a five part file called FOOBAR.JPG.
- Subject: - FooBar.Jpg {Another picture /0 } part04 of5} (6 /w ).
Even this does not fool UU; it assumes to be dealing with part four of a
five part file called FooBar.Jpg. Moreover, UU will see this as a further
part of the same file as in the previous example.
Although these examples show that UU is quite "intelligent" while dealing with
these lines, I realise that my "Subject:" line parser still leaves room for
improvement. Either way, the name it finds in the "Subject:" line is not all
that important since the name of the file also appears in the header of the
first section of a uuencoded file. And most of the time (so even when it comes
up with false information from the "Subject:" line), it will yield a correct
result anyway.

And while on the subject of filenames: Most of the uuencoders also include
some form of file identification at the start of each (so not only the first)
section, one way or another. For at least some of them, it may be the case
that this "name" differs from the one that is in the header of the first
section. And of course, this is also possible for the name UU filters out
of the "Subject:" line. That is why, when using the /I switch, UU will give
two names for each section it finds. The real name (i.e. the one from the
"begin" line of the first section) is the one that is NOT parenthesised.
And although UU will display the names exactly as they appear in the file,
it will perform a case-insensitive comparison between these names, thus making
up for capitalisation inconsistencies by the person who posted the file.

As mentioned earlier, there is a limit to the number of sections that UU can
handle when dealing with unsorted sections. Starting with version 2.6, this
number depends on the lengths of the filenames it finds in the input file.
This is because of the fact that starting with version 2.6, UU stores those
filenames in memory dynamically, which means that instead of using a fixed
amount of bytes for each filename, it now uses only the amount of bytes it
actually needs for each filename. If, for instance, the average length of
the filenames (including the ".") is 12, then the maximum number of sections
UU will allow is 862. But also note that no matter how short the filenames
are, UU will never allow more than 999 unsorted sections.

Because of the fact that UU may filter the wrong name out of the "Subject:"
line, it is possible that it comes up with the same name for two or more files
in case there are several files contained in the input file. If UU cannot find
sufficient information from the uuencoder that was used, this may then lead to
less successful results than would result if each file were contained in an
input file of its own. Stated differently: It is possible that two files that
would each be processed correctly by UU, will no longer yield a successful
result after they have been concatenated. In particular, this means that when
the same file occurs twice in the input file, it will be processed only once.

Also when using the /I switch, UU will give the section number and the total
number of sections (as far as this could be determined of course) for each
section it finds. This is displayed as in "(003/010)", which would mean that
this section is part three of a ten part file. Whenever a number could not be
determined, "000" is printed instead. Finally (still when using the /I switch
only), UU displays some information on any section it will not be able to
process, as well as the reason for this.

The remainder of this chapter holds for both the /I and /S switches: Whenever
a filename that was encountered is longer than twelve characters, it will be
displayed to the first eleven characters only, with an asterisk (*) appended
to it. Of course, the full name will be displayed when prompting the user for
a new filename, and UU will also use the full name in all internal operations.

When UU has scanned the input file, it will list the names, and numbers of
sections of each COMPLETE file it has found. It also gives the total number
of sections it has found, the number of sections it could not identify, and
the number of sections that may be processed. Note that the latter number is
not necessarily the difference of the former two, because there are various
reasons that a section that WAS identified cannot be processed after all (for
example when there are other sections of the same file missing). The actual
reason will usually be given while using the /I switch. If UU does not give
a reason, this usually means that one or more sections appear twice or more.

I have done my very best to make UU as smart as possible, but as noted earlier,
due to the fact that the uuencoding standard is not strict enough, even the
most intelligent uudecoder may not be able to correctly figure everything out.
Let me end this chapter by quoting Nick Viner: "Of course some files which have
been split by hand and not labelled adequately will always defeat it!"

Handling wildcards
UU accepts wildcards * and ?, and has two switches (/1 and /A) specifically
related to this. Basically, if a file specification containing wildcards is
used, then UU will act as if the files matching this specification were all
contained in one large file. As with single files, each of these matching
files may contain multiple multi part files. If the matching files are to
be processed fully independently of one another, then use the /1 switch.
There is one exception however to the assumption of seeing all these files as
if they were contained in one large file: In case UU is used in its "unsorted
sections" mode (by using the /I and/or /S switches), then each section should
be identifiable. Suppose, for example, that some file has been uuencoded into
one single section. If one were to manually split this section into two parts,
and save each of these to a different file (say PART1.UUE and PART2.UUE),
then UU will not be able to identify PART2.UUE, so invoking UU with
will not make UU decode anything. So don't split up sections... Please note
that if somebody has split up a large uuencoded file by hand, and has posted
each of these parts to USENET, then there is a good chance that each of these
parts *will* be identifiable, because the posted parts will have several useful
headers (such as "Subject:" lines). The requirement that all parts have to
be identifiable of course only applies to UU's "unsorted sections" mode of

Usually, the matching files are processed in the order in which they appear
in the directory, but UU can be forced to handle these files in alphabetical
order by specifying the /A switch. Please note that it does not make much
difference whether or not this switch is used when either or both of the
switches /I and /S are used as well. To wit, the switches /I and /S force
UU to examine all matching files first, and then determine the order in which
all sections of all matching files are to be handled, so the order in which
these matching files are examined is irrelevant. So the /A switch is only
really useful when neither of the switches /I and /S are used. Let us assume
that your directory contains the following files (in the listed order):
will process these files in that order, whereas
will start with FILE1.UUE, then proceed with FILE2.UUE, and finally process
FILE3.UUE. Note that in UU's "sorted order" mode of operation (where files
are *not* examined first), sections need not be identifiable, so if one were
to uuencode a file into one section, and then manually split up this encoded
file into files containing only one line each (let us assume there are 999
lines, and line 1 is written to a file called LINE.001, line 2 to LINE.002,
etc.), then
will correctly decode it (as will
if the files appear in the correct order in the directory).

Note that combining the /1 and /A switches in both UU's "sorted order" and its
"unsorted sections" modes of operation does not make much sense, since UU will
only terminate successfully if each of the input files is decodable by itself.
Or stated differently (using the above example with the files FILE2.UUE,
FILE3.UUE, and FILE1.UUE): No matter which additional switches (if any)
you use, the command
is just an abbreviation for
(where /X represents all additional switches). And clearly, there is no
difference as to the order in which these commands are given... Well, that
is not entirely true as there IS a difference in case the /O switch is used
as well, and -- at the same time -- there is some file that appears two times.
Suppose, for example, that both FILE1.UUE and FILE2.UUE contain a file called
EXAMPLE.ZIP. Then after having used the switch combination /1AO, EXAMPLE.ZIP
will be the one that was contained in FILE2.UUE, whereas the combination /1O
yields the EXAMPLE.ZIP from FILE1.UUE. The way I see it is that UU simply
offers a number of switches, and that it is up to the user to decide whether
or not certain combinations are useful. And of course, nobody is forced to
actually use all the options UU offers.

Finally, a word of advice on using wildcards: If you do not want to spend too
much time on USENET, then I suggest you collect all the binaries you want in
a few files, don't bother about it if the sections are not all contained in
one and the same file, and then run UU on these files using wildcards and
the /I and /S switches (e.g. "UU/IS P*"), but please remember that in this
mode, there still is the varying limit (as explained earlier) on the number
of sections: In case the /1 switch is used, each of the input files may not
contain more sections than this limit, and in case the /1 switch is not used,
then the sum of the numbers of sections of all input files may not exceed this

Plans for the next version (3.2) of UU
There is a Mac program called UUTool producing files that are best described
as being a mixture of UUcode and XXcode; I am planning to have UU support this
format. In the meantime, a small program that converts this format to standard
UUcode will be contained in the package.

Another mess-up that one sees every now and then, is that (probably because
someone had forgotten to turn off word wrapping) the "begin" line is split
up into two lines. I am planning on having UU recognise this.

Plans for the more distant future
I can think of several ways of making UU even smarter. For instance, by adding
support for even more uuencoders (if I find any). Another option is to have UU
use the information it gathers but does not use so far, so as to have it make
its own assumptions about sections that could only be partially identified.
The latter case would then be as if UU said "These sections probably belong
together... well, let's assume they do, and process them.". Finally, the
routine that deals with USENET's "Subject:" lines could be made yet a little

I think it would be nice if the user could choose to manually change the
"Subject:" lines, thus being able to correct for parts that have not been
labelled adequately.

Another option I plan to add, is to have UU be able to write every section
that has not been processed to a separate file. Related to this would be an
option to have UU output all non-encoded data.

By using code that runs only on an 80386 or higher, I could make UU yet a bit
faster; I may release such a version one day. Or better yet: I could have UU
auto-detect the processor, and include processor specific code for the most
time critical routines.

By using XMS (or EMS) memory for additional buffering, I could make UU yet a
bit faster.

Some uuencoders put checksums in the files. I may have a future version of UU
be able to check these.

I may also write an also very fast, and even smaller uuencoder. In fact,
I have already written a prototype which is faster than any of the uuencoders
I know.

I may also add support for xxencoded files to UU.

Someone suggested it would be nice if one could change UU's defaults, so that,
for example, the /S switch would then be assumed automatically. I do not like
to do this, since it would make using UU less easy. I think that naive users
would be frightened by the prospect of having to edit some configuration file
(or something like that) first. Moreover, I think typing "UU/S" instead of
"UU" cannot be a real bother. Or stated differently: If I had given this
program a longer name, then those extra characters would have to be entered

I should like to thank the following persons:
- Terry O'Brien for sending me detailed information on the file mode code
in the header of uuencoded files, and on uuencoding in general.
- Martin Jones for telling me about a bug ๐Ÿ™ in version 1.1 (and 1.0).
- Brian Norris for telling me about a bug ๐Ÿ™ in version 1.3 (and earlier
- Douglas Swiggum for all the trouble taken in sending me "strange" uuencoded
files, and detailed descriptions of what happened. You have saved me a lot
of time in finding two bugs ๐Ÿ™ in version 2.0!
- Anders Jarnberg for describing exactly what happened while using versions
2.0 and 2.1 under OS/2.
- Mike Laskey for telling me about the problems under OS/2, and for testing
some preliminary versions of UU 2.2 under OS/2.
- Roger Champagne for making me reconsider the way version 2.5 (and earlier
versions) handled blank lines.
- Robert Bleidt for sending me a file that made me realise that some files
that were considered corrupt by UU 2.5 and earlier versions (and still are
considered corrupt by almost every other uudecoder) are correctly decodable
after all. Thanks also for reminding me that filenames containing spaces
(although they *can* be created) are not easily dealt with under DOS.
- David Bunch for sending me the line that in a modified form is used in the
UUW.BAT batch file that was included in the UU 2.6 package. Yes, I know it
has been a while since you sent me that line, but I kept forgetting to
include it in the package...
- Hoa Nguyen for contributing the UUD.BAT batch file that was included in the
UU 2.6 package.
- Marko Pinteric for making sure that his uuencoder (EnUU) would be supported
by UU.
- Michael Eilers, David Farley, Spencer Hochstetler, Allan Hudgins, Martin
Ibert, Eric Johansson, Alex Law, Rufus P., Terry Thero, Anthony Trippe,
David Uy, and Rene Walter for helping me find the names of some of the
uuencoders UU recognises.
Last but not least, I should like to thank all the people who have let me
know they appreciate my program, or otherwise (e.g. by telling me about bugs,
or suggesting new features) mailed me regarding UU.

Release history
In my convention of version numbers, 0.x versions denote usually unreleased
prototype versions.

Versions 0.1 through 0.4, and 0.6 were private, unreleased versions, written
in a mixture of Pascal and assembly language.
Version 0.5 was given to but a few people to see how they liked it. It had
resulted from a process of stepwise refinement in which speed, size, feedback,
and user-friendliness were tackled. Versions 0.1 through 0.5 were all written
on 11-Dec-93. They were EXE files, and the latter had a size of 5872 bytes.

UU 0.6 Type: EXE Size: 3424 Date: 14-Dec-93
The last prototype version. Most of it written in assembly. Yet a bit
faster than 0.5.

UU 1.0 Type: COM Size: 1993 Date: 15-Dec-93
The first publicly released version. But for some tiny details this is
the full-assembly version of 0.6.

UU 1.1 Type: COM Size: 1965 Date: 18-Dec-93
- Even smarter in distinguishing comment lines from encoded lines (a fourth
test has been added).
- Sections containing only one non-empty line are now recognised as such.
- Detects when the disk is full, upon which it aborts with an appropriate
- Yet a bit faster than 1.0.

UU 1.2 Type: COM Size: 1896 Date: 23-Dec-93
- Now really only accepts "y", "Y", "n", and "N" while asking permission to
overwrite an existing file. Also, CTRL-Break (and CTRL-C) can be used at
this point to abort the program immediately.

UU 1.3 Type: COM Size: 1892 Date: 25-Dec-93
- In earlier versions, lines of more than 255 characters COULD (although it
is HIGHLY improbable they actually WOULD) result in decoded files being
corrupted; starting with this version, this can no longer happen.
- Yet a bit faster than 1.2 (amongst others (but not only!) because the read
and write buffers now each are 4k larger).

UU 2.0 Type: COM Size: 5866 Date: 09-Jan-94
- Now also allows files containing unsorted sections.
- An intelligent command line parser has been added. Because of this, the bug
of UU not accepting filenames of length 1 in the command line (in fact, I
did not even know about this bug until some time after I had finished the
parsing routines) no longer exists.
- Aborts with an appropriate message if there is not enough (conventional)
RAM free.
- Displays an error message when invoked without any parameters or switches.

UU 2.1 Type: COM Size: 6257 Date: 17-Jan-94
- I really thought I had solved the problem of lines containing more than
255 characters in version 1.3, but I had not; now, it is REALLY fixed.
- Added support for five more uuencoders and posting programs.
- In addition to "Subject:" lines, "Description:" lines are now supported
as well.
- Made the parser for "Subject:" (and "Description:") lines even more
- Fixed a bug that seemed to matter only when run from the DOS box under
- The maximum number of unsorted sections UU can handle is slightly higher
(434 instead of 387).
- Some minor changes not worth mentioning.

UU 2.2 Type: COM Size: 6453 Date: 29-Jan-94
- Faster than all previous versions, even more so (due to a bit of manual
code optimisation I performed) for those lucky few owning a Pentium.
- Now recognises corrupt final sections (which could cause UU to crash in
earlier versions).
- The "Subject:" line parser is yet a bit smarter.
- A bit smarter in recognising the uuencoders and posting programs.
- Also a bit smarter in making up for errors in the "Subject:" line.
- And also a bit smarter in recognising false "begin" lines.
- Supports five more uuencoders and posting programs.
- Now also runs from the DOS box under OS/2.
- Sections containing only an empty line followed by the end marker are now
recognised as such.
- While working on the previous point, I discovered and fixed a bug: Previous
versions did not handle very short encoded lines correctly; they would
cause a file to be one byte too short.

UU 2.3 Type: COM Size: 6450 Date: 13-Feb-94
- Still as fast as version 2.2, although UU now also runs on 8086 and 8088
- Now also accepts files created by uuencoders that put one lowercase letter
at the end of every uuencoded line -- previous versions of UU would either
crash, or come up with a resulting file of 0 bytes in these cases.
- Yet another five additional uuencoders and posting programs are supported.
- Some internal changes were made to make UU smaller; without these changes,
this version would have been over 300 bytes larger.

UU 2.4 Type: COM Size: 6470 Date: 03-Mar-94
- Previous versions of UU would sometimes not handle filenames of longer
than 28 characters correctly -- this has been fixed now.
- Discovered and fixed a bug that by some weird coincidence never seemed to
- Some tiny changes not worth mentioning.

UU 2.5 Type: COM Size: 6490 Date: 13-Mar-94
- Version 2.4 would sometimes display "strange" filenames (viz. a digit
followed by a blank, followed by the real filename). Fixed.
- In some other cases, UU would produce a filename of length zero when this
should not have been the case -- this has now been fixed.

UU 2.6 Type: COM Size: 6695 Date: 07-Apr-94
- In addition to DOS style ASCII files and UNIX style ASCII files, Mac
style ASCII files are now accepted as well.
- Fixed a tiny bug that on some occasions would display section numbers
that did not start at 1 in UU's "sorted order" mode of operation.
- Blank lines in encoded sections are now ignored, so UU now correctly
decodes postings that have a blank line following every "normal" line.
- Some files that were considered corrupt before (and still are considered
corrupt by almost every other uudecoder!), will now be decoded correctly.
- Filenames are now stored in memory dynamically, thus usually allowing much
more unsorted sections (usually well over 800 sections, but at most 999).
- One more uuencoder is supported.
- Several (other) internal changes were made in preparation for version 3.0.

UU 3.0 Type: COM Size: 7614 Date: 26-Apr-94
- Now also accepts wildcards. Related to this, two new switches (/1 and /A)
were added. The files UUW.BAT and UUD.BAT that were contained in the
package of version 2.6 have thereby become superfluous.
- Added a new switch /O for overwriting existing files without confirmation.
- Although the standard requires the "end" line to be preceded by a line
containing only a space or a backquote (`), UU does no longer require it,
since there are programs/systems that replace this line by an empty one.
This change was also made in preparation for version 3.1.
- Some systems allow spaces in filenames. Although it is possible to create
filenames containing spaces in DOS (earlier versions of UU would do just
that, but only if DOS 5.00 or below was used), UU will now replace such
spaces by underscores.
- A small program (FROMMAC.EXE) is included in the package to deal with
files produced by a Mac program called UUTool.
- One more uuencoder is supported.

UU 3.1 Type: COM Size: 8318 Date: 24-May-94
- Faster than all previous versions, and even more so if it can use one or
more extra buffers: UU still requires very little memory to run, but it
will put all additionally free conventional RAM (if any) to good use now.
- Usually much faster in its "unsorted sections" mode, because the order in
which the sections appear now is irrelevant as far as speed is concerned.
Even when the sections appear in reversed order (which was the worst case
for previous versions), UU is still as fast as in the best case now.
- Some programs and/or systems chop off all trailing spaces from text lines
in a misplaced attempt to save storage space (which is why most uuencoders
nowadays use backquotes (`) instead of spaces). UU now correctly decodes
these stripped lines.
- Added a new switch /D for having input files that have been SUCCESSFULLY
processed deleted.
- Added a new switch /K for skipping existing files without prompting.
- Files that already exist may now be skipped by pressing "S" when UU
prompts for it.

Contacting the author <-- Hey, that's me! :-)
Contact me (preferably using e-mail) if you have any questions, suggestions,
remarks, etc., on this document, on UU, or on any other of my programs.
Also, if you find a valid uuencoded file that UU does not process correctly,
please let me know. And if at all possible, pray send that file along to me
(or otherwise a detailed description of its contents), preferably in some
(any) compressed form in order to keep my mail server from automagically
ruining it. Beyond my control, my mail server automatically decodes (or tries
to anyway) uuencoded files, so I would not end up with your uuencoded file.
Thank you very much!

I check the and
newsgroups on USENET regularly, so you could also try placing messages for
me there. Finally, please send me an e-mail if you think my program is of
use to you (or flame me if you think it is useless). If I do not get enough
feedback, I take it that people are not interested, and I shall... continue
writing programs for myself, but DIScontinue spreading them on anything but
a very small scale.

Ben Jos Walbeehm (Please get my first name right, it is "Ben Jos".)
Lijsterbeslaan 20
5248 BB Rosmalen
The Netherlands
Phone : +31 4192 14345 (The best time (GMT) to get hold of me is at night!)
E-mail: [email protected]

  3 Responses to “Category : Utilities for DOS and Windows Machines
Archive   : UU31.ZIP
Filename : UU.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! ๐Ÿ˜€ I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: