arenberg@trwrb.UUCP (Jeff Arenberg) (05/06/88)
In article <9621@agate.BERKELEY.EDU> laba-4an@web3a.berkeley.edu.UUCP (Andy McFadden) writes: >Bitnet mail gets hosed by 6 bit encoding. Perhaps someone could explain >the [lack of] virtues for uuencode/atob. Of course, a primary reason for >not using uuencode is that most people don't have uudecode for their >Apple, and who wants to worry about UNIX fudging their binaries? > >laba-4an@widow.berkeley.edu (Andy McFadden) > >"Remember, mailers are people too." Last night I downloaded the C source code for uuencode and uudecode from simtel-20.arpa ( Files are in pd1:<msdos.starter> ) and I was playing around trying to get them running under APW C. The code is very short and pretty simple, but it uses Unix file commands, so rewriting it to use prodos and presumably the Basic interface would take a little work. I'm curious is anyone would like to see this as a utility. I haven't had any problems with Executioner. If anyone has any real good reasons why uuencoded material is better, please speak up. Jeff Arenberg ------------------------------------------------------------ UUCP : ( ucbvax, ihnp4, uscvax ) !trwrb!trwcsed!arenberg ARPA : jarenberg@ecla.usc.edu GEnie: shifty ------------------------------------------------------------
spike@bu-cs.BU.EDU (Spike) (05/08/88)
In article <790@trwcsed.trwrb.UUCP> arenberg@trwcsed.UUCP (Jeff Arenberg) writes: <Last night I downloaded the C source code for uuencode and uudecode from >simtel-20.arpa ( Files are in pd1:<msdos.starter> ) and I was playing >around trying to get them running under APW C. The code is very short and <pretty simple, but it uses Unix file commands, so rewriting it to use prodos >and presumably the Basic interface would take a little work. Uuencode is quit simple: First it puts the line 'Begin mode filename' mode is permissions of the file, filename is just that. This allows uudecode to skip over any cruft such as mail headers. It takes 3 8 bit integers and outputs 4 chars given AAAAAAAA output 00AAAAAA BBBBBBBB 00AABBBB CCCCCCCC 00BBBBCC 00CCCCCC The ASCII value of SPACE is then added to the number to make it a printable char. The very first char on each line is the number of uuencoded chars on that line plus the value of SPACE. This number must be <= 45 (45 uuencode ints will give 60 printable chars). Most commonly the value is 'M' ('M' - ' ' = 77 - 32 = 45). At the end the should have line starting with a SPACE (for 0 chars) and the a line that is 'end'. <I'm curious is anyone would like to see this as a utility. I haven't >had any problems with Executioner. If anyone has any real good <reasons why uuencoded material is better, please speak up. It might be useful if you wanted to work with Apple binaries on an other system or need to pack a non-text file on a non-Apple to send to your Apple. ->Spike "You'll laugh, you'll cry, you'll kiss 3 bucks goodbye." UUCP: ...!harvard!bu-cs!bu-it!spike INTERNET: spike@bu-it.bu.edu CSNET: spike%bu-it@bu-cs BITNET: engemnc@bostonu "VPS sucks"
kamath@reed.UUCP (Sean Kamath) (05/08/88)
In article <790@trwcsed.trwrb.UUCP> arenberg@trwcsed.UUCP (Jeff Arenberg) writes: > The code is very short and >pretty simple, but it uses Unix file commands, so rewriting it to use prodos >and presumably the Basic interface would take a little work. I'm curious >is anyone would like to see this as a utility. I haven't had any problems >with Executioner. If anyone has any real good reasons why uuencoded >material is better, please speak up. > >Jeff Arenberg The heart of the UU(en/de)CODE routine is: #define ENC(c) ((c) ? ((c) & 077) + ' ': '`') What this does is basically a three to four byte conversion, or six bit packing. It does not try to do anything funky, it just makes *every* byte readable as ascii. No, using uu(en/de)code is nice, but it still puts out all the nasty characters that BITNET bites on. Really. No, as for why I know all about this...I'm writing a program I am calling apencode. It will do A) self-execing files B) do try UNIX UU(en/.de)CODE from a file, and C) Ziff whatever packing used by .GIF and compress on our vax. . . Now, as for when this is going to appear. I already have a very simple routine that does A) under dos 3.3 I will start with DOS 3.3 for my own reasons. . . The last thing I will do with bee the Zwhatever compression, as I don't have an "reasonable" docs on how to do it. . . Just a bunch 'o undocumented C code. . . I expect to have something to post n a few weeks. . . To give you an idea about how I will pack files. . . They will all be packed with 6 bit packing, withh all characters being mapped to something I hope is readable. . . This means just about no characters other than A-Za-z. I do need about 16 chars, which I will use 0-9 and some other chars, and I am hoping to get back from Larry a list of death chars, so that I can avoid them. When I add packing, I will pack the file first, then encode it. Depending on how hard it is to do this, I may break it into two separate steps. . . When I move it to ProDOS, it will run virtually the same, but when you try to exec the packed file under the wrong dos, it will laugh at you. . .Well, OK, it'll cry. If *anyone* has anything to say about how this is going to work, please e-mail me a note, do not post it. I am doing it entirely in assembly, but if someone wants me to download the C code and put it on the apple (for uu(en/de)code) I will, and I'm sure it will work just fine, as Aztec does things right, unlike APW C. Sean Kamath -- UUCP: {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath CSNET: reed!kamath@Tektronix.CSNET || BITNET: reed!kamath@PSUVAX1.BITNET ARPA: reed!kamath@PSUVAX1.CS.PSU.EDU US Snail: 3934 SE Boise, Portland, OR 97202-3126 (I hate 4 line .sigs!)
JDA@NIHCU.BITNET (Doug Ashbrook) (05/09/88)
> and presumably the Basic interface would take a little work. I'm curious > is anyone would like to see this as a utility. I haven't had any problems > with Executioner. If anyone has any real good reasons why uuencoded > material is better, please speak up. I do not know anything about uuencoded files, but if they contain anything other than alphbetics and numerals, they are likely to cause problems when they traverse the various translation tables of netland. Actually, I am being a little conservative, some of the special characters are also fairly well agreed upon. But characters like curly braces, backslash, vertical bar, etc. are frequently problems. Assumming that uuencoded files avoid this problem, I would be happy to see them become the mode of choice. ------------------------------------------------------------------- J. Douglas Ashbrook (301) 496-5181 BITNET: JDA@NIHCU ARPA: jda%nihcu.bitnet@cunyvm.cuny.edu National Institutes of Health, Computer Center, Bethesda, MD 20892
SEWALL@UCONNVM.BITNET (Murph Sewall) (05/09/88)
>In article <790@trwcsed.trwrb.UUCP> arenberg@trwcsed.UUCP (Jeff Arenberg) > writes: ><I'm curious is anyone would like to see this as a utility. I haven't >>had any problems with Executioner. If anyone has any real good ><reasons why uuencoded material is better, please speak up. > > It might be useful if you wanted to work with Apple binaries >on an other system or need to pack a non-text file on a non-Apple to >send to your Apple. Unless ASCII to EBCDIC translation will be required why wouldn't you just use binary (I've had no trouble transferring Apple II binary files back and forth on MS-DOS, heck even Commodore 64, BBS's)? It seems the main reason for contemplating an Apple 2 version of uuencode/uudecode is graphic files from the MS-DOS World likely to be encoded in that format. Are there any other examples? --------------------- Disclaimer: The "look and feel" of this message is exclusively MINE! (subject to change without notice; void where prohibited) ARPA: sewall%uconnvm.bitnet@mitvma.mit.edu Murphy A. Sewall BITNET: SEWALL@UCONNVM School of Business Admin. UUCP: ...ihnp4!psuvax1!UCONNVM.BITNET!SEWALL University of Connecticut Acknowledge-To: <SEWALL@UCONNVM>