pete@i-core.UUCP (Pete Ashdown) (01/11/90)
Just got PKAZip 1.0 today. This is the full release of the Amiga PKZip and it looks rather nice. It supports compression as well as decompression (unlike the prereleases) and it does do all the techniques supported by MeSsy-DOS PKZip 1.02. What is really nice about it is the fact that the whole thing is intuitionized, which IMHO makes it a better program than all the other compressors combined. Its interface looks GOOD too! No standard slop windows here. Everything has a NeXTish look to it. It also has online help and a pallette control. I think it blows the MS-DOS version away. Only a couple of complaints. I wish I could see SOMETHING happening when it is compressing and decompressing. A bar going across a requester would be swell (ala StuffIt). Otherwise it just shows the word "Compressing" and then changes it to "Compressed" when it is done. Second, the Imploding really drags. It seems much faster on my AT (10 mhz). However, I'm sure they'll optimize this sooner or later. What's important is that it works and it is as good if not better than LHArc. I hope we can toss ARC and LHARC now (yeah sure....).
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/13/90)
In <258@estinc.UUCP>, fnf@estinc.UUCP (Fred Fish) writes: >In article <1990Jan11.062433.27699@i-core.UUCP> pete@i-core.UUCP (Pete Ashdown) writes: >>Just got PKAZip 1.0 today. This is the full release of the Amiga PKZip and >>it looks rather nice. It supports compression as well as decompression >>(unlike the prereleases) and it does do all the techniques supported by >>MeSsy-DOS PKZip 1.02. > >Does it still have the distribution restriction of "NO FEE IS CHARGED FOR >USE, COPYING, OR DISTRIBUTION" in the zip.license file? If so, I guess >it won't show up in any PD libraries. This clause should also cause all >pay-for-time online services to reject it from inclusion in their libraries, >though I doubt that will happen. Right. Given that wording, I doubt it will be excluded from 'pay-for-time' online service libraries. You see, most pay-for-time online services are exactly that; the payment is for time spent on the system, and not for any particular part of that service's offerings, be they public messages, email, real time conferencing, or data libraries. It's a subtle distinction, and one that has caused much argument. In fact, for a while, PLink was charging an extra fee for downloading files, based upon the number of bytes transferred. They decided to drop the extra fee, for reasons unknown to me, but while they were charging the fee, it was clear (at least to me), that they were charging for distribution of particular data files, regardless of restrctions to the contrary in those files. My stand on the issue is that if an author wants to prevent his work from appearing on a 'pay-for-time' network, he'd better make it clear in the distribution restrictions. The author of Zoo, at one time, clearly spelled out restrictions that indirectly prohibited distribution on Compuserve, and that restriction was honoured. When he was convinced to change those restrictions, Zoo was posted, and .ZOO files were allowed to appear in the data libraries. >>I hope we can toss ARC and LHARC now (yeah sure....). > >Not till it's as freely available and distributable as zoo, at least in >binary form... And not until it has the ability to be used from scripts. I certainly won't use it if I have to manually ZIP stuff. -larry -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/13/90)
In <1990Jan11.062433.27699@i-core.UUCP>, pete@i-core.UUCP (Pete Ashdown) writes: >Just got PKAZip 1.0 today. ... > >What is really nice about it is the fact that the whole thing is >intuitionized, which IMHO makes it a better program than all the other >compressors combined. The fact that it cannot be run without manual intervention makes it, IMHO, the single worst solution to archiving that I can think of. Given the choice between a slow, poorly compressing archiver that can be run from a script without manual intervention, and one that requires manual intervention, I would opt for the former every time, and save myself a lot of time and aggravation, considering the amount of archiving/unarchiving I do. Unfortunately, there are so many folks who will jump on PKAZip as their archiver of choice, I will be forced to use at least the 'unZip only' version, which can be run from a script. I will be using it to convert any ZIPped files to something more useful. -larry -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
kudla@pawl.rpi.edu (Robert J. Kudla) (01/13/90)
In <1990Jan11.062433.27699@i-core.UUCP> pete@i-core.UUCP (Pete Ashdown) writes:
-> What is really nice about it is the fact that the whole thing is
-> intuitionized, which IMHO makes it a better program than all the other
-> compressors combined. Its interface looks GOOD too! No standard slop
-> windows here. Everything has a NeXTish look to it. It also has online help
-> and a pallette control. I think it blows the MS-DOS version away.
Anything would blow an MS-Dross version away :)
Seriously though, I think PKZip Amiga sucks. It's 80k, has no command
line usage, opens up a custom screen with custom resolution and custom
colors, is quite slow, crashes almost invariably on large files,
doesn't multitask well, and is getting heavy attention from the novice
users on the local BBSes (they want everyone to use it because it's
"so easy, how could you not like it?").
It pains me to say this, but I'd rather use Arc.
-> I hope we can toss ARC and LHARC now (yeah sure....).
I tossed arc long ago and now only keep pkax around. I avoid LHARC if
possible already. My archiver of choice till something faster with
decent compression and a simple interface comes out is Zoo. Works on
my Amiga, works on Unix. Fine with me....
--
Robert Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonfnf@estinc.UUCP (Fred Fish) (01/13/90)
In article <1990Jan11.062433.27699@i-core.UUCP> pete@i-core.UUCP (Pete Ashdown) writes: >Just got PKAZip 1.0 today. This is the full release of the Amiga PKZip and >it looks rather nice. It supports compression as well as decompression >(unlike the prereleases) and it does do all the techniques supported by >MeSsy-DOS PKZip 1.02. Does it still have the distribution restriction of "NO FEE IS CHARGED FOR USE, COPYING, OR DISTRIBUTION" in the zip.license file? If so, I guess it won't show up in any PD libraries. This clause should also cause all pay-for-time online services to reject it from inclusion in their libraries, though I doubt that will happen. >I hope we can toss ARC and LHARC now (yeah sure....). Not till it's as freely available and distributable as zoo, at least in binary form... -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf
billsey@agora.UUCP (Bill Seymour) (01/14/90)
In article <258@estinc.UUCP: fnf@estinc.UUCP (Fred Fish) writes:
:Does it still have the distribution restriction of "NO FEE IS CHARGED FOR
:USE, COPYING, OR DISTRIBUTION" in the zip.license file? If so, I guess
:it won't show up in any PD libraries. This clause should also cause all
:pay-for-time online services to reject it from inclusion in their libraries,
:though I doubt that will happen.
Yup. Those exact same words are still there... I guess this means
you won't be putting it on one of your PD disks? :-)
:-Fred
:
:--
:# Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA
:# 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf
--
-Bill Seymour ...tektronix!reed!percival!agora!billsey
=============================================================================
Bejed, Inc. NES, Inc. Northwest Amiga Group At Home Sometimes
(503) 281-8153 (503) 246-9311 (503) 656-7393 BBS (503) 640-0842bdb@becker.UUCP (Bruce Becker) (01/14/90)
In article <1990Jan11.062433.27699@i-core.UUCP> pete@i-core.UUCP (Pete Ashdown) writes: |Just got PKAZip 1.0 today. This is the full release of the Amiga PKZip and |it looks rather nice. It supports compression as well as decompression |(unlike the prereleases) and it does do all the techniques supported by |MeSsy-DOS PKZip 1.02. Anyone know where I can get Zip source? I'd like to put it up on my Unix box... Thanks for any info, -- ,,,, Bruce Becker Toronto, Ont. w \$$/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/c/-e BitNet: BECKER@HUMBER.BITNET _/ >_ "Money is the root of all money" - Adam
aliu@nunki.usc.edu (Terminal Entry) (01/14/90)
In article <X#P|M*@rpi.edu> kudla@pawl.rpi.edu (Robert J. Kudla) writes: >I tossed arc long ago and now only keep pkax around. I avoid LHARC if >possible already. My archiver of choice till something faster with >decent compression and a simple interface comes out is Zoo. Works on >my Amiga, works on Unix. Fine with me.... I just ran across a Unix-compilable source for LHarc, seems to be v0.03 Beta... It compiled ok and lharc'ed some stuff, but I haven't tested it throughly... (not sure how compatible it is to the current amiga version) If anyone is interested, I could send it to a FTP site...
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/15/90)
In <2374@cpsc6a.att.com>, crs@cpsc6a.att.com (Chris (I'm a programmer, not a Doctor!!) Seaman) writes: >Could you provide an example of how you use Zoo with no manual intervention? >Frankly, in all the time I've been using the Amiga, I've never found a need >to do so. I don't spend that much of my time archiving/unarchiving files. Certainly. I use an ARexx script called 'extract'. It recognizes files of the form foo.(lzh|zoo|arc), creates a directory with the same name as the first part of the filename, moves the file into the newly created directory, and applies the appropriate command line to extract the files. I _do_ spend 'that much time archiving files. As a sysop on Compuserve's Amiga forums, I do a large volume of downloading, unarchiving, and checking files uploaded by members. The ARexx script saves me a LOT of time and typing (and in the case of PKAZip, a lot of mousing). >Besides, it seems that, in order to use an archiver that requires 'no' manual >intervention, one would still need to 'intervene' to build the script: >At least the use of a text editor, and some form of command line >syntax, which might include determining the working directory and/or tree >structure to be archived. Not at all. With an already written, single Arexx program, I can read in the contents of a directory, parse the names I find, (and even change the actual name on certain files where I have made a common mistake of naming it with .lhz instead of .lzh), create the directories, move the files, and extract them. All this with only one command line to type. >Interesting. I have just begun converting my Zoo'ed files to PKAZip, since >I find it more useful. To each his own, I guess. I find it admirable that the program supports the novice and mouse/icon oriented users, but I do think it misses the mark in this one important way. -larry -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
) Seaman) (01/16/90)
kudla@pawl.rpi.edu (Robert J. Kudla) writes: < (Pete Ashdown) writes: < -> What is really nice about it is the fact that the whole thing is < -> intuitionized, which IMHO makes it a better program than all the other < -> compressors combined. Its interface looks GOOD too! No standard slop < -> windows here. Everything has a NeXTish look to it. It also has online help < -> and a pallette control. I think it blows the MS-DOS version away. < < Seriously though, I think PKZip Amiga sucks. It's 80k, has no command < line usage, opens up a custom screen with custom resolution and custom < colors, is quite slow, crashes almost invariably on large files, < doesn't multitask well, and is getting heavy attention from the novice < users on the local BBSes (they want everyone to use it because it's < "so easy, how could you not like it?"). It hase been working OK for me. The custom screen is not a major problem, as I don't leave the program running all the time. It is slow in implode mode, though still faster than LHArc (with comparable compression), but it is quite fast (faster than Zoo) in Shrink mode, but still gives compression as good as Zoo. It SHOULD be getting a lot of novice attention, since that was the main reason for providing an intuition interface. My brother couldn't remember the Zoo syntax to save his life, but I guarantee he will know how to use PKAZip. I admit the lack of CLI support is a problem, but it should appear in the next version. There are a lot of Amiga users out there who don't know (or want to know) about the CLI, and I think it's about time a good archiver was made available to them. < It pains me to say this, but I'd rather use Arc. I'd rather not archive than have to use Arc. :-) < I tossed arc long ago and now only keep pkax around. I avoid LHARC if < possible already. My archiver of choice till something faster with < decent compression and a simple interface comes out is Zoo. Works on < my Amiga, works on Unix. Fine with me.... < -- < Robert Jude Kudla <kudla@pawl.rpi.edu> PKAZip has a simple interface (what could be simpler than Intuition?), decent compression (at least as good as Zoo in shrink mode), and is 30-40% faster than Zoo in shrink mode. What more could you want? :-) -- Chris (Insert phrase here) Seaman | /|__|\__/|__|\ crs@cpsc6a.att.com <or> | | | Where does he get ...!att!cpsc6a!crs | | /\/\ /\/\ | those Wonderful toys? The Home of the Killer Smiley | \| \/ |/
) Seaman) (01/16/90)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: < pete@i-core.UUCP (Pete Ashdown) writes: < >What is really nice about it is the fact that the whole thing is < >intuitionized, which IMHO makes it a better program than all the other < >compressors combined. < < The fact that it cannot be run without manual intervention makes it, IMHO, the < single worst solution to archiving that I can think of. Given the choice < between a slow, poorly compressing archiver that can be run from a script < without manual intervention, and one that requires manual intervention, I would < opt for the former every time, and save myself a lot of time and aggravation, < considering the amount of archiving/unarchiving I do. Could you provide an example of how you use Zoo with no manual intervention? Frankly, in all the time I've been using the Amiga, I've never found a need to do so. I don't spend that much of my time archiving/unarchiving files. Besides, it seems that, in order to use an archiver that requires 'no' manual intervention, one would still need to 'intervene' to build the script: At least the use of a text editor, and some form of command line syntax, which might include determining the working directory and/or tree structure to be archived. < Unfortunately, there are so many folks who will jump on PKAZip as their < archiver of choice, I will be forced to use at least the 'unZip only' version, < which can be run from a script. I will be using it to convert any ZIPped files < to something more useful. Interesting. I have just begun converting my Zoo'ed files to PKAZip, since I find it more useful. To each his own, I guess. < -larry -- Chris (Insert phrase here) Seaman | /|__|\__/|__|\ crs@cpsc6a.att.com <or> | | | Where does he get ...!att!cpsc6a!crs | | /\/\ /\/\ | those Wonderful toys? The Home of the Killer Smiley | \| \/ |/
fnf@estinc.UUCP (Fred Fish) (01/16/90)
In article <1802@agora.UUCP> billsey@.UUCP (Bill Seymour) writes: >In article <258@estinc.UUCP: fnf@estinc.UUCP (Fred Fish) writes: >:Does it still have the distribution restriction of "NO FEE IS CHARGED FOR >:USE, COPYING, OR DISTRIBUTION" in the zip.license file? If so, I guess >:it won't show up in any PD libraries. > > Yup. Those exact same words are still there... I guess this means >you won't be putting it on one of your PD disks? :-) That is correct. I interpret that statement to mean that no money can flow from the recipient of the software to the provider, regardless of how the distribution is made. I could make the same sort of argument that online services make, that the charges are for "time spent" as opposed to the "product exchanged". In fact, this IS how I regard my distribution fees. They cover all the material and time costs involved in transfering (hopefully) exact images of a master disk to the recipient, without regard to the material included on the disk. I still believe that without further clarification from the author, that the distribution restriction should preclude pay-for-time services from including pkazip in their online files. -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf
hamilton@intersil.uucp (Fred Hamilton) (01/16/90)
In article <2373@cpsc6a.att.com>, crs@cpsc6a.att.com (Chris (I'm a programmer, not a Doctor!!) Seaman) writes: > kudla@pawl.rpi.edu (Robert J. Kudla) writes: > < (Pete Ashdown) writes: > < -> What is really nice about it [PKZip] is the fact that the whole thing is > < -> intuitionized, which IMHO makes it a better program than all the other > < -> compressors combined. Its interface looks GOOD too! > < > < Seriously though, I think PKZip Amiga sucks. > > It hase been working OK for me. > > < It pains me to say this, but I'd rather use Arc. > > I'd rather not archive than have to use Arc. :-) The *best* archiving solution (and much more) is the directory utility SID V1.06. I hated DUs before I saw SID (prefering the CLI), but now I use SID exclusively for file management, archiving and de-archiving, showing pictures, hearing samples, etc. Now the NEAT thing about SID is that if you click on ANY archived file (.arc, .zoo, or .lzh), SID will display the contents of that file. If you select one or more archived files, then select UNARC, SID will automatically choose the correct un-archiving program and de-arc the program for you. Finally, if you select a number of files and hit ARC, it will archive those files for you using whatever archive program you prefer. There are SO many good things about SID, and only a few bad ones (which I mentioned in the letter accompanying my $25 shareware registration that I wrote out within hours of discovering the program). You should all check it out. SID 1.06. Very nice. -- Fred Hamilton Any views, comments, or ideas expressed here Harris Semiconductor are entirely my own. Even good ones. Santa Clara, CA
Adam.Benjamin@cave.cc.andrews.edu (Adam Benjamin) (01/16/90)
So I hear the latest arciver ZIP is out for us Amigans now...
My question is...
What is the best. (these are arcivers, so which one sqeezes the smallest?)
And I don't want a reply from any of you 150+meg wren users out there
8-) 8-)
//
\X/ Adam B
--
Fidonet : Adam Benjamin on 1:227/220 The Cave BBS (616) 471-2525
Internet: Adam.Benjamin@cave.cc.andrews.edu
UUCP : ...!{uunet, ames}!sharkey!aucis!cave!Adam.Benjaminkudla@pawl.rpi.edu (Robert J. Kudla) (01/16/90)
In <2373@cpsc6a.att.com> crs@cpsc6a.att.com (Chris (I'm a programmer, not a Doctor!!) Seaman) writes:
-> slow in implode mode, though still faster than LHArc (with
-> comparable compression), but it is quite fast (faster than Zoo) in
-> Shrink mode, but still gives compression as good as Zoo. It SHOULD
Why can't the PK people use real names for their compression schemes,
like "Lemple-Ziv" and "Huffman"? Even the Mac users' Stuffit does
that... all these "Imploding" and "Squashing" things make me think of
all the various pirate cruncher programs written by twelve-year-olds
to sound totally rad ]<uel or whatever.
-> be getting a lot of novice attention, since that was the main
-> reason for providing an intuition interface. My brother couldn't
-> remember the Zoo syntax to save his life, but I guarantee he will
-> know how to use PKAZip. I admit the lack of CLI support is a
-> problem, but it should appear in the next version.
Your brother should try one of the umpteen CLIWizard clones out there
that supports Zoo, LHArc, etc. My objection is not simply that it has
an intuition interface, but also that it tries to be a mega-directory
utility as well. Archivers should be small, simple programs. At least
he could have saved a little space by bagging the custom screen and
hideous "NeXT" look.
Oh yeah, and the problem with novices giving it lots of attention is
that many of the people who make the rules on the BBSes around here
are novice users (you know, the kind who rejoice when they figure out
the DIR command) and they're on the verge of requiring everyone to
upload in ZIP format. Extra bad.
-> There are a lot of Amiga users out there who don't know (or want to know)
-> about the CLI, and I think it's about time a good archiver was made
-> available to them.
See what I said above regarding the directory utilities.
-> PKAZip has a simple interface (what could be simpler than Intuition?),
-> decent compression (at least as good as Zoo in shrink mode), and is
-> 30-40% faster than Zoo in shrink mode. What more could you want? :-)
What could be simpler than intuition? Well, MacOS, for one. :) By
"simple", I mean compact, fast, uncluttered, and available for use in
script files. I don't mean "OK boys and girls, we're going to pick up
our mousies now and point at the 'Lets Put Together some Files'
gadget".
And what more could I ask for? Indeed. Unix compatibility, a smaller
executable, my own preferences if they must include a hideous graphic
interface, not eating 200k while simply idling and nearly 300k when
compressing, not crashing because I tried to run dterm (which eats
about 50k and the serial port) at the same time, and if possible, to
be compiled pure. Save the last one, Zoo is what I could ask for. Or a
command line ONLY (no huge executable, please!) version. My solution
now is to unzip everything I get and if I put it elsewhere it gets
LHArced or Zooed. Simple.
--
Robert Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonkudla@pawl.rpi.edu (Robert J. Kudla) (01/16/90)
In <2374@cpsc6a.att.com> crs@cpsc6a.att.com (Chris Seaman) writes:
-> Could you provide an example of how you use Zoo with no manual
-> intervention? Frankly, in all the time I've been using the Amiga,
-> I've never found a need to do so. I don't spend that much of my
-> time archiving/unarchiving files. Besides, it seems that, in order
-> to use an archiver that requires 'no' manual intervention, one
-> would still need to 'intervene' to build the script: At least the
-> use of a text editor, and some form of command line syntax, which
-> might include determining the working directory and/or tree
-> structure to be archived.
How about this?
foreach archive ($*)
zoo x// $archive
end
or
foreach archive ($*)
set newdir `strhead . $archive`
cd $newdir
zoo x ../$archive
cd ..
end
or
alias zv 'zoo v \!*'
The first will extract properly any recursive archives. The second
will correctly extract any non-recursive archives. (I'm not sure on
the syntax though... it's been a while since I wrote it.) The third,
obviously, lists an archive. You can't do any of those things with
your "simple" PKZip 1.0.
--
Robert Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonreynaldo@athena.mit.edu (Rey Villarreal) (01/16/90)
I don't know about the rest of you but I think that the look of PAZip is great. Gray is the Amiga's color. I hope Commodore adopts a similar look for Workbench 1.4. Which leads me to the question. Can someone out there in the know post of a couple of .iff pictures of 1.4 as it looks now to an FTP site. Mucho Gracias Rey ---Worlds most ardent Oiler fan
new@udel.edu (Darren New) (01/17/90)
Would it not be better to write a graphical front-end to ZOO and to add the better compression algorithm from LHARC to ZOO rather than having NEW archivers with incompatible formats showing up all over? -- Darren
sean@ms.uky.edu (Sean Casey) (01/17/90)
Where can I get source to PKZip? I won't even *think* about replacing zoo till I can get source. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet, ukma!sean *** Copyright 1989 by Sean Casey. Only non-profit redistribution permitted. *** "Gotta warn ya, if you're not a RUSH fan, well, what's *wrong* with you?" *** -DJ during WKQQs Four HOURS of Rush special.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/17/90)
In <PORTUESI.90Jan17104219@tweezers.esd.sgi.com>, portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes: >Larry, > >could you post the source to "extract" here on the net, please? Certainly. Usage is as follows: CD to the directory containing one or more files to be extracted. All files in the directory whose names end with .zoo, .arc, .lzh, or .lhz will be extracted into a directory. If there are any files you do not wish to have extracted, you should move them out of the current directory. Each file's 'root name' will be used to make a directory to hold the extracted files, and the archive file as well as the extracted files will be placed in the new directory. If a directory already exists, that archive file will be skipped. This is a safety feature. Easy enough to change if you would rather it acted some other way. type 'extract' The current directory will be scanned for all archive files, new directories made, the archive files moved to the new directories, and extracted with the appropriate unarchiver. You will be left in the directory in which you started. Assumptions Needs rexxsupport.library. I do the loadlib for it in my startup-sequence, so I don't include it in any of the programs I write. There may be other assumptions that will cause it not to work in your particular setup. If you see any, please feel free to ask about it, giving any error messages you get. >I've been meaning to write such a program for a while now, but haven't >gotten around to it. It might be fun to have the program recognize a >whole bunch of different file types, such as shar files, uuencoded >binaries, etc. and do the right things. That sounds like a good idea. I will have to take a look at how it can be done without clobbering anything. I usually proced very carefully with binaries and sources I receive over the net, since there have been conflicts in the past with duplicate names in shar files. If it can be done safely, it would be real nifty to have it even take care of multi-part .zuu files, uudecoding each part, joining them together, and unZooing the result. Anyway, here's the source for 'extract'. ---- slice here ------------ /* extract - extract files from any archive */ fnames = showdir('','f') curdir = pragma('d') do i = 1 to words(fnames) if length(word(fnames,i)) <6 then iterate archtype = translate(substr(word(fnames,i),length(word(fnames,i))-3,4)) rootname = substr(word(fnames,i),1,length(word(fnames,i))-4) say rootname archtype if find('.ZOO .LZH .LHZ .ARC', archtype) > 0 then do if ~exists(curdir || '/' || rootname) then makedir curdir || '/' || rootname else do say 'Directory' rootname 'already exists' iterate end end else iterate if substr(curdir,length(dirname)) = ':' then dirname = curdir || rootname else dirname = curdir || '/' || rootname fullname = dirname || '/' || rootname address command mv curdir || '/' || word(fnames,i) dirname call pragma('directory', dirname) select when archtype = '.ZOO' then do address command zoo 'e//' fullname say end when archtype = '.LHZ' then address command mv fullname || '.lhz' fullname || '.lzh' when archtype = '.LZH' then address command lharc e fullname when archtype = '.ARC' then do address command arc e fullname say end end end call pragma('directory',curdir) ------ end of slice ---------- Enjoy! -larry -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jenglish@tardis.Tymnet.COM (Jim English) (01/17/90)
In article <13702@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: >Where can I get source to PKZip? I won't even *think* about replacing >zoo till I can get source. > The guy who wrote it, is the sysop of the SafeHarbor BBS (They sell software and hardware too). The BBS number is 414-544-6567. I think his name is Dennis. Give them a shout and ask him. -- Jim English MD-IPC | JENGLISH@F74.TYMNET.COM or jenglish@tardis.tymnet.com (214)637-7406 Dallas | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jenglish
swan@jolnet.ORPK.IL.US (Joel Swan) (01/17/90)
In article <2373@cpsc6a.att.com> crs@cpsc6a.att.com (Chris (I'm a programmer, not a Doctor!!) Seaman) writes:
:
:PKAZip has a simple interface (what could be simpler than Intuition?),
A simple command line, that's what. The friend you mentioned still had to
figure out what all the little gadgets were at the bottom middle of the
screen (the H, U, S, E, D, plus arrows) and the myriad of expand and
compress menu choices. You mean he/she can remember all those but not
remember ZOO x filename ?? Plus, you must click, click, click, click,
click -- just to set destination, source and zip.
:decent compression (at least as good as Zoo in shrink mode), and is
:30-40% faster than Zoo in shrink mode. What more could you want? :-)
Fast? Yes. What more? A command line option. That's the whole point.
No one said trash the intuition part. People would like to see a trimmed
down version with CLI support. That's all.
:--
:Chris (Insert phrase here) Seaman | /|__|\__/|__|\
:crs@cpsc6a.att.com <or> | | | Where does he get
:...!att!cpsc6a!crs | | /\/\ /\/\ | those Wonderful toys?
:The Home of the Killer Smiley | \| \/ |/
--
Joel E. Swan USENET: swan@jolnet
Media Specialties Ltd. & PLINK : Amiga*Joel
Moody Broadcasting Network CI$ : 74746,3240portuesi@tweezers.esd.sgi.com (Michael Portuesi) (01/17/90)
>>>>> On 15 Jan 90 11:18:24 GMT, lphillips@lpami.wimsey.bc.ca (Larry Phillips) said: larry> In <2374@cpsc6a.att.com>, crs@cpsc6a.att.com (Chris (I'm a programmer, not a Doctor!!) Seaman) writes: larry> Certainly. I use an ARexx script called 'extract'. It recognizes files of the larry> form foo.(lzh|zoo|arc), creates a directory with the same name as the first larry> part of the filename, moves the file into the newly created directory, and larry> applies the appropriate command line to extract the files. Larry, could you post the source to "extract" here on the net, please? I've been meaning to write such a program for a while now, but haven't gotten around to it. It might be fun to have the program recognize a whole bunch of different file types, such as shar files, uuencoded binaries, etc. and do the right things. --M -- __ \/ Michael Portuesi Silicon Graphics Computer Systems, Inc. portuesi@SGI.COM Entry Systems Division -- Engineering
Sullivan@cup.portal.com (sullivan - segall) (01/18/90)
> > >So I hear the latest arciver ZIP is out for us Amigans now... >My question is... >What is the best. (these are arcivers, so which one sqeezes the smallest?) >And I don't want a reply from any of you 150+meg wren users out there > LHARC produces the smallest archives with PKAZIP a distant second (3-5% larger.) Both archivers run at about the same speed. ZOO and ARC produce similar files 10-15% larger than LHARC. LHARC supports protection bits, full filenames, recursive directory creation or search, and date/time stamps. LHARC's major failing is that it asks you each time it creates a subdirectory. PKAZIP is proprietary, and has an exceptionally ugly interface, but otherwise does an acceptable job of file compression. Amiga protection bits and time stamps are not supported to the best of my knowlege. ZOO's are more portable to UNIX than either ARC files or ZIP files. LHARC for the Amiga currently produces files with more recent compression schemes than either the MSDOS version, or the UNIX version. --Sullivan Segal _____________________________________________________________________________ /V\ Johnathan taught Sullivan to fly. Sullivan showed them all how to ' jump. Isn't it right that the student should surpass the master. To quote the immortal Socrates: "I drank what!" -- Real Genius _____________________________________________________________________________ Mail to: sullivan@cup.portal.com -or- {backbone}...!sun!portal!cup.portal.com!sullivan
dfrancis@dsoft.UUCP (Dennis Heffernan) (01/19/90)
In article <78.25B29F1F@cave.cc.andrews.edu> Adam.Benjamin@cave.cc.andrews.edu (Adam Benjamin) writes: > > >So I hear the latest arciver ZIP is out for us Amigans now... >My question is... >What is the best. (these are arcivers, so which one sqeezes the smallest?) >And I don't want a reply from any of you 150+meg wren users out there Well, I'm a floppy user so I guess I qualify :-). I've found that lharc gets roughly 10-15% better compression most of the time, though zip seems to do better on text files. I don't like zip very much because it's huge, and the intuition interface keeps me from using it in a script. It seemed to use godawful amounts of ram, too, though I belive that's because it creates all temporary files in RAM:, and that you can change it if you don't like it. Still, I'll be sticking with lharc for now. -- --dfh ...uunet!tronsbox!dsoft!dfrancis "Great spirits have always encountered violent opposition from mediocre minds." -Albert Einstein
mikes@lakesys.lakesys.com (Mike Shawaluk) (01/20/90)
In article <26053@cup.portal.com> Sullivan@cup.portal.com (sullivan - segall) writes: >LHARC produces the smallest archives with PKAZIP a distant second (3-5% >larger.) Both archivers run at about the same speed. ZOO and ARC produce >similar files 10-15% larger than LHARC. Please qualify your statements; it is my experience that PKAZIP compresses roughly the same (sometimes better, sometimes worse, but a small margin) as LHARC, when it is told to use Imploding, at a better speed. But, you don't say which version of LHARC you are comparing to. The current version of PKAZIP is 1.0, which is what I assume you are using, since the beta version only decompressed. Also, are you comparing both compression AND expansion speed, or just one of these? As an independent aside, has anyone undertaken a comparison of each of the available compression utilities, on some sort of "benchmark" set of files (this would be a great service to the Amiga community; I would volunteer to do so, but I consider myself too close to the source, since I am personally acquainted with Phil Katz and Dennis Hoffman, who are the authors of PKZIP/UNZIP and PKAZIP) >LHARC supports protection bits, full filenames, recursive directory creation >or search, and date/time stamps. LHARC's major failing is that it asks you >each time it creates a subdirectory. > >PKAZIP is proprietary, and has an exceptionally ugly interface, but otherwise >does an acceptable job of file compression. Amiga protection bits and time >stamps are not supported to the best of my knowlege. What is the basis for your claim of PKAZIP being "proprietary"? If you mean that the source code isn't in the public domain, then please say that. The file format is NOT proprietary, and a document describing it is distributed with PKZIP/UNZIP for MS-DOS, as well as a short document which dedicates the ZIP format to the public domain (these files were not distributed with the initial Amiga release, but I will suggest to PKWARE that they be added on any subsequent releases). And, you are incorrect in your assertion that Amiga protection bits and time stamps are not supported; they most certainly are. In addition, PKAZIP also supports file comments, and offers the ability to search a .ZIP file for a particular string in either the file name or file comments. I am sorry that you find the graphical interface to be "exceptionally ugly", but I guess "each to his own". It might be appropriate to add an "IMHO" to the above comments (or at least "IMO"). In your assessment that PKAZIP provides an "acceptable" level of file compression, it's interesting to note that most people found ARC and ZOO to provide "acceptable" levels of compression, and PK(A)ZIP exceeded each of these by a significant factor, even with its less dense (but much faster) Shrinking algorithm. The imploding algorithm was developed by PKWARE after the release of LHARC (no, it is NOT the same algorithm with minor tweaks), in an effort to keep his software moving forward (and obviously not to lose his user base to a different program). As an aside, I have seen a beta version of PKZIP 1.1 for MS-DOS, and the result of benchmarks that have been done between it and the current version of PKZIP and other compression utilities, including LHARC. Besides implementing a number of new features, it has improved compression, and routinely exceeds the compression achieved by its competition. Also, PKWARE is also investigating claims that the Amiga version lags in compression ratio behind LHARC, due to certain file types and structures that are uncommon in MS-DOS (i.e., IFF files, 68000 executable images), and is looking toward improving its algorithms to provide better compression for these cases, WITHOUT losing any compatibility with existing .ZIP files on either MS-DOS or Amiga (by the way, if you have a .LZH file which was created on your Amiga, try to extract a single file out of it on your MS-DOS system; if the file name has any lower case characters in it, good luck!) >ZOO's are more portable to UNIX than either ARC files or ZIP files. LHARC >for the Amiga currently produces files with more recent compression schemes >than either the MSDOS version, or the UNIX version. Pray tell, which UN*X version of LHARC are you referring to? I've not seen a port of LHARC in either BSD or SYSV to date. - Mike -- - Mike Shawaluk "Rarely have we seen a mailer -> DOMAIN: mikes@lakesys.lakesys.com fail which has thoroughly -> UUCP: ...!uunet!marque!lakesys!mikes followed these paths." -> BITNET: 7117SHAWALUK@MUCSD
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/20/90)
In <26136@cup.portal.com>, Sullivan@cup.portal.com (sullivan - segall) writes: >... >> select >> when archtype = '.ZOO' then do >> address command zoo 'e//' fullname >> say >> end >> when archtype = '.LHZ' then >> address command mv fullname || '.lhz' fullname || '.lzh' >> when archtype = '.LZH' then >> address command lharc e fullname >... > >LZH files should be extracted using: > > lharc e -mxa <filenam.lzh> > >Option -m suppresses requestors (ie: do you want to create this directory?, or > do you want to overwrite this file?) > > -x uses extended path names (eg: user/lib/foo/mydir) > > -a keeps file attributes > Ahhh! Thanks Sullivan. I just looked, and sure enough, there they are on the info that comes out wth just typing the program name. > -x consider extended file names > -a consider file attributes Who woulda thunk they mean what they do from this description? -larry -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
rogers@iris.ucdavis.edu (Brewski Rogers) (01/20/90)
I noticed in the documentation that came with LHarc said the author had used the original single file compression program source code (lzhuf.c), because it was written all in C, whereas the IBM LHarc source had lots of 8086 and other IBM stuff in it. Well, a few months back, I tried speeding up lzhuf.c (the single file compression program) on the amiga by using Tomas Rokicki's profiler and rewriting a bit of it into assembly. Currently, I have the decompressing speeded up by about 2-3X. (4-6K per second.) Is there some way I can contact the author of the amiga version of LHarc through the network so I can Email him the speeded up code? thanks, ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ "My brain is on fire!" \________/ Quark!
Sullivan@cup.portal.com (sullivan - segall) (01/20/90)
... > select > when archtype = '.ZOO' then do > address command zoo 'e//' fullname > say > end > when archtype = '.LHZ' then > address command mv fullname || '.lhz' fullname || '.lzh' > when archtype = '.LZH' then > address command lharc e fullname ... LZH files should be extracted using: lharc e -mxa <filenam.lzh> Option -m suppresses requestors (ie: do you want to create this directory?, or do you want to overwrite this file?) -x uses extended path names (eg: user/lib/foo/mydir) -a keeps file attributes By default all of these are off which will result in a flat file directory with no file attributes, and required user intervention. This cheatsheet is from lharc 1.0>> -- Lharc -- v 1.0 Oct 27 1989 by Paolo Zibetti (FidoNet 2:331/101.6) (LZHUF compression code by Haruyasu YOSHIZAKI) Usage: lharc [<switches>] <Command> <Archive> [<dest path>] [<file patterns>] summary of commands: summary of switches: e,x extract files from archive -p pause after loading l,v show archives contents -m no messages for queries p print extracted files to screen -x consider extended file names t test archive integrity -n no progress indicator a add files to archives -w set working directory m move files into archives -P set priority d delete files from archives -a consider file attributes u update files in archives -u convert file names to uppercase f freshen files in archives -r recursively collect files <Dest path> must end with `:' or `/' --Sullivan Segal _____________________________________________________________________________ /V\ Johnathan taught Sullivan to fly. Sullivan showed them all how to ' jump. Isn't it right that the student should surpass the master. To quote the immortal Socrates: "I drank what!" -- Real Genius _____________________________________________________________________________ Mail to: sullivan@cup.portal.com -or- {backbone}...!sun!portal!cup.portal.com!sullivan
bobl@pro-graphics.cts.com (Bob Lindabury) (01/21/90)
In-Reply-To: message from kudla@pawl.rpi.edu > Oh yeah, and the problem with novices giving it lots of attention is > that many of the people who make the rules on the BBSes around here > are novice users (you know, the kind who rejoice when they figure out > the DIR command) and they're on the verge of requiring everyone to > upload in ZIP format. Extra bad. Oh come on here! Who the heck are you to be telling the MAJORITY of users out there what they should or shouldn't be using or doing? Do you think your elitest computer mentality has any bearing on what's going to be accepted by the large majority of users out there? I think not! Your comments and others on the subject of this intuition based Zip utility makes me sick. I can understand the need for a small CLI based utility but that also goes hand in hand with an easy to use interface driven utility for the kids and mom and pops out there buying their first computers who don't know jack about the CLI or other nasties such as scripts (in their minds). Would you like to ban all intuition based archivers and require that everyone out there in the Amiga community learn scripts? You might as well try pissing into the wind. Seems to me the next logical step is to create a CLI based ZIP utility for all you elitest slobs out there who think nothing of sitting around banging on your CLI and writing scripts to automate your tasks (which require one hell of alot more time than clicking on PKZIP and unzipping a file). You know, the world doesn't revolve around you people who are heavy CLI users. Although I like the CLI and use it often, I can see the need for these easy to use Archivers and I don't have a closed mind about the product. Instead I see it as a step to a more universally accepted archiver for ALL computer types and ALL types of users, novice or experienced. You, on the other hand, have no tolerance for anyone who has less knowledge than you so you have to cut down those opinions because you have less confindence in your own abilities than you put on. > And what more could I ask for? Indeed. Unix compatibility, a smaller > executable, my own preferences if they must include a hideous graphic > interface, not eating 200k while simply idling and nearly 300k when > compressing, not crashing because I tried to run dterm (which eats > about 50k and the serial port) at the same time, and if possible, to > be compiled pure. Save the last one, Zoo is what I could ask for. Or a > command line ONLY (no huge executable, please!) version. My solution > now is to unzip everything I get and if I put it elsewhere it gets > LHArced or Zooed. Simple. Sure, a *nix version would be nice..in fact it is a requirement in my opinion. I feel the PKAZIP interface is elegant and not "hideous". It's easy to use and provides the user with many options. Too bad you don't have any memory. Zoo, give me a break! Yes, it's time for a CLI only version of ZIP but let's not go backwards to Zoo or the horrible alphabet soup of LHArc! Yeah, simple is the thought you put into your reply on this subject. > Robert Jude Kudla <kudla@pawl.rpi.edu> -- Bob _______________________ Pro-Graphics BBS 201/469-0049 ________________________ InterNet: bobl@pro-graphics.cts.com | ProLine: bobl@pro-graphics UUCP: ..crash!pro-graphics!bobl | CServe: 70347,2344 ARPA/DDN: ..crash!pro-graphics!bobl@nosc.mil | Amer. Online: Graphics3D ___________ ____________ Raven Enterprises - 25 Raven Ave. Piscataway, NJ 08854
bobl@pro-graphics.cts.com (Bob Lindabury) (01/21/90)
In-Reply-To: message from new@udel.edu > Would it not be better to write a graphical front-end to ZOO and to add > the better compression algorithm from LHARC to ZOO rather than having > NEW archivers with incompatible formats showing up all over? -- Darren Hmm..NEW archivers with incompatible formats? Where have you been? Seems to me that most every other computer made can ZIP and UnZIP a ZIP file. I have a ZIP utility for my Amiga, my Apple //, my IBM and I have seen them for the Atari ST's and I'm sure they are in the works for *NIX systems. So where is that incompatibility you're talking about? If you're talking incompatible with Zoo, they you're right..but since when was ZOO ever compatible with anything other than the AMIGA and Unix OS's? I'm not that familiar with what machines Zoo works on but I've only seen it on the Amiga. -- Bob _______________________ Pro-Graphics BBS 201/469-0049 ________________________ InterNet: bobl@pro-graphics.cts.com | ProLine: bobl@pro-graphics UUCP: ..crash!pro-graphics!bobl | CServe: 70347,2344 ARPA/DDN: ..crash!pro-graphics!bobl@nosc.mil | Amer. Online: Graphics3D ___________ ____________ Raven Enterprises - 25 Raven Ave. Piscataway, NJ 08854
kudla@pawl.rpi.edu (Robert J. Kudla) (01/22/90)
In <1245@crash.cts.com> bobl@pro-graphics.cts.com (Bob Lindabury) writes:
-> Oh come on here! Who the heck are you to be telling the MAJORITY
-> of users out there what they should or shouldn't be using or doing?
I'm not. I'm saying that they haven't the right to force me to pick up
the mouse. Ever.
-> the need for a small CLI based utility but that also goes hand in
-> require that everyone out there in the Amiga community learn
-> scripts? You might as well try pissing into the wind.
No, but I would like to ban any archiver that cannot be run
interactively. I'd also like to see archivers for which there is no
publically available source be left to rot as they should be.
-> Seems to me the next logical step is to create a CLI based ZIP
-> utility for all you elitest slobs out there who think nothing of
-> sitting around banging on your CLI and writing scripts to automate
-> your tasks (which require one hell of alot more time than clicking
-> on PKZIP and unzipping a file).
Me: extract *
You: clickety click, start Zip
clickety click, click, click, select all the archives you want to
extract.
clickety, click on the "extract" button.
This assumes you don't GURU the machine by running out of chip.
-> You know, the world doesn't revolve around you people who are heavy
-> CLI users.
Yes, it does. Show me a programmer who uses a clickety-click interface
exclusively (or even mostly) and I'll show you a Hypercard user.
-> Although I like the CLI and use it often, I can see the need for
-> these easy to use Archivers and I don't have a closed mind about
-> the product. Instead I see it as a step to a more universally
-> accepted archiver for ALL computer types and ALL types of users,
-> novice or experienced.
Not when experienced users are forced to spend their time clicking to
hell and back to do something that would take four seconds to do using
a script that took two minutes to write. My complaints are based on
(1) the unavailability of a small cli-based Zip and
(2) the sysops of many boards forcing all uploads to be Zipped because
a fraction of the users don't know how to type (although they managed
to figure out the CLI-based BBS pretty well... skypix ain't that
popular you know).
-> You, on the other hand, have no tolerance for anyone who has less
-> knowledge than you so you have to cut down those opinions because
-> you have less confindence in your own abilities than you put on.
Excuse me? I cut down on those who force me to take up my precious
disk space, quit my terminal just to de-archive stuff lest it crash,
use the mouse, look at colors which are *not* my preferences (isn't
the name of the program - "preferences" - enough?), look at a low-res
screen, use a different archiver on Unix, and abandon all my
time-honored procedures. As a matter of fact, I'm a pretty lousy C
programmer. But my system runs real smoothly, and all I ask is that it
stay that way.
-> Sure, a *nix version would be nice..in fact it is a requirement in
-> my opinion. I feel the PKAZIP interface is elegant and not
-> "hideous".
That's nice. Obviously, so did the designers. In fact, they probably
thought it was "wicked rad ]<uel" or something. However, a lot fewer
people would have complained had their program paid attention to the
user's preferences rather than assuming everyone likes low-res
greyscale.
-> It's easy to use and provides the user with many options. Too bad
-> you don't have any memory.
I don't have any memory? I have a meg, and the standard half-meg of
chip out of that. If a program (and not even an application, but a
simple utility!) cannot multitask well in such a commonplace, normal
environment, it's cutting out a good 600,000 or more users. Next
you'll be bitching at someone who complains that TCP is slow because
they "only" have 2400 baud.
-> Zoo, give me a break! Yes, it's time for a CLI only version of ZIP
-> but let's not go backwards to Zoo or the horrible alphabet soup of
-> LHArc!
Horrible alphabet soup? Looks pretty much the same (perhaps simpler)
than Arc or Zoo. I'm also interested in your confusion at the array of
commands in these archivers when everytime you run Zip you're forced
to look at *its* whole gamut of commands. "Now, where is that
add-recursive button...."
How is Zoo going backwards when most Amiga/Unix users still use it
regularly? Most Net postings are in that format, in fact.
-> Yeah, simple is the thought you put into your reply on this
-> subject.
I've been archiving stuff and unarchiving stuff for years as the sysop
of two BBSes and user of hundreds, and now Usenet. I've put a great
deal of thought into what makes a good archiver. There are solutions
for those who are uncomfortable with the CLI-only archivers;
currently, there is no solution for those who are uncomfortable with
the Intuition-only Zip, let alone those of us who would automate our
work. Can you concede at least that much?
--
Robert Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonrumford@afitamy.fidonet.org (Don Rumford) (01/24/90)
> So I hear the latest arciver ZIP is out for us Amigans > now... Anyone know where I can F'req this new ZIP program. Would be most appreciated. -Don- -- Don Rumford - via FidoNet node 1:110/300 UUCP: uunet!dayvb!afitamy!rumford ARPA: rumford@afitamy.fidonet.org ---------> The AFIT Amiga Users BBS/UFGateway Dayton, Oh. 1:110/300
dorf@iesd.auc.dk (Thomas Dorf Nielsen) (02/01/90)
In article <9744@baldrick.udel.EDU> C503719@umcvmb.missouri.edu (Baird McIntosh) writes: >In article <1990Jan26.165551.7614@iesd.auc.dk>, dorf@iesd.auc.dk (Thomas Dorf >Nielson) asks: >>Is there anyone who knows, whether DiskSalv requires 1Meg? > >DiskSalv 1.4 (latest version I have) has a LOMEM option that minimizes >memory used... I don't know if it works in 512k since I have a 2000 >(1 meg), but I would think it does work in LO MEMory. :-) > > / Baird McIntosh (2nd yr CS/Math major, University of Missouri-Columbia) ><-- c503719@umcvmb.missouri.edu <-or-> c503719@umcvmb.bitnet > "Every multitasking system needs a talking clock..." -- Andy Finkel First: Nielson would be sweedish, Nielsen is danish - AND SO AM I ;-) ^ ^ Would anyone happen to know, whether some special stack-setting is needed to make DiskSalv run on a 512K Amiga? I seem to have some problems! Thomas -- dorf@iesd.auc.dk
daveh@cbmvax.commodore.com (Dave Haynie) (02/16/90)
In article <9744@baldrick.udel.EDU> C503719@umcvmb.missouri.edu (Baird McIntosh) writes: >In article <1990Jan26.165551.7614@iesd.auc.dk>, dorf@iesd.auc.dk (Thomas Dorf >Nielson) asks: >>Is there anyone who knows, whether DiskSalv requires 1Meg? >DiskSalv 1.4 (latest version I have) has a LOMEM option that minimizes >memory used... I don't know if it works in 512k since I have a 2000 >(1 meg), but I would think it does work in LO MEMory. :-) The latest DiskSalv (V1.42) will recover from floppy to floppy on a 512K machine, no problem. The program itself is written with special attention to stack usage, so it should be happy as a clam with the default 4K of stack space. However, the amount of memory needed by DiskSalv is far more dependent on the disk you're recovering than on DiskSalv itself. The LOMEM option helps to minimize the amount of fixed overhead DiskSalv will use for any given operation. The program needs, dynamically, 8 bytes per file and (I think) 52 bytes per directory entry for normal operation, plus 2 bits per disk block for normal, 1 bit per disk block for LOMEM recovery. For very full/large recoveries on systems with only a small amount of memory, using the FILE or START/STOP options can limit the scanner to only a portion of the disk, allowing one to recover that disk in pieces. > / Baird McIntosh (2nd yr CS/Math major, University of Missouri-Columbia) -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough