UU version 2.6 -- A small, fast, and smart uudecoder for DOS Copyright (C) April 1994 -- ir.drs. Benjamin J. Walbeehm April 7, 1994 Introduction ~~~~~~~~~~~~ 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 USENET: alt.binaries.pictures.utilities FTP : ftp.rahul.net /pub/bryanw/pc FTP : wuarchive.wustl.edu /pub/MSDOS_UPLOADS/uucode Pointer messages announcing the new release will be posted to USENET: alt.binaries.misc USENET: alt.binaries.pictures.erotica USENET: alt.binaries.pictures.misc USENET: alt.binaries.pictures.supermodels In addition to the UU??.ZIP packages, I also post UU??.EXE packages to the alt.binaries.pictures.utilities 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 YOU WHEN YOU DECIDE THAT THIS PROGRAM IS OF USE TO YOU, IS THAT YOU SEND ME A SHORT E-MAIL. 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 75k (UU uses two 32k buffers to speed up reading and writing) for this program to work correctly. UU will check if there is enough RAM free, and complain if there is not. (I hear some people asking: "75k?"... Yes, I know we are talking .COM here, but that does NOT mean we are restricted to 64k now, does it?) 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. 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 commands: UU /? UU -? TYPE UU.COM 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] [/I] [/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 "I" 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,906 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) 24 21 9 5 5 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. 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. The current version of UU does not allow encoded files to be split up into different files, so if, for example, a file called EXAMPLE.EXE has been converted (by some uuencoder) into three sections, and each section has been written to a different file, say EXAMPLE1.UUE, EXAMPLE2.UUE, and EXAMPLE3.UUE, then UU will not be able to retrieve the original file. Until I have implemented a multiple source handler, one can work around this restriction by first executing the following command (still using the same example) from the DOS prompt: COPY /b EXAMPLE1.UUE + EXAMPLE2.UUE + EXAMPLE3.UUE EXAMPLE.TMP and then feeding the resulting combined file EXAMPLE.TMP to UU. Note that the /b switch has been added just to be sure; if the source files come directly from a (any) uuencoder, then it will not be necessary, but in that case it will not harm either. Some posting programs, however, put a CTRL-Z character in the file, in which case the /b switch is absolutely required. Please note also that if (and only if) the (here) three source files appear in increasing order in the directory (so EXAMPLE1.UUE comes before EXAMPLE2.UUE, which in turn comes before EXAMPLE3.UUE), that the following DOS command will correctly combine them as well: COPY /b EXAMPLE*.UUE EXAMPLE.TMP The restriction of the files appearing in increasing order in the directory when using the latter COPY command usually does not apply when UU is used in its "unsorted sections" mode on the resulting file. For more information on unsorted sections, see the appropriate chapter in this manual. Please note that in order for the COPY command to work correctly, the resulting file (EXAMPLE.TMP in the above examples) should have an extension that differs from those of the files that are to be concatenated (the files ending in .UUE in the above examples). Two batch files, UUW.BAT and UUD.BAT, are included in the package to make up (at least partially) for UU's not handling multiple input files. If no switches are used (and ONLY then), UU does not allow sections to be in any other than increasing order in the file. (Please refer to the chapter on unsorted sections for information on how to handle these.) In particular, this means that this version acts the same as the earlier 1.x versions in case no switches are used. Either way, because of its speed, intelligence, and robustness, I highly recommend using version 2.6 only. 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 and 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. If the filename for an encoded file already exists, the user is informed of this, and may then choose to either overwrite the old file, or rename the new one. At this point, CTRL-Break (and CTRL-C) may be used to abort the process. 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 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. 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. Just how much slower depends on the order in which the sections appear. Worst case performance (in terms of speed) is when the sections appear in reversed order; as before, considerable gains may be achieved on systems using disk caches and/or RAM disks. 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). 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 1.3 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.13 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 - 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 PICTURE.GIF. - 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 the filename 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 header 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!" Plans for future versions of UU ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With the possible exception of the first three points, the following plans do not have high priority for me... but I am open to suggestions, so if you have any arguments in favour of any of these, or perhaps some new suggestions, please let me know. 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 smarter. 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. I am considering having UU be able to handle files whose sections are not all contained in one and the same file, so the PART1.UUE PART2.UUE PART3.UUE scheme, but I should add that this does not have high priority, since I only need this very rarely, and for these rare cases, I do not mind using the COPY command first in order to put everything in one file. As an alternative to the former, or even in addition to it, I may some day have UU accept wildcards in the filename. I am considering adding a switch (/d for instance) allowing one to have the input file deleted after it has been SUCCESSFULLY processed. Again, this does not have high priority for me, but on the other hand, it would be very easy to add this. So anyone in favour of this is kindly requested to react. (People who are against this option do not have to react I guess, because no one is forced to actually use all UU's options.) 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 add a third option to UU in case a file already exists, viz. "skip", which will allow the user to choose not to process this file, and continue with the next (if any). 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 anyway. Acknowledgements ~~~~~~~~~~~~~~~~ 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 versions). - 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. - David Bunch for sending me the line that in a modified form is used in the UUW.BAT batch file that is 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 is included in the UU 2.6 package. - 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 names I did not know yet 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) 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 message. - 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 intelligent. - Fixed a bug that seemed to matter only when run from the DOS box under Windows. - 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 processors. - 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 matter. - 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. 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 alt.binaries.pictures.misc and alt.binaries.pictures.utilities 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: Walbeehm@fsw.ruu.nl