5 ms·
There were a lot of encoders at the time using this general scheme (a few more values to indicate match length or distances). PKZIP won at the time because it w
by beagle3 10y ago
There were a lot of encoders at the time using this general scheme (a few more values to indicate match length or distances). PKZIP won at the time because it was faster, and PK had the name recognition from his PKARC, which was a superfast implementation of SEA ARC (the dominant archiver on PCs at the time).
PK had to stop working on PKARC because of a C&D request from SEA. He wrote the first algos of PKZIP, which were on par with SEA ARC on compression (and with PKARC on speed), but weren't much better. (And have been deprecated since the 1990 if I'm not mistaken).
Then, the Japanese encoders started to rule the compression ratio (and had comparably reasonable compression times) - LHArc, LZAri, don't remember the rest of the names. LHArc or LHA (don't remember which), had basically the same scheme that PKZIP converged on, except it used adaptive arithmetic coding. PK replaced that with static huffman coding, trading a little compression for a lot of speed, and the format we now know and love as "zlib compression" was born (and quickly took the world by storm, being in a sweet spot of compression and speed).
There's another non-trivial thing that PKZIP had going for it - it put the directory at the end, which meant you could see the list of files in the archive without reading the entire archive! This sounds simple, but back then everyone adopted the tar-style "file header then data" appendable style, which meant that just listing the files inside a 300KB zip file (almost a whole floppy disk!) meant reading that entire floppy (30 seconds at least). PKZIP could do it in about 2 seconds.
- carey 10y agoWeren't there also (alleged) patents on arithmetic coding back then? Huffman coding had that as an advantage, too, especially when GNU were looking for an alternative to Unix' compress program.
- TD-Linux 10y agoYes there were. JPEG was also affected, and most decoders still don't support the optional arithmetic mode.
- creshal 10y ago> There's another non-trivial thing that PKZIP had going for it - it put the directory at the end, which meant you could see the list of files in the archive without reading the entire archive! Beginning and the end, which continues to bite us in the ass until today, where we regularly stumble over bugs when one part of a toolchain uses one entry and the rest the other.
- acqq 10y agoThe directory is only at the end in the PKZIP, there is additional info before each compressed file, like in TAR. It's actually good to have both, as it allows recovering individual files even when there's a corruption in other files or in the directory.
- deleted 10y ago[deleted]
- dalke 10y agoYes, it's possible to use the information to recover a corruption. The problem is, what happens if the two are different? This can be through accident or maliciously. If one tool uses the first and another uses the second, then you'll end up with different results, and it can be hard to figure out why they are different. It's like a CD, where audio players interpret the CD different than CD-ROM players. Some anti-copying techniques tried to take advantage of this to produce un-rippable CDs. A problem, however, was that car CD players used CD-ROM drives, so these CDs weren't playable in those cars. (https://en.wikipedia.org/wiki/Compact_Disc_and_DVD_copy_protection https://en.wikipedia.org/wiki/Compact_Disc_and_DVD_copy_prot... ) Or some HTTP header attacks based on duplicate headers. Let's say there's a firewall which allows only access requests for "Content-Type: text/plain". If the attacker includes the header twice, once as text/plain and the other as image/gif, then the firewall might only check the first while the back-end web server interprets the second. This is a silly example; I couldn't remember the real attacks which take advantage of the same mechanism.
- acqq 10y ago
- acqq 10y agoAnd "there's another non-trivial thing that PKZIP had going for it": https://en.wikipedia.org/wiki/Phil_Katz https://en.wikipedia.org/wiki/Phil_Katz "SEA was attempting to retroactively declare the ARC file format to be closed and proprietary. Katz received positive publicity by releasing the APPNOTE.TXT specification, documenting the Zip file format, and declaring that the Zip file format would always be free for competing software to implement."
- userbinator 10y agoLZH actually remains very common in BIOS images, probably because of its superior compression in relation to the other formats along with its low implementation complexity. See this article, for example: http://www.intel.com/content/www/xr/ar/support/boards-and-kits/000008221.fast.html http://www.intel.com/content/www/xr/ar/support/boards-and-ki... The file it references can be downloaded here: https://downloadcenter.intel.com/download/8375/Logo-Update-Utility-LOGOTOOLS-ZIP- https://downloadcenter.intel.com/download/8375/Logo-Update-U... ...and it's somewhat amazing that it contains the original LHA.EXE from 25 years ago: LHA version 2.13 Copyright (c) Haruyasu Yoshizaki, 1988-91 === <<< A High-Performance File-Compression Program >>> ======== 07/20/91 ===
- Moter8 10y agoHey, the first link seems to be from a RTL language, here is the Left-To-Right version that should look better: https://www-ssl.intel.com/content/www/xr/en/support/boards-and-kits/000008221.fast.html https://www-ssl.intel.com/content/www/xr/en/support/boards-a...