Being a physicist, computers and programming are not in the core of my interest. However, due to my work, I would be forced to learn programming, if I didn't always love it as a one of my hobbies. So even before I really had to, I learned programming languages, Basic, Pascal, C and Assembler. Therefore it is not surprising that my most exciting programming project, the program called ENUU, has nothing to do with my work.
ENUU.COM is a $0 shareware program. For those less experienced, this means that you don't have to pay a penny/nickel to use it, but you must register. It is an uuencoder for DOS that is the fastest, the shortest and the most easy-to-use as far as I know. Yes, all this is possible, since it is the only DOS uuencoder fully written in Assembler.
The function of encoders and decoders using uu-algorithm is enabling binary file transfer through e-mail. Namely, e-mail programs use a bunch of characters as control ones, so if you simply send a binary file through e-mail, recipient will get the file of different content and length. However, if you encode file according to uu-algorithm, those control characters are avoided and when the recipient finally decodes your post, he or she will get a file identical to the starting one!
Writing this program was one of my greatest life challenges. Although I am not a professional programmer, I tried to make a program that could be useful and easy-to-use to various people. Using knowledge of Pascal, I wrote the first version of the program in the beginning of 1994. The great help was given by Ben Jos Walbeehm, whom I hereby specially thank.
Later, implementing my knowledge of Z80 Assembler to the 8088 instruction set, I gradually transformed part after part of the original Pascal program into Assembler. So despite the number of options of the program was increasing, the program was becoming shorter and faster with every new version.
When the last version was released in 1995, I still had great plans for the future. Then I was working on implementing wildcards, while UNIX standard files were already enabled in beta versions. However, under the pressure of different obligations, among which the continuation of my studies was the fatal one, I practically stopped any further development.
The situation worsened with appearance of alternative systems, like the new MIME-standard for e-mail transfer or new Windows 95 operating system, and faster computers. All this made my further efforts rather in vain.
The only requirement for using the program is to register. The idea behind this is about estimating the number of users, and enabling them to get the newest version as soon as possible.
Despite I know and have strong indications that many users have never registered, I was pleasantly surprised by the fact that the program became very popular. Number of postings using my program was so big, that all new uudecoders recognize my program as one of the three prime uuencoders for all operating systems. Also, I got registrations literally from the whole world - from Hawaii to New Zealand and from Sweden to South Africa.
You can still register simply by writing me using this feedback form
I thank all people that helped me with programming advices, Ahmad Mulhem, Jeroen Schipper and of course Ben Jos Walbeehm.
Special thanks also to all of my beta-version testers.
Thank you all who have registered! You too helped further development of the program by motivating my work.
You have surely experienced mail servers before, so you've probably noticed that for a normal text, mail is working just well. But some files, like pictures or execution files, or so-called binary files, contain many characters, which have special meaning for the mail server, so-called control characters; The mail server deletes or replaces control characters with other ones (and this is only the top of the ice hill). Therefore, if you simply send a binary file through e-mail, the recipient will get a file of a different length and content than the initial one.
So some clever people (I do not know) came to the idea to transform binary files into the form, which is acceptable for the post, and then again, in the end of the process, after receiving it, transform them back to initial state. This is what is usually referred as uucoding or xxcoding. These are two different standards, but almost everyone uses the former.
So you have uuencoders for the first transformation and uudecoders for the second. For all procedures the standard exists, so there should be no concern whether a recipient will be able to decode files from a sender.
What is the essence of uucode? Characters from range $00 to $FF are pressed to fit range $20 to $5F (alternatively $21 to $60). When uuencoding, three bytes (twenty-four bits) are taken and split into four strings. Then these strings are set to occupy the lowest bites of new formed four bytes, getting range from $00 to $3F. In the end, each of new bytes is added $20 for adjustment. Uudecoding procedure is opposite.
Schematically (each letter stands for bit 0 or 1):
|first byte||second byte||third byte|
|A B C D E F G H||I J K L M N O P||Q R S T U V W X|
|A B C D E F||G H||I J K L||M N O P||Q R||S T U V W X|
|A B C D E F||G H I J K L||M N O P Q R||S T U V W X|
|0 0 A B C D E F||0 0 G H I J K L||0 0 M N O P Q R||0 0 S T U V W X|
|0 ? ? B C D E F||0 ? ? H I J K L||0 ? ? N O P Q R||0 ? ? T U V W X|
|first byte||second byte||third byte||fourth byte|
Some uuencoders turn character $20 into $60 in the end. Most uudecoders recognize both characters. Still, there is one very good point for choosing $60. Some UNIX systems chop off all spaces ($20) in the end of the line, or so-called trailing spaces, so the code becomes corrupted. Those problems with $60 instead of $20 do not appear.
The rest of the standard is as follows: In each line the first character designate the number of bytes coded within it, and again $20 is added for adjusting. Since the standard number of bytes per line is 45, letter 'M' (45+$20) appears as the first character throughout the file (except in the last line). Finally, the coded file starts with line 'begin' and ends with line 'end'.
But one problem made lives of uudecoders' programmers hell: Since some mail servers restrict the length of a message and often for the practical reasons, the encoded file must be parted into many smaller sections. It is not standardized how (i) the total number of sections, (ii) the number of particular section, (iii) the particular section's beginning and (iv) the particular section's end are specified. Also, it is not standardized how to specify (v) the name and (vi) the length of the initial file. These things are uuencoder dependent, and should be recognized by uudecoders for each uuencoder separately.
Created by Marko Pinteric: feedback form.
Updated . Web page has been read by visitors since July 2005.