larry@focsys.UUCP (Larry Williamson ) (02/27/88)
Since it seems inevitable that many good tools are being sent
around in pkxarc format, and many of us would like to be able
to use some of these tools, maybe pkxarc should be posted so
that we may use it.
Either that or EVERYONE must stop using whatever feature that
pkxarc has that makes it's output incompatible with the older
arc standard.
So if the proper authority would be so kind, please post an
un-arc'd version of pkxarc. Let us all have access to this
'other' arc.
I know that it is available by anon ftp from somewhere but I
don't have ftp available at this site. A direct email to me
would be nice, but I'm sure many others would also like to
have access to this tool.
Note that it would be foolish to post it arc'd as there would
be no way to un-arc it. Even if it was arc'd in the 'standard'
version, not everyone has even that I'm sure.
--
---
Larry Williamson Focus Automation Systems
UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4
+1 519 746 4918akk2@ur-tut.UUCP (Atul Kacker) (02/29/88)
I will be posting PKARC to comp.sys.binaries.ibm.pc on the
5th of March. Why 5th March, you say ? Because that way we
will perhaps avoid multiple postings to the net. I will
not post it here, its binaries or nothing folks. If there
are any reasons why I shouldn't post it at all, please let
me know before the 5th of March.
--
-------------------------------------------------------------------------------
Atul Kacker | Internet: akk2@tut.cc.rochester.edu
| UUCP: {ames,cmcl2,decvax,rutgers}!rochester!ur-tut!akk2
-------------------------------------------------------------------------------dave@sun.soe.clarkson.edu (Dave Goldblatt) (02/29/88)
From article <1053@ur-tut.UUCP>, by akk2@ur-tut.UUCP (Atul Kacker): > I will be posting PKARC to comp.sys.binaries.ibm.pc on the > 5th of March. Just make sure you are posting PKX35A35.EXE, which is the complete package, including PKARC, PKXARC, MAKESFX, and the associated documentation. -dg-
merlin@hqda-ai.UUCP (David S. Hayes) (03/01/88)
In article <1053@ur-tut.UUCP>, akk2@ur-tut.UUCP (Atul Kacker) writes: > I will not post it here, its binaries or nothing folks. If there > are any reasons why I shouldn't post it at all, please let > me know before the 5th of March. You should not post the binaries again. The binary (for IBM PC) of PKARC is already well-distributed. This is fine, but what is really needed is the C code, so we can try to run this on our Unix machines. As it stands now, you must have both a PC and a Unix system. Further, after the files are received on the Unix machine via Usenet, they must be transferred to the PC for de-ARCing. It would be better if we could unpack the archives directly on the Unix machines, so we can look at the documentation and such before investing effort in moving all the code to some other machine. -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpa
farren@gethen.UUCP (Michael J. Farren) (03/01/88)
In article <695@hqda-ai.UUCP> merlin@hqda-ai.UUCP (David S. Hayes) writes: > > It would be better if we could unpack the archives directly >on the Unix machines, so we can look at the documentation and such >before investing effort in moving all the code to some other >machine. Sources for a Unix ARC capable of unpacking PKXARC files were posted to alt.sources some time ago. And sorry, I don't have them here, so can't mail 'em to anyone. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
akk2@ur-tut.UUCP (Atul Kacker) (03/03/88)
In article <695@hqda-ai.UUCP> merlin@hqda-ai.UUCP (David S. Hayes) writes: >In article <1053@ur-tut.UUCP>, akk2@ur-tut.UUCP (Atul Kacker) writes: >> I will not post it here, its binaries or nothing folks. If there >> are any reasons why I shouldn't post it at all, please let >> me know before the 5th of March. > > You should not post the binaries again. The binary (for IBM >PC) of PKARC is already well-distributed. This is fine, but what >is really needed is the C code, so we can try to run this on our >Unix machines. Well since I posted my orginal message, the binaries for PKARC have been posted to the binaries newsgroup. I will thus not be posting them anymore. I don't know about you guys out there, but I use a Unix version of ARC that I had saved off the net last year. This version has *no* problems dealing with the *squashed* format of PKARC. It does not however create squashed ARC files. The person who had posted it had mentioned that he was working on it. Unfortunately, I have deleted the sources in a recent disk crunch and all I have are the binaries for my Unix machine. I am trying to see if a backup exists somewhere. If I do find them, I will post them to the appropriate newsgroup (Which one ? That still remains to be seen). If anyone else out there has the Unix sources for ARC, which will handle squashed PKARC archives, please come forward now! I don't want to have duplicate postings to the net. -- ------------------------------------------------------------------------------- Atul Kacker | Internet: akk2@tut.cc.rochester.edu | UUCP: {ames,cmcl2,decvax,rutgers}!rochester!ur-tut!akk2 -------------------------------------------------------------------------------
rmtodd@uokmax.UUCP (Richard Michael Todd) (03/05/88)
In article <695@hqda-ai.UUCP> merlin@hqda-ai.UUCP (David S. Hayes) writes: > You should not post the binaries again. The binary (for IBM >PC) of PKARC is already well-distributed. This is fine, but what >is really needed is the C code, so we can try to run this on our >Unix machines. As it stands now, you must have both a PC and a >Unix system. Further, after the files are received on the Unix >machine via Usenet, they must be transferred to the PC for >de-ARCing. Well, as other people have mentioned, source code for an alleged PKXARC- compatible archive program for UNIX has appeared on Usenet before. As I recall, the source code contained comments saying the poster had gotten it to work on his VAX. Said program refused to do *anything* but drop core on this here Encore Multimax. (There's a lot of stuff Vaxen will let sloppy coders get away with that other machines won't...). I would have messed with it to see why it didn't work, but the ZOO source came out the next week, so I pitched my copy of the Unix PKARC into the bit bucket. BTW, I agree with you about posting the PKARC PC binaries. They're available from practically every PC-based BBS in the known cosmos. People, go look at your local BBS before you ask that this junk be shipped around the country at the expense of lots of large companies. I recall hearing that hoptoad has already dropped the binary groups due to excessive volume; do you really want to encourage the backbone sites to follow suit? > It would be better if we could unpack the archives directly >on the Unix machines, so we can look at the documentation and such >before investing effort in moving all the code to some other >machine. Agreed. But I'm not sure PKARC is the solution. Zoo is a PD program, with C source available, that does much the same thing as PKARC, with about the same compression ratio (not surprising, they both use 13-bit LZW compression), and it's available for PCs and Unix machines (and Amigas and VMS too, I believe). The Unix version compiled and ran here after a 1-line change to makefile. (When was the last time you could say that about a program from the net?). This program seems to have been written with an eye to portability. As another alternative, there's the tar&compress combination. It's got a long history of use on Unix systems, both tar and compress have PD versions available, and both have versions for MSDOS. The only problem is getting people to use one of these two formats instead of the PKARC format which is currently limited to PCs and *some* Unix machines. ___________________________________________________________________________ Richard Todd Dubious Domain: rmtodd@uokmax.ecn.uoknor.edu USSnail:820 Annie Court,Norman OK 73069 Fido:1:147/1 UUCP: {cbosgd|ihnp4}!occrsh!uokmax!rmtodd
farren@gethen.UUCP (Michael J. Farren) (03/05/88)
In article <465@sun.soe.clarkson.edu> dave@sun.soe.clarkson.edu (Dave Goldblatt) writes: > >Just make sure you are posting PKX35A35.EXE, which is the complete >package, including PKARC, PKXARC, MAKESFX, and the associated documentation. No, be sure you are posting PKX35B35.EXE, which is the absolute latest stuff, and fixes some small bugs. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
dean@violet.berkeley.edu (Dean Pentcheff) (03/07/88)
In article <731@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >No, be sure you are posting PKX35B35.EXE, which is the absolute latest >stuff, and fixes some small bugs. Quote from an earlier comp.sys.ibm.pc article: From: dave@sun.soe.clarkson.edu (Dave Goldblatt) Newsgroups: comp.sys.ibm.pc,comp.sys.zenith.z100 Subject: Beware PKARC trojan! Summary: Do not use PKX35B35.ARC Keywords: trojan PKARC PKXARC Message-ID: <493@sun.soe.clarkson.edu> Date: 4 Mar 88 17:12:09 GMT Reply-To: dave@sun.soe.clarkson.edu (Dave Goldblatt) Organization: Clarkson University, Potsdam, NY Lines: 20 Xref: agate comp.sys.ibm.pc:14951 comp.sys.zenith.z100:444 I just pulled this from my bulletin board.. TO: All FROM: John Allen SUBJECT: Beware Pkxarc Trojan All MS-DOS users beware of a trojan being uploaded to BBS's under the name of PKX35B35.ARC. Phil Katz has been contacted about this program and Phil stated that the current version is PKX35A35.ARC. The "B" VERSION IS A FAT KILLER....... BEWARE...... --- * Origin: The Black Cat's Shack - Silver Spring, MD (Opus 1:109/661) -dg- Internet: dave@sun.soe.clarkson.edu or: dave@clutx.clarkson.edu BITNET: dave@CLUTX.Bitnet uucp: {rpics, gould}!clutx!dave Matrix: Dave Goldblatt @ 1:260/360 ICBM: Why do you want to know? :-) ----------------- Dean Pentcheff (dean@violet.berkeley.edu) ----------------- "A university is a place where people pay high prices for goods which they then proceed to leave on the counter when they go out of the store." Loren Eiseley
anderson@vms3.macc.wisc.edu (Jess Anderson) (03/07/88)
In article <731@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: ]In article <465@sun.soe.clarkson.edu> dave@sun.soe.clarkson.edu (Dave Goldblatt) writes: ]>Just make sure you are posting PKX35A35.EXE, which is the complete ]>package, including PKARC, PKXARC, MAKESFX, and the associated documentation. ]No, be sure you are posting PKX35B35.EXE, which is the absolute latest ]stuff, and fixes some small bugs. NO! *Many* articles have now gone by in I forget which groups (this one, I think), warning that PKX35B35.EXE is a trojan. Before this gets out of hand, maybe someone who knows Phil Katz should get the latest word from him. ==INTERNET: anderson@vms.macc.wisc.edu====Jess Anderson======(home:)======== | UUCP: {harvard,rutgers,allegra,ucbvax} 1210 W. Dayton 2838 Stevens | | !uwvax!vms3.macc.wisc.edu!anderson Madison, WI 53706 Madison 53705 | ==BITNET: anderson@wiscmacc===============608/263-6988=======608/238-4833===
boneill@hawk.ulowell.edu (SoftXc Coordinator) (03/07/88)
In article <731@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >In article <465@sun.soe.clarkson.edu> dave@sun.soe.clarkson.edu (Dave Goldblatt) writes: >> >>Just make sure you are posting PKX35A35.EXE, which is the complete >>package, including PKARC, PKXARC, MAKESFX, and the associated documentation. > >No, be sure you are posting PKX35B35.EXE, which is the absolute latest >stuff, and fixes some small bugs. > >Michael J. Farren NO!!!!! Absolutely do NOT post PKX35B35.EXE!!!! It is a Trojan program circulating around BBS's that destroys the FAT of disks. The current official version is PKX35A35.EXE. Please, the net is paranoid enough about Trojans being posted, lets not ASK for them to be posted. Let's not have a repeat of the ARC 5.13 problem. ============================================================================ Brian O'Neill University of Lowell boneill@hawk.ulowell.edu - boneill@hawk.UUCP ...!ulowell!hawk!boneill MS-DOS Software Exchange Coordinator - E-mail for details
adonis@tahoe.unr.edu (Derrick Hamner) (03/10/88)
In article <731@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >In article <465@sun.soe.clarkson.edu> dave@sun.soe.clarkson.edu (Dave Goldblatt) writes: >> >>Just make sure you are posting PKX35A35.EXE, which is the complete >>package, including PKARC, PKXARC, MAKESFX, and the associated documentation. > >No, be sure you are posting PKX35B35.EXE, which is the absolute latest >stuff, and fixes some small bugs. I have it on pretty good authority that PKX35B35.EXE is NOT from Phil Katz or PKWARE. I don't remember if it was a trojan or a virus or anything like that, but I do remember that PKX35A35.EXE is the LATEST official version. Maybe someone could contact PKWARE and absolutely verify this. Until it then, be careful. -- A computer program does what you tell it to do, | Derrick Hamner not what you want it to do. | adonis@tahoe.unr.edu
john@viper.Lynx.MN.Org (John Stanley) (03/12/88)
In article <731@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >In article <465@sun.soe.clarkson.edu> >dave@sun.soe.clarkson.edu (Dave Goldblatt) writes: >> >>Just make sure you are posting PKX35A35.EXE, which is the complete >>package, including PKARC, PKXARC, MAKESFX, and the associated documentation. > >No, be sure you are posting PKX35B35.EXE, which is the absolute latest >stuff, and fixes some small bugs. > While we're on the subject, does anyone have information about the additional compression format(s) included in PKARC? I'm writing a general purpose arc extractor for my home machine (which is not an IBM or clone). I've got the compression methods for ARC 2.15, but the added PKARC method(s) are still an unknown. If anyone can provide documents, source, or handwaving that explains the added format(s), please contact me. --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john
w8sdz@brl-smoke.ARPA (Keith B. Petersen ) (03/12/88)
The following file, ARC-FILE.INF, is forwarded from my BBS.
--cut-here--
ARC-FILE.INF contains information extracted from UNARC.INF by
Robert A. Freed (September, 1986) and from SQSHINFO.DOC by Phil Katz,
(December, 1986).
Note: In the following discussion, UNARC refers to Robert A. Freed's
CP/M-80 program for extracting files from MSDOS ARCs. The definitions
of the ARC file format are based on MSDOS ARC and PKARC/PKXARC
programs.
ARCHIVE FILE FORMAT
-------------------
Component files are stored sequentially within an archive. Each
entry is preceded by a 29-byte header, which contains the directory
information. There is no wasted space between entries. (This is in
contrast to the centralized directory used by Novosielski libraries.
Although random access to subfiles within an archive can be noticeably
slower than with libraries, archives do have the advantage of not
requiring pre-allocation of directory space.)
Archive entries are normally maintained in sorted name order. The
general format of the 29-byte archive header is as follows:
archive mark, header version, file header, file data...
Byte 1: 1A Hex.
This marks the start of an archive header. If this byte is not
found when expected, UNARC will scan forward in the file (up to
64K bytes) in an attempt to find it (followed by a valid
compression version). If a valid header is found in this
manner, a warning message is issued and archive file processing
continues. Otherwise, the file is assumed to be an invalid
archive and processing is aborted. (This is compatible with
MS-DOS ARC version 5.12). Note that a special exception is made
at the beginning of an archive file, to accommodate
"self-unpacking" archives (see below).
Byte 2: Compression version, as follows:
0 = End of file marker (remaining bytes not present).
1 = Stored (obsolete).
2 = Stored - No compression.
3 = Packed - (non-repeat packing).
4 = Squeezed (Huffman squeezing, after packing)
5 = Crunched (Obsolete - 12-bit static LZW without non-repeat pack).
6 = Crunched (Obsolete - 12-bit static LZW with non-repeat packing).
7 = Crunched (Obsolete - after packing, using faster hash algorithm).
8 = Crunched (using dynamic LZW variations, after packing).
(The initial LZW code size is 9-bits with a
maximum code size of 12-bits. The possibility of
adaptive resets are implemented in this mode.)
9 = Squashed (The file was compressed with Dynamic LZW
compression without non-repeat packing. The
initial LZW code size is 9-bits with a maximum
maximum code size of 13-bits. The possibility of
adaptive resets are implemented in this mode.)
Bytes 3-15: ASCII file name, nul-terminated.
(All of the following numeric values are stored low-byte first.)
Bytes 16-19: File size of compressed file, in bytes.
(The number of bytes in the file data area following the
header.)
Bytes 20-21: File date, in 16-bit MS-DOS format:
Bits 15:9 = year - 1980
Bits 8:5 = month of year
Bits 4:0 = day of month
(All zero means no date.)
Bytes 22-23: File time, in 16-bit MS-DOS format:
Bits 15:11 = hour (24-hour clock)
Bits 10:5 = minute
Bits 4:0 = second/2 (not displayed by UNARC)
Bytes 24-25: Cyclic redundancy check (CRC) value (see below).
Bytes 26-29: Original (uncompressed) file length in bytes.
(This field is not present for version 1 entries, byte 2 = 1.
I.e., in this case the header is only 25 bytes long. Because
version 1 files are uncompressed, the value normally found in
this field may be obtained from bytes 16-19.)
SELF-UNPACKING ARCHIVES
-----------------------
A "self-unpacking" archive is one which can be renamed to a .COM
file and executed as a program. An example of such a file is the MS-DOS
program ARC512.COM, which is a standard archive file preceded by a
three-byte jump instruction. The first entry in this file is a simple
"bootstrap" program in uncompressed form, which loads the subfile
ARC.EXE (also uncompressed) into memory and passes control to it. In
anticipation of a similar scheme for future distribution of UNARC, the
program permits up to three bytes to precede the first header in an
archive file (with no error message).
CRC COMPUTATION
---------------
Archive files use a 16-bit cyclic redundancy check (CRC) for error
control. The particular CRC polynomial used is x^16 + x^15 + x^2 + 1,
which is commonly known as "CRC-16" and is used in many data
transmission protocols (e.g. DEC DDCMP and IBM BSC), as well as by most
floppy disk controllers. Note that this differs from the CCITT
polynomial (x^16 + x^12 + x^5 + 1), which is used by the XMODEM-CRC
protocol and the public domain CHEK program (although these do not
adhere strictly to the CCITT standard). The MS-DOS ARC program does
perform a mathematically sound and accurate CRC calculation. (We
mention this because it contrasts with some unfortunately popular public
domain programs we have witnessed, which from time immemorial have based
their calculation on an obscure magazine article which contained a
typographical error!)
Additional note (while we are on the subject of CRC's): The
validity of using a 16-bit CRC for checking an entire file is somewhat
questionable. Many people quote the statistics related to these
functions (e.g. "all two-bit errors, all single burst errors of 16 or
fewer bits, 99.997% of all single 17-bit burst errors, etc."), without
realizing that these claims are valid only if the total number of bits
checked is less than 32767 (which is why they are used in small-packet
data transmission protocols). I.e., for file sizes in excess of about
4K bytes, a 16-bit CRC is not really as good as what is often claimed.
This is not to say that it is bad, but there are more reliable methods
available (e.g. the 32-bit AUTODIN-II polynomial). (End of lecture!)
Notes:
For type 1 stored files, the file header is only 23 bytes in size,
with the length field not present. In this case, the file length is the
same as the size field since the file is stored without compression.
The first byte of the data area following the header is used to
indicate the maximum code size, however only a value of 12 (decimal) is
currently used or accepted by existing ARC programs.
The algorithm used "squashed" compression is identical to type 8
crunched files with the exception that the maximum code size is 13 bits
- i.e. an 8K entry LZW table. However, unlike type 8 files, the first
byte following the file header is actual data, no maximum code size is
stored.
References
----------
Source code for ARC 5.0 by Tom Henderson of Software Enhancement
Associates, usually found in a file called ARC50SRC.ARC.
Source code for general Ziv-Lempel-Welch routines by Kent Williams,
found in a file LZX.ARC. Kent Williams work is also referenced in the
SEA documentation.
Source code and documentation from the Unix COMPRESS utilities, where
most of the LZW algorithms used by SEA originated, found in a file
called COMPRESS.ARC.
Ziv, J. and Lempel, A. Compression of individual sequences via
variable-rate coding. IEEE Trans. Inform. Theory IT-24, 5 (Sept. 1978),
530-536.
The IBM DOS Technical Reference Manual, number 6024125.
=end=
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZfarren@gethen.UUCP (Michael J. Farren) (03/14/88)
In article <5297@swan.ulowell.edu> boneill@hawk.ulowell.edu (SoftXc Coordinator) writes: >In article <731@gethen.UUCP> farren@gethen.UUCP I wrote: >>No, be sure you are posting PKX35B35.EXE, which is the absolute latest >>stuff, and fixes some small bugs. > >NO!!!!! Absolutely do NOT post PKX35B35.EXE!!!! It is a Trojan program >circulating around BBS's that destroys the FAT of disks. A word of explanation: when I made the above posting, I was unaware of the existence of a Trojan PKARC. The version that I've been using, PKX35B35, was downloaded from a local BBS system which maintains very tight control over it's downloads. I've NEVER downloaded a Trojan from there, and likely never will. PKX35B35.EXE, *as I received it*, works fine. That does NOT mean that there are no Trojan versions out there, and a call to Phil Katz's BBS system confirmed that there is NO PKX35B35 authorized by him, so I would have to agree - do not use PKX35B35.EXE, as you may not get a version as benign as the one I got. I've removed PKX35B35.EXE from my BBS as a precaution. My apologies for the confusion - I did NOT post the above with malicious intent, simply a bit of ignorance of the global situation. Thanks to those who pointed out my error; we need to combat this crap anywhere we find it. No thanks, though, to those who sent hate mail. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
fastrax@dasys1.UUCP (Jonathan Herbert) (03/23/88)
> >No, be sure you are posting PKX35B35.EXE, which is the absolute latest > >stuff, and fixes some small bugs. > I have it on pretty good authority that PKX35B35.EXE is NOT from > Phil Katz or PKWARE. I don't remember if it was a trojan or a virus or > anything like that, but I do remember that PKX35A35.EXE is the LATEST > official version. Maybe someone could contact PKWARE and absolutely verify > this. Until it then, be careful. Let me throw my two cents in here. For what it's worth, the rumors that I have heard are that PKX35B35.EXE is some kind of yucky nasty. Be very ware. Stick to the A version unitl the dust settles. -- Jonathan Herbert Big Electric Cat Public UNIX When the going gets strange, ..!cmcl2!phri!dasys1!fastrax the weird turn pro.
tneff@atpal.UUCP (Tom Neff) (03/25/88)
Newsgroups: comp.sys.ibm.pc,comp.sources.wanted Subject: Re: pkxarc wanted Summary: A simple solution References: <1053@ur-tut.UUCP> <465@sun.soe.clarkson.edu> <731@gethen.UUCP> <1057@tahoe.unr.edu> <3511@dasys1.UUCP> Reply-To: tneff@atpal.UUCP (Tom Neff) Organization: Rational Technologies, Inc. Keywords: pkxarc katz arce buerg In article <3511@dasys1.UUCP> fastrax@dasys1.UUCP (Jonathan Herbert) writes: >> >No, be sure you are posting PKX35B35.EXE, which is the absolute latest >> >stuff, and fixes some small bugs. >> I have it on pretty good authority that PKX35B35.EXE is NOT from >> Phil Katz or PKWARE. I don't remember if it was a trojan or a virus or >> anything like that, but I do remember that PKX35A35.EXE is the LATEST >> official version. Maybe someone could contact PKWARE and absolutely verify >> this. Until it then, be careful. > >Let me throw my two cents in here. For what it's worth, the rumors that I have >heard are that PKX35B35.EXE is some kind of yucky nasty. Be very ware. Stick >to the A version unitl the dust settles. Guys -- if you use Vern Buerg's superb ARCE.COM, which predates all the Katz stuff, is smaller, nimbler, and more reliable, you will not have this problem. The current version (3.1b) even supports Katz's incompatible, reprehensible, rogue "squashing" compression technique. -- Tom Neff