On Tue, 28 Apr 1998, Werner Koch wrote:
Lindsay Mathieson <lindsay(_at_)powerup(_dot_)com(_dot_)au> writes:
Why not just document the usage of zlib - A new compression algorithm would
break existing implementations and compatibility is one of the objectives
for the spec.
PGP used an early version of zlib which was limited to a 13 bit
compression window, the RFC documented zlib does not have this
limitation. It's okay to support the old version, but why should
I not use a newer (and documented) one as an option?
They actually used infozip's original inflate code when they were cloning
PKzip on unix. Because DOS and other machines had memory limitations, the
window size was limited to 8K.
One of these days I am going to get a palm pilot and port my lib. Enough
of SSLeay and zlib are there. If this works with 5.x, there should be no
reason to continue the limit.
Also, the algorithm is *not* different, just that PGP 2.6.2's compression
is not strictly compliant with the RFC. It takes about two minutes to
change this in the PGP 2.6.2 code (at least the decompression side).
To quote from RFC 1951:
3.3. Compliance
A compressor may limit further the ranges of values specified in
the previous section and still be compliant; for example, it may
limit the range of backward pointers to some value smaller than
32K. Similarly, a compressor may limit the size of blocks so that
a compressible block fits in memory.
A compliant decompressor must accept the full range of possible
values defined in the previous section, and must accept blocks of
arbitrary size.
around line 141 of src/zinflate.c (in one of the PGP 2.6.2 dists):
#ifndef WSIZE
# define WSIZE 8192
/* window size--must be a power of two, <= 32K, and equal to that of zip.
* On 16 bit machines (MSDOS), WSIZE must be <= 16K (32K is possible
* with a few hacks, see the zip archiver.
*/
#endif
2.6.2 should be fixed (including hacking the DOS version if needed).
--- reply to tzeruch - at - ceddec - dot - com ---