bobmon@iuvax.UUCP (Che' Flamingo) (06/06/87)
I just did a preliminary comparison of some versions of PKARC and ARC on some text files I was shuffling away. The following numbers are merely suggestive, not definitive, but... Original: three text files, 165366 + 143872 + 19430 bytes = 328668 total ARChiving program Execution time Size Compression ----------------- -------------- ------ ----------- pkarc v1.2 0:59.28 137700 59% pkarc v3.5, with squashing 0:39.32 130305 61% pkarc v3.5, without squashing 0:43.06 138283 58% arc v5.12 6:04.53 138290 58% arc v5.20 5:04.35 141646 57% All the files were crunched except under pkarc v3.5 w/squashing, which squashed them all. The time comparisons are the big issue for me.
jvc@mirror.UUCP (06/11/87)
News Flash:
Incompatibility is not as big an issue anymore (as long as the
unpacking is being done on a MS/PC-DOS machine). With PKARC 3.5
it is possible to create your own self-unpacking archives. Now you
can distribute pkarced files to ANYONE with a MS/PC-DOS machine and
they can unpack it WITHOUT using any software.
There are instructions in the pkarc manual but the procedure is as
follows:
1) Pkarc the files you wish to archive. You CAN use squashing.
2) Copy the archive file to the end of the file PKSFX.PGM (this file
(is created by one of the programs that comes with PKARC 3.5) as
follows:
copy/b pksfx.pgm + archive.arc file.exe
where archive.arc is the full archive name created in step one,
file.exe is the name of the file you want to be self extracting and
it must have an extention of .EXE.
All the options for pkxarc except -v will work with the self
extracting archive. For example:
file -l
where file is the self extracting archive, will display the
software license,
file -g<password>
will extract garbled file w/password.
The argument that posting SOURCE in an archived format is unfair to
non-MS/PC-DOS users still holds. [I don't really think its hurts
anyone that reads this group but I want to avoid flames]
NOTE: ADDING PKSFX.PGM TO THE BEGINING OF THE FILE DOES ADD 9758
BYTES TO THE FILE, BUT, SINCE THE ARCHIVE FILE IS GENERALLY
>64K THE OVERHEAD IS INSIGNIFICANT (and of course, the recipiant
doesn't have to know what software you used to pack it and
doesn't have to have software to unpacked which makes the overhead
even more insignificant). PLEASE SEND ANY FLAMES ABOUT THIS
OVERHEAD TO /DEV/NULL.
-------------------------------------------------------------------------
Jim Champeaux jvc@mirror.TMC.COM
{mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!jvc
Mirror Systems, 2067 Massachusetts Avenue, Cambridge, MA 02140
Telephone: (617) 661-0777paul@cgh.UUCP (06/15/87)
I have noticed the existence of more Self-Extracting-ARChives, and I
must report that I think this an unfortunate trend. I say this for
several reasons:
1. With an ARC file, you can use "arc v" to get a directory list
showing filenames and sizes. with SelfExtractingARC.EXE, you
cannot.
2. With an ARC file, you can extract only a portion of the files.
On a floppy based system, this might be important. With a
a self-extracting file you cannot do this.
3. It give me a creepy feeling to download an EXE file from some
remote system and then just go ahead and run it without checking
it out, and it should give everyone else a creepy feeling, too.
An error in transmission could cause the extraction part to work
improperly, possibly causing corruption of one's hard disk. Or,
a trouble-maker could put a Trojan in the extractor part. Not good.
4. Archive programs are handy things. Not only can you take ARCs
apart with them, you can put things into ARC files, too. But you
cannot put things into a self extracting file. Since you need
ARC or ARCA/E or ZOO (yeah!) anyway, you don't need the self
extracting file.
On GEnie, we have banned self-extracting files from our libraries except
for the case of boot-strap distributions of the ARCHIVE utility programs
themselves. (Also of interest: we do not allow PKARC files with SQUASHED
members in them, as these files cannot be unARC'd with ARC.EXE or ARCE.COM.
If it *says* FOO.ARC, it should *be* an ARC).
Paul Homchick, Sysop GEnie IBM RoundTablejvc@mirror.UUCP (06/16/87)
/* Written 1:19 am Jun 15, 1987 by paul@cgh.UUCP in comp.sys.ibm.pc */ >... > > 1. With an ARC file, you can use "arc v" to get a directory list > showing filenames and sizes. with SelfExtractingARC.EXE, you > cannot. > > 2. With an ARC file, you can extract only a portion of the files. > On a floppy based system, this might be important. With a > a self-extracting file you cannot do this. > Not quite. With the self extracting archives created by PKARC, #1 is true. However, if you know what's in the archive, you can selectively extract files. The format is : selfextractingarchive [options] [d:path\] [file...] and the file name can contain wildcards (works just like pkxarc except for the /v option). Although this isn't as useful since you can't get a listing of the archive, it can be done. I don't know what ZOO can or can't do as I have been unable to find a copy. > 4. Archive programs are handy things. Not only can you take ARCs > apart with them, you can put things into ARC files, too. But you > cannot put things into a self extracting file. Since you need > ARC or ARCA/E or ZOO (yeah!) anyway, you don't need the self > extracting file. The self extracting files were not meant to be replacements for the archive programs. They are meant to be a method of giving someone a archive without having to also give them the program that was used to create the archive. This attempts to solve the "incompatibility" problem between the different archive programs. >... > [talked about how files archived with PKARC's squashing method are not allowed in his site's library because SEAwares ARC program can't unarc them.] Self extracting archives will help make it so that it doesn't matter how the files where archived because anyone can unarc them without software. The inability to get a listing (/v option) was a dumb thing to leave out of the selfextractingarchive software but it can be worked around. How about putting a file in the archive call LISTING which would list the files in the archive. Using this method, you could give COMPLETE description of the files in the archive. As long as this file name is consistant, anyone at your site who wants to selectively extract files can first extract LISTING to find the names of the files he/she wishes to extract. jvc@mirror.TMC.COM Note: I'm not saying that PKARC's squashing is or is not a better method than the other "standard" methods so any flames about it should be sent to /dev/null.
w8sdz@brl-smoke.UUCP (06/21/87)
Self-extracting ARC's have some disadvantages. First, because the file
extension is .EXE, it's not apparent to others that this is really an
ARC file unless you include a note saying so. Second, what about those
who wish to extract/view/print the member files on a mainframe that has
an implimentation of ARC512? Third, the self-extracting part can be
dangerous to your file system if it gets corrupted because of an error
in transmission. Also, it might be easy for someone to put a Trojan
Horse in the self-extracting code.
I'd rather have an ARC for these reasons. I have no objection to people
posting source in uuencoded ARC format - in fact I prefer it because it
gives a built-in error checking mechanism that has been missing from
Usenet for far too many years.
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZpaul@cgh.UUCP (Paul Homchick) (06/22/87)
/* From <206900040@mirror> in comp.sys.ibm.pc by jvc@mirror.UUCP */ > >The self extracting files were not meant to be replacements for the >archive programs. They are meant to be a method of giving someone a >archive without having to also give them the program that was used to >create the archive. This attempts to solve the "incompatibility" >problem between the different archive programs. > >Self extracting archives will help make it so that it doesn't matter >how the files where archived because anyone can unarc them without software. The "incompatibility" problem is entirely due to the existence of an archiving program that creates files with ".ARC" extensions which existing and mainstream ARC programs cannot deal with. This is akin to someone distributing ".EXE" files that DOS cannot load and run. The "solution" to this problem is now offered as the self-extracting archive file which creates a whole new set of problems. If most people would resolve to stop using PKARC, or if its author could be persuaded to adopt another filetype extention when "squashed" format files are created, then the first problem would not exist, and this unfortunate "solution" would not be necessary. The phrase: "tangled web" comes to mind. -- Paul Homchick Chimitt Gilman Homchick, Inc.; One Radnor Station, Suite 300; Radnor, PA 19087 {seismo!bpa | ihnp4!cbmvax} !vu-vlsi!cgh!paul
jvc@mirror.UUCP (06/23/87)
The current version of pkarc (3.5) allows you to create a config file (pkarc.cfg) and place a variable in the dos environment telling pkarc where to find it. In this file you can specify SQUASH=ENABLE or SQUASH=DISABLE. You can also specify which data stamping method should be used. You can override these default settings with switches on the command line. jvc@mirror.TMC.COM
NU013809@NDSUVM1.BITNET (Greg Wettstein) (07/01/87)
I have been looking around for an implementation of the ARC512 program
for an IBM mainframe for some time now. In this posting I noticed that
the author alluded to the fact that some people have ARC512 running on
a mainframe.
I would appreciate it if someone could advise me of the availability of
such a program or where I might obtain a copy of it. Our hardware/software
setup is an IBM 3081-D32 running VM/SP4. Replies may be posted to net news
or sent by EMAIL to my BITNET address. Any information will be appreciated.
As always,
G.W. Wettstein
NU013809@NDSUVM1