rob@ireta.cynic.wimsey.bc.ca (Rob Prior) (02/06/91)
NORM%IONAACAD.BITNET@CUNYVM.CUNY.EDU (Norman Walsh) writes: > ... If memory serves, I've seen several postings > of ASC for PC's and, of course, there's always the one in my trusty '48. Could someone re-post the ASC-> source for PC's? I would assume that it is in c or some other readily accessible language? Is there also a ->ASC for PC's? +------------ | rob@ireta.cynic.wimsey.bc.ca | Rob Prior, President, Still Animation Logo Design +------------------------------------------------------------
pashdown@javelin.es.com (Pete Ashdown) (02/12/91)
I am having a real hard time trying to see why ASC is preferred over UUENCODE. Here are my points against ASC: 1. Bad if you are low on memory. For example, I wanted to try out Dr. Wickes' new modes browser. In its ASC form, it was 5363 bytes. I had 9K free, but still, I had to remove a directory temporarily to download it. Once I managed to convert it to a binary, it was 2635 bytes. Yes, almost half the size. I found that I could transfer this to and fro my machine with any conversion and without needing to delete the original directory that I did for ASC. 2. Pain in the butt. Again, if you are low on memory, you need to have twice the size of the ASC'd program available. One to store it, one to recall it to the stack. Isn't it much easier to UUDECODE it on the PC you are sending it from? 3. Not a standard form of transportation. How many times are we going to see "Where can I get ASC?" in the future? UUENCODE is widely available FOR ALL PC's. UNIX, VMS, IBM, Amiga, Atari, Mac. I think there is even an Apple II version available. If not, there are versions of UUENCODE available in BASIC. 4. How many times are we going to see a bad post of Tetris? Wouldn't it be nice if Andre could just send it to his machine in binary, UUENCODE it, then post it? Then we can UUDECODE it and make sure its valid before attempting to mess with downloading then trying to get "SETUP" to work. UUENCODE would eliminate a lot of problems with sending directories of mixed objects. That's my arguement. I'm just throwing this out, because I'm sick of ASC and the garbage that is associated with it. I would like to see and end to its use, but of course, not without the proper discussion. -- "Hi, we're 'Slaughter'. We'd just like to say how much we love our troops." Pete Ashdown pashdown@javelin.sim.es.com ...uunet!javelin.sim.es.com!pashdown
hoford@sequoia.upenn.edu (John Hoford) (02/12/91)
In article <1991Feb11.230500.9590@javelin.es.com> pashdown@javelin.sim.es.com writes: > >I am having a real hard time trying to see why ASC is preferred over UUENCODE. >Here are my points against ASC: >3. Not a standard form of transportation. How many times are we going to see >"Where can I get ASC?" in the future? UUENCODE is widely available FOR ALL >PC's. UNIX, VMS, IBM, Amiga, Atari, Mac. I think there is even an Apple II >version available. If not, there are versions of UUENCODE available in >BASIC. But UUENCODE is not available for the hp48sx, the intended machine. This seems to have been the major reason ASC was implemented, It also means you could not type in the binary progams. I my self would like them as uuencode'ed files.
creiman@headroom.ncsa.uiuc.EDU (Chuck Reiman) (02/13/91)
In article <37409@netnews.upenn.edu>, hoford@sequoia.upenn.edu (John Hoford) writes: > In article <1991Feb11.230500.9590@javelin.es.com> pashdown@javelin.sim.es.com writes: > > > >I am having a real hard time trying to see why ASC is preferred over UUENCODE. > >Here are my points against ASC: > > >3. Not a standard form of transportation. How many times are we going to see > >"Where can I get ASC?" in the future? UUENCODE is widely available FOR ALL > >PC's. UNIX, VMS, IBM, Amiga, Atari, Mac. I think there is even an Apple II > >version available. If not, there are versions of UUENCODE available in > >BASIC. > > But UUENCODE is not available for the hp48sx, the intended machine. > This seems to have been the major reason ASC was implemented, > It also means you could not type in the binary progams. > > I my self would like them as uuencode'ed files. ASC also has the advantage that the strings producded have actual meaing. They are the actual hex bytes of the object. This allows one to disassemble obejcts to see what makes them tick. Charlie Reiman creiman@ncsa.uiuc.edu
TDSTRONG%MTUS5.BITNET@CUNYVM.CUNY.EDU (* Tim Strong) (02/13/91)
> >I am having a real hard time trying to see why ASC is preferred over UUENCODE. >Here are my points against ASC: >... Your arguments are probably quite sound for one who has UUENCODE available. However while UUENCODE may be a standard I don't have it available and I'm probably not the only one. Second of all I've never had trouble using ASC. Most of the problems people are having seems to be with the fact that they are forgetting to remove the linefeeds at the end of some of the lines that the net adds in. My kermit can be set to remove these so its not a problem. Perhaps the best solution is to post it both ways if possible. ====================================================================== ___ :__) _ _: _ _ Tim Strong <tdstrong%mtus5.bitnet@cunyvm.edu> : \ (_: (_: (_: : Michigan Tech. Houghton, Michigan ======================================================================
pashdown@javelin.es.com (Pete Ashdown) (02/13/91)
hoford@sequoia.upenn.edu (John Hoford) writes: >In article <1991Feb11.230500.9590@javelin.es.com> pashdown@javelin.sim.es.com writes: >> >>I am having a real hard time trying to see why ASC is preferred over UUENCODE. >>Here are my points against ASC: >>3. Not a standard form of transportation. How many times are we going to see >>"Where can I get ASC?" in the future? UUENCODE is widely available FOR ALL >>PC's. UNIX, VMS, IBM, Amiga, Atari, Mac. I think there is even an Apple II >>version available. If not, there are versions of UUENCODE available in >>BASIC. >But UUENCODE is not available for the hp48sx, the intended machine. >This seems to have been the major reason ASC was implemented, >It also means you could not type in the binary progams. Anyone who would rather type in a huge hex dump than hack together a cable has got to be crazy. I'm not talking about using UUENCODE on the 48. How many people read this group via the 48? There is virtually ALWAYS an interfacing machine between the net and the 48. Its much easier to UUDECODE binaries on that machine then do a binary transfer on the 48 than the ASC method. As for the "disassembly" argument. Doesn't anyone have any utilities on their machines to dump out a file in hex/decimal/octal/ascii/whatever? ASC is hardly the utility for this. -- "Hi, we're 'Slaughter'. We'd just like to say how much we love our troops." Pete Ashdown pashdown@javelin.sim.es.com ...uunet!javelin.sim.es.com!pashdown
akcs.dnickel@hpcvbbs.UUCP (Derek S. Nickel) (02/13/91)
Pete,
UUENCODE/UUDECODE is far from being a standard. At least I have never
laid eyes on a version of UUENCODE for my PC.
The idea of the ASC routines is that they are totally independent of the
computer you use as host. You don't need a version of ASC for each
system that people might use.
Two things:
1) it would have been nice to have ASC built-in to the '48 (but its not)
2) a host-based (PC or other) program that would translate an ASC file to
binar with checksum validation. I think something like this has been
posted in the past, but I missed catching it.
As far as I can tell, UUENCODE is just as hard (or harder) to get as ASC.
Derek S. Nickelmadler@eeyore.caltech.edu (Mark Adler) (02/13/91)
Derek Nickel adds his five cents: >> At least I have never >> laid eyes on a version of UUENCODE for my PC. I've seen many. At the end of this message is the C source for uuencode and uudecode for Unix and MSDOS (MSC or Turbo). >> The idea of the ASC routines is that they are totally independent of the >> computer you use as host. You don't need a version of ASC for each >> system that people might use. Huh? You mean you have an ASC program that runs on any computer? Now that would be amazing, since they all use different processors, etc. Seriously though, the point about uuencode should be restated: "Why didn't Bill use the uuencode format for ASC instead of one of his own creation?" I'd have to leave it to Bill to answer that one. >> As far as I can tell, UUENCODE is just as hard (or harder) to get as ASC. It's as hard as copying it from the end of this message ... Mark Adler madler@pooh.caltech.edu --- uuencode.c --- /* * Copyright (c) 1983 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ /* * Modified 12 April 1990 by Mark Adler for use on MSDOS systems with * Microsoft C and Turbo C. Standard input problem fixed 29 April 1990 * as per suggestion by Steve Harrold. */ #ifndef lint static char sccsid[] = "@(#)uuencode.c 5.6 (Berkeley) 7/6/88"; #endif /* not lint */ #ifdef __MSDOS__ /* For Turbo C */ #define MSDOS 1 #endif /* * uuencode [input] output * * Encode a file so it can be mailed to a remote system. */ #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #if MSDOS #include <io.h> #include <fcntl.h> #endif /* ENC is the basic 1 character encoding function to make a char printing */ #define ENC(c) ((c) ? ((c) & 077) + ' ': '`') main(argc, argv) char **argv; { FILE *in; struct stat sbuf; int mode; /* optional 1st argument */ if (argc > 2) { if ((in = fopen(argv[1], "r")) == NULL) { perror(argv[1]); exit(1); } argv++; argc--; } else in = stdin; #if MSDOS /* set input file mode to binary for MSDOS systems */ setmode(fileno(in), O_BINARY); #endif if (argc != 2) { fprintf(stderr,"Usage: uuencode [infile] remotefile\n"); exit(2); } /* figure out the input file mode */ if (fstat(fileno(in), &sbuf) < 0 || !isatty(fileno(in))) mode = 0666 & ~umask(0666); else mode = sbuf.st_mode & 0777; printf("begin %o %s\n", mode, argv[1]); encode(in, stdout); printf("end\n"); exit(0); } /* * copy from in to out, encoding as you go along. */ encode(in, out) register FILE *in; register FILE *out; { char buf[80]; register int i, n; for (;;) { /* 1 (up to) 45 character line */ n = fread(buf, 1, 45, in); putc(ENC(n), out); for (i=0; i<n; i += 3) outdec(&buf[i], out); putc('\n', out); if (n <= 0) break; } } /* * output one group of 3 bytes, pointed at by p, on file f. */ outdec(p, f) register char *p; register FILE *f; { register int c1, c2, c3, c4; c1 = *p >> 2; c2 = (*p << 4) & 060 | (p[1] >> 4) & 017; c3 = (p[1] << 2) & 074 | (p[2] >> 6) & 03; c4 = p[2] & 077; putc(ENC(c1), f); putc(ENC(c2), f); putc(ENC(c3), f); putc(ENC(c4), f); } --- uudecode.c --- /* * Copyright (c) 1983 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ /* * Modified 12 April 1990 by Mark Adler for use on MSDOS systems with * Microsoft C and Turbo C. */ #ifndef lint static char sccsid[] = "@(#)uudecode.c 5.5 (Berkeley) 7/6/88"; #endif /* not lint */ #ifdef __MSDOS__ /* For Turbo C */ #define MSDOS 1 #endif /* * uudecode [input] * * create the specified file, decoding as you go. * used with uuencode. */ #include <stdio.h> #ifndef MSDOS #include <pwd.h> #endif #include <sys/types.h> #include <sys/stat.h> /* single character decode */ #define DEC(c) (((c) - ' ') & 077) main(argc, argv) char **argv; { FILE *in, *out; int mode; char dest[128]; char buf[80]; /* optional input arg */ if (argc > 1) { if ((in = fopen(argv[1], "r")) == NULL) { perror(argv[1]); exit(1); } argv++; argc--; } else in = stdin; if (argc != 1) { printf("Usage: uudecode [infile]\n"); exit(2); } /* search for header line */ for (;;) { if (fgets(buf, sizeof buf, in) == NULL) { fprintf(stderr, "No begin line\n"); exit(3); } if (strncmp(buf, "begin ", 6) == 0) break; } (void)sscanf(buf, "begin %o %s", &mode, dest); /* handle ~user/file format */ #ifndef MSDOS if (dest[0] == '~') { char *sl; struct passwd *getpwnam(); struct passwd *user; char dnbuf[100], *index(), *strcat(), *strcpy(); sl = index(dest, '/'); if (sl == NULL) { fprintf(stderr, "Illegal ~user\n"); exit(3); } *sl++ = 0; user = getpwnam(dest+1); if (user == NULL) { fprintf(stderr, "No such user as %s\n", dest); exit(4); } strcpy(dnbuf, user->pw_dir); strcat(dnbuf, "/"); strcat(dnbuf, sl); strcpy(dest, dnbuf); } #endif /* create output file */ #ifdef MSDOS out = fopen(dest, "wb"); /* Binary file */ #else out = fopen(dest, "w"); #endif if (out == NULL) { perror(dest); exit(4); } #ifndef MSDOS chmod(dest, mode); #endif decode(in, out); if (fgets(buf, sizeof buf, in) == NULL || strcmp(buf, "end\n")) { fprintf(stderr, "No end line\n"); exit(5); } exit(0); } /* * copy from in to out, decoding as you go along. */ decode(in, out) FILE *in; FILE *out; { char buf[80]; char *bp; int n; for (;;) { /* for each input line */ if (fgets(buf, sizeof buf, in) == NULL) { printf("Short file\n"); exit(10); } n = DEC(buf[0]); if (n <= 0) break; bp = &buf[1]; while (n > 0) { outdec(bp, out, n); bp += 4; n -= 3; } } } /* * output a group of 3 bytes (4 input characters). * the input chars are pointed to by p, they are to * be output to file f. n is used to tell us not to * output all of them at the end of the file. */ outdec(p, f, n) char *p; FILE *f; { int c1, c2, c3; c1 = DEC(*p) << 2 | DEC(p[1]) >> 4; c2 = DEC(p[1]) << 4 | DEC(p[2]) >> 2; c3 = DEC(p[2]) << 6 | DEC(p[3]); if (n >= 1) putc(c1, f); if (n >= 2) putc(c2, f); if (n >= 3) putc(c3, f); } /* * Return the ptr in sp at which the character c appears; * NULL if not found */ #define NULL 0 char * index(sp, c) register char *sp, c; { do { if (*sp == c) return(sp); } while (*sp++); return(NULL); } --- end ---
madler@eeyore.caltech.edu (Mark Adler) (02/13/91)
By the way, I don't remember if this was mentioned on this thread, but the uuencode format is more efficient than asc, since uuencode puts six bits in a character, where asc only puts four. Mark Adler madler@pooh.caltech.edu
cloos@acsu.buffalo.edu (James H. Cloos) (02/13/91)
In article <37409@netnews.upenn.edu> hoford@sequoia.upenn.edu (John Hoford) writes: >In article <1991Feb11.230500.9590@javelin.es.com> pashdown@javelin.sim.es.com writes: >> >>I am having a real hard time trying to see why ASC is preferred over UUENCODE. >>Here are my points against ASC: > >>3. Not a standard form of transportation. How many times are we going to see >>"Where can I get ASC?" in the future? UUENCODE is widely available FOR ALL >>PC's. UNIX, VMS, IBM, Amiga, Atari, Mac. I think there is even an Apple II >>version available. If not, there are versions of UUENCODE available in >>BASIC. > >But UUENCODE is not available for the hp48sx, the intended machine. >This seems to have been the major reason ASC was implemented, >It also means you could not type in the binary progams. > >I my self would like them as uuencode'ed files. For those who are interested, below is the format of uuencoded files. I know I said that I'd work on translating it to the 48, but I've been flooded by rplc, a project for class (a Huffman encoding exercise) and various other hw assignments, ergo: not uuencode/decode for the 48 from me for a while! If anyone else wants to try, it looks like this: Files output by uuencode(1C) consist of a header line, fol- lowed by a number of body lines, and a trailer line. uudecode (see uuencode(1C)) will ignore any lines preceding the header or following the trailer. Lines preceding a header must not, of course, look like a header. The header line is distinguished by having the first 6 char- acters `begin '. The word begin is followed by a mode (in octal), and a string which names the remote file. Spaces separate the three items in the header line. The body consists of a number of lines, each at most 62 characters long (including the trailing NEWLINE). These con- sist of a character count, followed by encoded characters, followed by a NEWLINE. The character count is a single printing character, and represents an integer, the number of bytes the rest of the line represents. Such integers are always in the range from 0 to 63 and can be determined by subtracting the character space (octal 40) from the charac- ter. Groups of 3 bytes are stored in 4 characters, 6 bits per character. All are offset by a SPACE to make the characters printing. The last line may be shorter than the normal 45 bytes. If the size is not a multiple of 3, this fact can be determined by the value of the count on the last line. Extra garbage will be included to make the character count a multiple of 4. The body is terminated by a line with a count of zero. This line consists of one ASCII SPACE. The trailer line consists of end on a line by itself. (exerpted from uuencode.5 man page from SunOS 4.1.1 w/o perm.) -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
edp@jareth.enet.dec.com (Always mount a scratch monkey.) (02/13/91)
> . . .There is virtually ALWAYS an interfacing >machine between the net and the 48. Its much easier to UUDECODE binaries on >that machine then do a binary transfer on the 48 than the ASC method. Binary file on one system -> UUENCODE -> UUDECODE on another system -- that sequence is not guaranteed to produce an identical binary file, particularly not one that will download correctly to the HP-48 -- differences caused by file attributes or formats of a particular system's binary files can cause problems. I have been able to get binary objects to and from my 48, but I cannot count on receiving them correctly, even with UUDECODE. I need ASC or a version of UUDECODE that runs on the 48. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
e88cb@efd.lth.se (Christer Boberg) (02/13/91)
In Article 4917 akcs.dnickel@hpcvbbs.UUCP (Derek S. Nickel) says: > As far as I can tell, UUENCODE is just as hard (or harder) to get as ASC. This PC-man doesn't seem to read comp.binaries.ibm.pc . Recently someone dropped a complete package for uuencoding and uudecodeing files on a MesSy-DOS-machine there, and this goes for the Amiga too, And most of us, as said before, have UNIX (how can you else read this?) at school, and therefore must have NO problem messing with UUDECODE ! Yes, send files with uuencoding, we've done that for a VERY long time when it comes to home-computer-files-over-the-net.
lennartb@lne.kth.se (Lennart Brjeson @ KTH, Stockholm) (02/13/91)
In article <1991Feb13.101558.5056@lth.se>, e88cb@efd.lth.se (Christer Boberg) writes: > >In Article 4917 akcs.dnickel@hpcvbbs.UUCP (Derek S. Nickel) says: > >> As far as I can tell, UUENCODE is just as hard (or harder) to get as ASC. > >This PC-man doesn't seem to read comp.binaries.ibm.pc . Recently >someone dropped a complete package for uuencoding and uudecodeing >files on a MesSy-DOS-machine there, and this goes for the Amiga too, >And most of us, as said before, have UNIX (how can you else read this?) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Because there are DOZENS of other kinds of systems on the Usenet!!!! ASC-> is machine independant, as it runs on the target machine. Those who have a C compiler on their host can get PD versions of ASC->. >at school, and therefore must have NO problem messing with UUDECODE ! > >Yes, send files with uuencoding, we've done that for a VERY long time >when it comes to home-computer-files-over-the-net. Remember that not everyone has Unix or even C. Use ASC->. !++ ! Lennart Boerjeson, System Manager ! School of Electrical Engineering ! Royal Institute of Technology ! S-100 44 Stockholm, Sweden ! tel: int+46-8-7907814 ! Internet: lennartb@lne.kth.se !--
akcs.dnickel@hpcvbbs.UUCP (Derek S. Nickel) (02/14/91)
Christer Boberg writes: >This PC-man doesn't seem to read comp.binaries.ibm.pc ... No, I don't read comp.binaries.ibm.pc. The reaon being that the ONLY link that I have is via the HPBBS (that's also why I don't have access to a UN*X machine.) Derek S. Nickel
darrylo@hpnmdla.HP.COM (Darryl Okahata) (02/14/91)
In comp.sys.handhelds, akcs.dnickel@hpcvbbs.UUCP (Derek S. Nickel) writes: > UUENCODE/UUDECODE is far from being a standard. At least I have never > laid eyes on a version of UUENCODE for my PC. I've seen at least two versions (in ready-to-run binaries) for the PC (and Mark Adler just posted some sources). -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@hp-sde.sde.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.
cloos@acsu.buffalo.edu (James H. Cloos) (02/14/91)
I feel compeled to mention one point that I left out of my immediatly previous post on this subject: ASC includes a CRC, uuencode does not. On a machine such as the 48, where incorrect binaries can cause a MEM LOST, and not everyone is able to backup to a computer (I'm currently stuck w/ backing up to a ram card which I do not take out (though sometimes FREE and set to R/O)). ASC will tell you the string is invalid if there is any coruption; uudecode will not, and could cause problems. (I don't want to create another immense flame war (asbestos suits can be expensive); I hope that we can get back to the more interesting posts!) -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: "If you miss any humor, too bad!"
madler@pooh.caltech.edu (Mark Adler) (02/14/91)
James H. Cloos points out:
>> ASC includes a CRC, uuencode does not.
A *very* important point, but easily worked around, since the HP has a
BYTES command for checking just that sort of thing. As for HP binary
objects generated outside the HP (like by an assembler), if they can
generate an ASC-> format, then they can just as easily compute the
result of BYTES (since ASC uses the same crc) for use with uuencode.
I believe the wide availability of uuencode/decode for many machines
(a fact apparently still disputed) makes it more portable than ASC which
is available on only one machine (the HP-48SX). This is particularily
important when you want to save time and memory by doing a binary download
into your calculator.
One solution is to have a portable ->ASC-> converter, but why bother when
uu* is already in place, and is more efficient (by 50%) in mail bandwidth?
Mark Adler
madler@pooh.caltech.edufrechett@spot.Colorado.EDU (-=Runaway Daemon=-) (02/14/91)
In article <1991Feb14.015132.10732@nntp-server.caltech.edu> madler@pooh.caltech.edu (Mark Adler) writes: [...] >I believe the wide availability of uuencode/decode for many machines >(a fact apparently still disputed) makes it more portable than ASC which >is available on only one machine (the HP-48SX). This is particularily ^^^^^^^^^^^ >important when you want to save time and memory by doing a binary download >into your calculator. > >One solution is to have a portable ->ASC-> converter, but why bother when ^^^^^^^^ ^^^^^ >uu* is already in place, and is more efficient (by 50%) in mail bandwidth? > >Mark Adler >madler@pooh.caltech.edu DESC: A C version of the ASC-> decoder. Works on most any machine with C. >Article 1430 of comp.sys.handhelds: >Path: csn!ncar!elroy.jpl.nasa.gov!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!rnews!hpcvbbs!akcs.wilsonpm >From: akcs.wilsonpm@hpcvbbs.UUCP (Pete M. Wilson) >Newsgroups: comp.sys.handhelds >Subject: Re: ASC-> for UNIX >Message-ID: <2798e77c:1547.1comp.sys.handhelds;1@hpcvbbs.UUCP> >Date: 20 Jan 91 01:40:06 GMT >References: <1990Dec31.080317.12174@csn.org> >Lines: 267 This is my C version of ASC->. It was written on a PC & compiled with Microsoft C & Turbo C++. I used ANSI C functions (mostly). I hope it will help you. Pete P.S. If I can get it uploaded! # additional notes. May have to edit section on strerror as some machines # don't understand. I changed to stderr.. Crude but it works. ------------------------------CUT HERE-------------------------------- This programs reads an up to 127K ASCII (RPL) file consisting of a string intended for ASC-> and converts it into a binary object file. This program was compiled with Microsoft C 5.1 and Turbo C. ANSI C conventions are mostly followed. The original algorithm for CRC computation was extracted from Li Sheng's posting to comp.sys.handhelds. 01/19/91 PMW created */ #include <stdlib.h> #include <stdio.h> #include <string.h> #include <ctype.h> #include <errno.h> #define MAX_READ_SIZE 127 #if !defined(FILENAME_MAX) #define FILENAME_MAX 65 #endif #if !defined(EXIT_FAILURE) #define EXIT_FAILURE 1 #endif #if !defined(EXIT_SUCCESS) #define EXIT_SUCCESS 0 #endif #define HEX2INT(hc) ((unsigned int) (isdigit(hc) ? (hc)-'0' : (hc)-'A'+10)) int FileExists(char *f) { FILE *tf; if ((tf = fopen(f, "rb")) != NULL) { fclose(tf); return 1; } else return 0; } long FileSize(FILE *f) { long origPos = ftell(f), fileSize = 0; fseek(f, 0L, SEEK_END); fileSize = ftell(f); fseek(f, origPos, SEEK_SET); return fileSize; } typedef unsigned char BYTE; typedef unsigned int WORD; #define CALC_CRC(c, i) (((((c)^(i)) & 0xF) * 0x1081) ^ ((c) >> 4)) WORD crcBlock(BYTE *mb, size_t len) { WORD crc = 0, bObjSize = len/2; while (bObjSize--) { crc = CALC_CRC(crc, (WORD) (*mb) & 0xF); crc = CALC_CRC(crc, (WORD) ((*mb) >> 4)); ++mb; } if (len & 1) crc = CALC_CRC(crc, (WORD) (*mb) & 0xF); return crc; } void CopyLine(BYTE **mb, char **s, WORD *objSize) { char *ts = *s; BYTE *tmb = *mb; WORD ls = 0; while (isxdigit(ts[0]) && isxdigit(ts[1])) { *tmb++ = (BYTE) (HEX2INT(ts[0]) + (HEX2INT(ts[1]) << 4)); ls += 2; ts += 2; } if (isxdigit(ts[0]) && ts[1] == '"') { /* we ended on a nibble boundary!! */ BYTE crc1, crc2; /* correct crc by nibble shifting end */ crc2 = (BYTE) ((tmb[-1] >> 4) + (HEX2INT(ts[0]) << 4)); crc1 = (BYTE) ((tmb[-2] >> 4) + ((tmb[-1] & 0xF) << 4)); /* fix memory buffer */ tmb[-2] &= 0xf; tmb[-1] = crc1; *tmb++ = crc2; ++ls; ++ts; } *s = ts; *mb = tmb; *objSize += ls; } #define READLN(s, f) fgets((s), sizeof(s), (f)) void ReadFile(char *filepath, BYTE **mb, WORD *objSize) { FILE *infile; char lineBuf[250], *p; WORD bufSize; long fileSize; BYTE *wmb; if (!strchr(filepath, '.')) strcat(filepath, ".rpl"); if (!(infile = fopen(filepath, "r"))) { fprintf(stderr, "asc2bin: can't open %s\n", filepath); exit(EXIT_FAILURE); } fileSize = FileSize(infile); if (fileSize > MAX_READ_SIZE*1024L) { fprintf(stderr, "asc2bin: File %s is too long\n", filepath); exit(EXIT_FAILURE); } bufSize = 4+(WORD) (fileSize / 2); /* approximate byte size of object */ if (!(*mb = (BYTE *) malloc(bufSize))) { fprintf(stderr, "asc2bin: Unable to allocate %u bytes\n", bufSize); exit(EXIT_FAILURE); } wmb = *mb; /* find string */ while (!feof(infile)) { if (!READLN(lineBuf, infile)) { if (feof(infile)) fputs("asc2bin: Unable to locate string\n", stderr); else fprintf(stderr, "asc2bin: Read error: %s\n", strerror(errno)); fclose(infile); exit(EXIT_FAILURE); } if (*lineBuf == '"') break; } *objSize = 0; /* put string into buffer */ p = &lineBuf[1]; /* skip opening quote */ CopyLine(&wmb, &p, objSize); /* copy remainder into buffer */ while (*p != '"' && !feof(infile)) { if (!READLN(lineBuf, infile)) { if (feof(infile)) fputs("asc2bin: Unable to locate closing quote\n", stderr); else fprintf(stderr, "asc2bin: Read error: %s\n", strerror(errno)); fclose(infile); exit(EXIT_FAILURE); } p = lineBuf; CopyLine(&wmb, &p, objSize); } fclose(infile); } void WriteFile(char *filepath, BYTE *mb, WORD objSize) { FILE *outfile; char *extpos = strchr(filepath, '.'); strcpy(extpos+1, "bin"); if (FileExists(filepath)) { fprintf(stderr, "asc2bin: file already exists: %s\n", filepath); exit(EXIT_FAILURE); } if (!(outfile = fopen(filepath, "wb"))) { fprintf(stderr, "asc2bin: unable to create %s\n", filepath); exit(EXIT_FAILURE); } fputs("HPHP48-C", outfile); /* my own version */ while (objSize--) fputc(*mb++, outfile); fclose(outfile); } main(int argc, char *argv[]) { char filepath[FILENAME_MAX]; BYTE *mb; WORD objSize, rcrc, crc,bObjSize; /* NOTE: objSize is in nibbles! */ if (argc < 2) { fputs("usage: asc2bin infile[.ext]\n", stderr); fputs("\treads infile.ext and creates infile.bin\n", stderr); fputs("\tif omitted, .ext is assumed to be .rpl\n", stderr); exit(EXIT_FAILURE); } strcpy(filepath, argv[1]); ReadFile(filepath, &mb, &objSize); if (objSize < 2) { fputs("asc2bin: String too short to include crc\n", stderr); exit(EXIT_FAILURE); } objSize -= 4; /* nibbles */ bObjSize = objSize / 2 + (objSize & 1); rcrc = (WORD) mb[bObjSize] + ((WORD) mb[bObjSize+1] << 8); crc = crcBlock(mb, objSize); if (crc != rcrc) { fprintf(stderr, "asc2bin: Calculated CRC # %Xh does not match read CRC # %Xh\n", crc, rcrc); exit(EXIT_FAILURE); } WriteFile(filepath, mb, bObjSize); return EXIT_SUCCESS; } ------------------------------CUT HERE-------------------------------- NOTE: I forgot that some of my lines would wrap because of the line number - The code will need to be cleaned up. I'll upload the source & a self-unzipping PC archive (with executable) in user.programs.
NORM%IONAACAD.BITNET@CUNYVM.CUNY.EDU (Norman Walsh) (02/14/91)
UUEncoding has a real deficiency over ASC. It cannot be sent reliably
from point A to point B. Specifically, if the receiver is on an IBM
mainframe the fact that uuencoded files contain square brackets is
always a problem. IBM's EBCDIC character set doesn't have them. It may
even be a problem if there is simply an IBM mainframe somewhere in the
path from point A to point B, but I think that is less commonly a problem.
In other circles, I always advocate XXEncoding which is a simple variation
on UUEncoding (the same algorithm 'cept it uses the letters A-Z in upper
and lower case, the digits and +/- instead of space through ASCII 95) but
here I think ASC is fine. If memory serves, I've seen several postings
of ASC for PC's and, of course, there's always the one in my trusty '48.
ndwmcgrant@elaine30.stanford.edu (Michael Grant) (02/15/91)
How about a portable version of ASC-> and ->ASC in C which is available over FTP and mailservers (yes, I know some exist), AND which is distributed in EXECUTABLE form on the HP software disks included with the cables? (Heck, why not put the HP48 ASC-> and ->ASC programs on the disks too)? That way, all that whining about UUENCODE would be bunk, because you could ALWAYS transmit to and from your computer in binary, the format would not suffer from ASCII-EBDIC translation or what-not, and everyone would have the same programs anyway. Mike
madler@pooh.caltech.edu (Mark Adler) (02/15/91)
>> How about a portable version of ASC-> and ->ASC in C I portabilized Pete Wilson's program that was recently posted and I am posting it at the end of this message. >> AND which is distributed in EXECUTABLE form I leave it to others to compile it for PC's or whatnot and put it on some ftp site. >> on the HP software disks included with the cables? Well, I would prefer a uu-like thing instead. But until then, this program should be useful. >> That way, all that whining about UUENCODE would be bunk Not in my opinion, but I won't rehash what I've posted already. Mark Adler madler@pooh.caltech.edu --- asc2bin.c --- /* This programs reads an up to 127K ASCII (RPL) file consisting of a string intended for ASC-> and converts it into a binary object file. This program was compiled with Microsoft C 5.1 and Turbo C. ANSI C conventions are mostly followed. The original algorithm for CRC computation was extracted from Li Sheng's posting to comp.sys.handhelds. 01/19/91 PMW created 02/14/91 MAdler modified for portability */ #include <stdio.h> #include <errno.h> #ifdef __STDC__ # define MODERN #endif #ifdef __TURBOC__ # ifndef MODERN # define MODERN # endif #endif #ifdef MODERN # include <stdlib.h> # include <string.h> # include <ctype.h> # define FOPR "rb" # define FOPW "wb" #else # define void int # define size_t unsigned int extern char *strcat(); extern char *strcpy(); # define FOPR "r" # define FOPW "w" #endif typedef unsigned char BYTE; typedef unsigned int WORD; /* Function prototypes for ANSI C */ #ifdef MODERN int FileExists(char *); long FileSize(FILE *); WORD crcBlock(BYTE *, size_t); void CopyLine(BYTE **, char **, WORD *); void ReadFile(char *, BYTE **, WORD *); void WriteFile(char *, BYTE *, WORD ); int main(int, char **); #endif #define MAX_READ_SIZE 127 #ifndef FILENAME_MAX # define FILENAME_MAX 65 #endif #ifndef EXIT_FAILURE # define EXIT_FAILURE 1 #endif #ifndef EXIT_SUCCESS # define EXIT_SUCCESS 0 #endif #ifndef SEEK_SET # define SEEK_SET 0 #endif #ifndef SEEK_END # define SEEK_END 2 #endif #ifndef isxdigit # define isxdigit(c) (c >= '0' && c <= '9' || c >= 'A' && c <= 'F') #endif #define HEX2INT(hc) ((unsigned int) (isdigit(hc) ? (hc)-'0' : (hc)-'A'+10)) int FileExists(f) char *f; { FILE *tf; if ((tf = fopen(f, FOPR)) != NULL) { fclose(tf); return 1; } else return 0; } long FileSize(f) FILE *f; { long origPos = ftell(f), fileSize = 0; fseek(f, 0L, SEEK_END); fileSize = ftell(f); fseek(f, origPos, SEEK_SET); return fileSize; } #define CALC_CRC(c, i) (((((c)^(i)) & 0xF) * 0x1081) ^ ((c) >> 4)) WORD crcBlock(mb, len) BYTE *mb; size_t len; { WORD crc = 0, bObjSize = len/2; while (bObjSize--) { crc = CALC_CRC(crc, (WORD) (*mb) & 0xF); crc = CALC_CRC(crc, (WORD) ((*mb) >> 4)); ++mb; } if (len & 1) crc = CALC_CRC(crc, (WORD) (*mb) & 0xF); return crc; } void CopyLine(mb, s, objSize) BYTE **mb; char **s; WORD *objSize; { char *ts = *s; BYTE *tmb = *mb; WORD ls = 0; while (isxdigit(ts[0]) && isxdigit(ts[1])) { *tmb++ = (BYTE) (HEX2INT(ts[0]) + (HEX2INT(ts[1]) << 4)); ls += 2; ts += 2; } if (isxdigit(ts[0]) && ts[1] == '"') { /* we ended on a nibble boundary!! */ BYTE crc1, crc2; /* correct crc by nibble shifting end */ crc2 = (BYTE) ((tmb[-1] >> 4) + (HEX2INT(ts[0]) << 4)); crc1 = (BYTE) ((tmb[-2] >> 4) + ((tmb[-1] & 0xF) << 4)); /* fix memory buffer */ tmb[-2] &= 0xf; tmb[-1] = crc1; *tmb++ = crc2; ++ls; ++ts; } *s = ts; *mb = tmb; *objSize += ls; } #define READLN(s, f) fgets((s), sizeof(s), (f)) void ReadFile(filepath, mb, objSize) char *filepath; BYTE **mb; WORD *objSize; { FILE *infile; char lineBuf[250], *p; WORD bufSize; long fileSize; BYTE *wmb; if (!strchr(filepath, '.')) strcat(filepath, ".rpl"); if (!(infile = fopen(filepath, "r"))) { fprintf(stderr, "asc2bin: can't open %s\n", filepath); exit(EXIT_FAILURE); } fileSize = FileSize(infile); if (fileSize > MAX_READ_SIZE*1024L) { fprintf(stderr, "asc2bin: File %s is too long\n", filepath); exit(EXIT_FAILURE); } bufSize = 4+(WORD) (fileSize / 2); /* approximate byte size of object */ if (!(*mb = (BYTE *) malloc(bufSize))) { fprintf(stderr, "asc2bin: Unable to allocate %u bytes\n", bufSize); exit(EXIT_FAILURE); } wmb = *mb; /* find string */ while (!feof(infile)) { if (!READLN(lineBuf, infile)) { if (feof(infile)) fputs("asc2bin: Unable to locate string\n", stderr); else perror("asc2bin: Read error"); fclose(infile); exit(EXIT_FAILURE); } if (*lineBuf == '"') break; } *objSize = 0; /* put string into buffer */ p = &lineBuf[1]; /* skip opening quote */ CopyLine(&wmb, &p, objSize); /* copy remainder into buffer */ while (*p != '"' && !feof(infile)) { if (!READLN(lineBuf, infile)) { if (feof(infile)) fputs("asc2bin: Unable to locate closing quote\n", stderr); else perror("asc2bin: Read error"); fclose(infile); exit(EXIT_FAILURE); } p = lineBuf; CopyLine(&wmb, &p, objSize); } fclose(infile); } void WriteFile(filepath, mb, objSize) char *filepath; BYTE *mb; WORD objSize; { FILE *outfile; char *extpos = strchr(filepath, '.'); strcpy(extpos+1, "bin"); if (FileExists(filepath)) { fprintf(stderr, "asc2bin: file already exists: %s\n", filepath); exit(EXIT_FAILURE); } if (!(outfile = fopen(filepath, FOPW))) { fprintf(stderr, "asc2bin: unable to create %s\n", filepath); exit(EXIT_FAILURE); } fputs("HPHP48-C", outfile); /* my own version */ while (objSize--) fputc(*mb++, outfile); fclose(outfile); } int main(argc, argv) int argc; char **argv; { char filepath[FILENAME_MAX]; BYTE *mb; WORD objSize, rcrc, crc,bObjSize; /* NOTE: objSize is in nibbles! */ if (argc < 2) { fputs("usage: asc2bin infile[.ext]\n", stderr); fputs("\treads infile.ext and creates infile.bin\n", stderr); fputs("\tif omitted, .ext is assumed to be .rpl\n", stderr); exit(EXIT_FAILURE); } strcpy(filepath, argv[1]); ReadFile(filepath, &mb, &objSize); if (objSize < 2) { fputs("asc2bin: String too short to include crc\n", stderr); exit(EXIT_FAILURE); } objSize -= 4; /* nibbles */ bObjSize = objSize / 2 + (objSize & 1); rcrc = (WORD) mb[bObjSize] + ((WORD) mb[bObjSize+1] << 8); crc = crcBlock(mb, objSize); if (crc != rcrc) { fprintf(stderr, "asc2bin: Calculated CRC # %Xh does not match read CRC # %Xh\n", crc, rcrc); exit(EXIT_FAILURE); } WriteFile(filepath, mb, bObjSize); return EXIT_SUCCESS; }
darrylo@hpnmdla.HP.COM (Darryl Okahata) (02/16/91)
In comp.sys.handhelds, lennartb@lne.kth.se (Lennart Brjeson @ KTH, Stockholm) writes: > Because there are DOZENS of other kinds of systems on the Usenet!!!! > ASC-> is machine independant, as it runs on the target machine. > Those who have a C compiler on their host can get PD versions of ASC->. Those who have a C compiler on their host can also get freely copyable versions of uuencode/uudecode. -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@hp-sde.sde.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day. Also, I'm just a user of the 48SX; while I work for HP, I don't have anything to do with the HP division that makes calculators.
akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (02/16/91)
Look, Mark, chill. Use ASC, trust me.
1) Mark's wonderful argument is that UUENCODE?DECODE is widely available
for all machines unlike ASC which is only available for 48's. He then
goes on to say that the this fact is widely disputed. Think for a sec,
Mark. If people disagree with you, and say that they don't think that
uuencode is widely available, doesn't this mean that they don't have
uuencode (like me, and I know I never heard of it before I joined c.s.h)
and they don't know of many people with it? Personaly, I have a MAc, and
I don't feel like converting your Turbo C program into a more modern
format which my Lightspeed C can better understand. UU is not in place
everwhere, and it's a pain to put into place.
2) ASC is available for the one machine which it needs: the 48. ASC can
be posted or mailed to someone in about a minute, and all you do is
transfer it to your hp, hit a button, and voila, you have your converter.
I have ASC and I can give it to anyoje, no matter if they are using a
SUN, Mac, Tnady, Atari, IBM, or a PET to get the files onto their 48.
Anyone can use ASC on their 48, and they dont' have toorry about digging
out a C program or a basic program, or using UNIX, etc.
3) I like the ASC format better. With this board, I have problems with
the board not catching everything that I am throwing at it. With ASC, I
can tell if it messus up by looking at what it got. With UU, I can't,
it's all gibberish to me anyways.
4) ASC is useful for other things, like Internals programming.
5) I don't care about bandwith, it's not that much of a difference. Who
cares about even a 50% larger file, when I only have to ASC a few ML
routines or other small sections of my larger progrmas.
6) ASC is here. Almost everyone has it on the 48. If they don't I'll
post it up again, when my last posting gets dropped (1805 on c.s.h.))
----Falcokaufman@delta.eecs.nwu.edu (Michael L. Kaufman) (02/16/91)
In article <1991Feb11.230500.9590@javelin.es.com> pashdown@javelin.sim.es.com writes: >3. Not a standard form of transportation. How many times are we going to see >"Where can I get ASC?" in the future? UUENCODE is widely available FOR ALL >PC's. UNIX, VMS, IBM, Amiga, Atari, Mac. I think there is even an Apple II >version available. If not, there are versions of UUENCODE available in BASIC. Two problems with this argument. 1) The only difference that this would cause would be that people would constantly be asking for UUENCODE instead of ASC. 2) UUENCODE may or may not be available on every machine. We do know that ASC is available on the one machine that everyone interested has; the 48sx. Michael Michael Kaufman | I've seen things you people wouldn't believe. Attack ships on kaufman | fire off the shoulder of Orion. I watched C-beams glitter in @eecs.nwu.edu | the dark near the Tannhauser gate. All those moments will be | lost in time - like tears in rain. Time to die. Roy Batty
madler@owl.caltech.edu (Mark Adler) (02/17/91)
Andrey Dolgachev suggests: >> Look, Mark, chill. Use ASC, trust me. Well, I *do* use ASC, and I'm rather glad Bill Wickes wrote it and gave it to us out of the kindness of his heart. If I really cared about the issue, I'd write a uu-format version of ASC and let natural selection take its course. In all truth, I just like to argue sometimes. I get the impression that most people think ASC is just fine, so I won't try to convince anyone anymore with my steel-clad logic. However, in the pursuit of the pleasure of debate, I will answer Andrey's points. Those bored with the whole thing can junk this message now ... >> 1) ... UU is not in place everwhere, and it's a pain to put into place. >> 2) ASC is available for the one machine which it needs: the 48. ... >> 4) ASC is useful for other things, like Internals programming. ... >> 6) ASC is here. Almost everyone has it on the 48. The issue, as I see it, is simply: "Why doesn't ASC use a UU-compatible format?" In other words, I'm imagining a near future in which there are two versions of ASC, the current one, and one that is compatible with the uu-format. Which one is better? Obviously ASC is better if it's the only thing available, as is the case presently (point 6 above). In that light, I would answer 1) ASC is in place nearly nowhere, 2) The uu-ASC is also on the 48 (remember, we're in this hypothetical future), and 4) The old ASC is still there for you to use as a poor substitute for a hex editor on the HP. I should add here that I concede Andrey's point that uuencode/decode is not as widely available as I implied. However, it is no harder to get uuencode to work on the Mac than ASC is, and I'd lay fairly good odds that someone has uu* on the Mac already. >> 5) I don't care about bandwith, it's not that much of a difference. Well, I have to admit that I don't care that much about it either. After all, I don't pay for it. That was a pretty weak argument on my part. However, I think you *will* care when people get HP-48 compilers working, and you find it taking forever to get the object code into the HP, and then failing because there's not enough memory left to make the object. Then that 50% will start to seem significant. On the other hand, the way I do it is to always use binary in and out of the calculator for such things, and that is where ASC is lacking, since most people don't have an ASC on their machine. The same arguments apply about not having C compilers that was used against UU*--but there are object versions of UU* out there for PC's, and I suspect Macs as well. And it's always there on Unix machines. >> 3) With ASC, I can tell if it messus up by looking at what it got. With >> UU, I can't, it's all gibberish to me anyways. I know I wouldn't be able to spot a missing line in the ASC *or* UU format. If Andrey can, he's a better man than I. However, the UU format is just as structured as ASC's, if not more so (lines start with an "M", there's a begin at the beginning and an end at end). Anyway, what's relevant is whether the resulting object is faithful after it has been mangled by kermit, ftp, uu*, asc, what have you. This brings up a point that Andrey *didn't* mention, which is, in my opinion, the strongest argument against the uu-format. ASC has a CRC check. My response is that I consider ASC's crc check a welcome, additional error check in a long line of error checking done by ftp, kermit, internet, etc. But, I would like to urge everyone to *always* include the result of BYTES on an object that you post, whether it is in ASC form, ASCII upload form, or typed in, and whether the object is a user program or in RPL/machine code. Then, the lack of a crc in the uu-format is not a problem. Mark Adler madler@pooh.caltech
silvert@cs.dal.ca (Bill Silvert) (05/10/91)
In article <1991Feb16.191721.23352@nntp-server.caltech.edu> madler@owl.caltech.edu (Mark Adler) writes: >>> 1) ... UU is not in place everwhere, and it's a pain to put into place. >I know I wouldn't be able to spot a missing line in the ASC *or* UU format. [two points taken out of context] It may be worth pointing out that there exist backwards compatible versions of uu{en,de}code widely available. The Dumas version, which was designed for the ST but easily compiled on PC's, Unix boxes, and just about everything else, handles multi-part postings (not a hot issue with handheld users!) and adds a sequence check to the end of each line (this is ignored by standard uudecode). It also incorporates a method for handling munged characters, such as the backquote/space ambiguity. One version of the Dumas program is available by anonymous ftp from cs.dal.ca as pub/bio/uu.tar.Z if anyone is interested. -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biome!silvert BITNET=silvert%biome%dalcs@dalac InterNet=silvert%biome@cs.dal.ca
TDSTRONG%MTUS5.cts.mtu.edu@CUNYVM.CUNY.EDU (Tim Strong) (05/13/91)
> >In article <1991Feb16.191721.23352@nntp-server.caltech.edu> > madler@owl.caltech.edu (Mark Adler) writes: >>>> 1) ... UU is not in place everwhere, and it's a pain to put into place. >>I know I wouldn't be able to spot a missing line in the ASC *or* UU format. > >[two points taken out of context] > >It may be worth pointing out that there exist backwards compatible >versions of uu{en,de}code widely available. The Dumas version, which >was designed for the ST but easily compiled on PC's, Unix boxes, and >just about everything else, handles multi-part postings (not a hot issue >with handheld users!) and adds a sequence check to the end of each line >(this is ignored by standard uudecode). It also incorporates a method >for handling munged characters, such as the backquote/space ambiguity. > >One version of the Dumas program is available by anonymous ftp from >cs.dal.ca as pub/bio/uu.tar.Z if anyone is interested. >-- >William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography >P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 >UUCP=..!{uunet|watmath}!dalcs!biome!silvert >BITNET=silvert%biome%dalcs@dalac InterNet=silvert%biome@cs.dal.ca I'm not going to argue that uuencode doesn't have its pruposes. I happen to use it all the time. However it seems certain versions extend the decompressed files to intergral block size (or something like that somebody said once) and that sometimes causes some binary files to be corrupted. An example is MLDL by Jan Brittenson. Some people have reported that the uuencode version when downloaded to their machine gives an invalid card data and then clears the port. This happened to me as well but the ASC version works fine in my machine. ====================================================================== ___ I__) _ _I _ _ Tim Strong <TDSTRONG@MTUS5.cts.mtu.edu> I \ (_I (_I (_I I Michigan Tech. Houghton, Michigan, U.S.A. ======================================================================
IMS103@psuvm.psu.edu (Ian Matthew Smith) (05/14/91)
OPTIONS: NOACK LOG SHORT NOTEBOOK ALL XOPTIONS: REPLYING to NETNEWS article As to UUEncode, I havn't found any files that will decode correctly from this newsgroup. They all say 'Short file' and will not D/L correctly into the HP. Somone posted they were working on a UUencode for the HP that didn't use a buffer and therefore only used 1/3 the space of ASC. How hard would it be to re-write ASC to do the same? Ahhh, nevermind. Just hope some HP owener wins $50 million and buys us all a pair of 128K ram cards. :-) :-) :-) - Ian Smith <<ims103@psuvm.psu.edu>>