Re: SDK vs ZIP?

[Don Bruder <dakidd@sonic.net>]

In article <43f004f7$0$58125$742ec2ed@news.sonic.net>,
 Andy McFadden <fadden@fadden.com> wrote:

> Bryan Parkoff <none@nospam.net> wrote:
> >     What is the difference between SDK and ZIP compression utility?  Apple 
> > II does have ZIP utility, but it is very slow at 1MHz.  I tried to compress 
> > using ZIP on Apple IIgs at 7MHz so it seems running okay little faster for 
> > couple minutes.  It seems that SDK is little faster.  Why?
> 
> SDK (ShrinkIt) is using a combination of RLE and LZW.  Zip is using
> Deflate, which is a very different algorithm.  Deflate is fairly slow
> when compressing data, much faster when uncompressing.
> 
> ShrinkIt is hand-coded assembly, the Zip utility is probably C code.

If it's the Zip utility I'm most personally familiar with, I can tell 
you with certainty that it's a mix of Manx Aztec C and hand-coded 
assembly. How can I say this? 'Cause if it's the one I'm thinking of, my 
stumpy little fingers and fevered little mind, along with those same 
parts of a fellow conspirator whose name was never revealed to me, but 
who claimed to be located in Pennsylvania, conspired to code large 
chunks of it as part of trying to (and eventually succeeding - at least 
90%) write a Blu-Wave compatible offline Fidonet reader package for use 
in conjunction with ProTerm - A task that "they" said was impossible for 
the //e. For being impossible, it ended up working pretty darn well. 
Unfortunately, this happened about 3-4 months before the internet "fire" 
caught, and rapidly drove most BBSes out of business.

SHK and ZIP are indeed *TOTALLY* different algorithms, and as you say, 
Deflate/Implode, and all the other flavors of compression (other than 
"store", which is just that - cram it into the zip file with zero effort 
at any kind of compression) found in zip files are *MUCH* slower in the 
compression process.

Trying to get around all the "starts with a digit" filenames that were 
part of the Blu-Wave "standard" (another severely moving target) was a 
major challenge that we finally only managed to solve by patching ProDOS 
"down on the metal" - After running our reader, you *HAD* to reboot. If 
you didn't, there was no telling what kind of bizarre (and totally 
inaccessible to a "not-patched" ProDOS) filenames you might end up 
creating, since my patch essentially lobotomized the "Is this a legal 
filename?" logic built into ProDOS, letting *ANYTHING* you could either 
type from a keyboard, or cram into a string within a program, be the 
first (or any other) character of a filename. Consider the "wisdom" of a 
file named "1/A.something.data"... Note that this is a *FILENAME*, not a 
*PATHNAME*, as it appears to be at first glance - The "/" became a legit 
filename character after my "lobotomy", meaning that, among other 
things, trying to mess around in subdirectories was pretty much futile 
after my patch was installed. Not a real good thing when dealing with a 
"massive" 20 meg (OK, so for the time, it WAS massive...) SCSI HD in the 
system... Users tend to find it disconcerting, to say the least, when 
everything but the root directory of their drive becomes inaccessible...

-- 
Don Bruder - dakidd@sonic.net - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info