Re: Using ZLib

On 30 May 2005 03:01:17 -0700, "QS Computing" <qscomputing@xxxxxxxxx>
wrote:

>I think I have solved my problem now: After noticing that most online
>examples use TZDecompressionStream instead of TDecompressionStream, a
>short Google led my to ZLibEx - the first result if you Google for that
>term. Its TZDecompressionStream allows its length to be read.

If I were you I would not change horses in mid stream

Having thought about this a bit more I think I know what has happened.

Someone has noticed that the Delphi ZLib Decompression routine tries
to read from a SourceStream when the Position of the source stream is
equal to the Size of the source stream.

This (in their jiggered SourceStream descendant) probably raised a
'read past end of file' error.

Rather than examine the code in TDecompressionStream very carefully,
they decided that Borland were idiots, and simply hacked out the code
that caused the 'so called' error.

Then in desperation, they tried reading the data byte by byte, and
miracle of miracles - it worked.

Or maybe they resorted to storing the actual decompressed size first,
and found that it worked.

Instead of going back and undoing their hacks to library code, they
wrapped up and you inherited their meddling.

In fact the problem is one of 'code purity', TDecompressionStream does
not support a Size property - very correctly as it is reading from a
compressed source that does not (under Huffman) know anything about
the size of the source data.

That means that for TDecompressionStream to ask the SourceStream for a
size would be assuming that the SourceStream supported more than the
TDecompressionStream

- a violation of poly morphism
- like a monkey asking a human what time it is

If a monkey does not have a wristwatch, it should not ask that
question of a human masquerading as a monkey.

Unfortunately Borland assumed that people would understand that since
TDecompressionStream does not have a Size property
- it could (should) not expect anything else to have a Size property.

The answer is pretty simple, filter the Input Stream and make sure
that it understands that trying to read at the end of the file ONCE is
valid behaviour - and is the way the old PKZIP libraries determined
that there was no more data.

It is (ahem) emulating a character device driver in its behaviour.

As an aside, if a TZDecompressioStream supports a Size property then
it is either decompressing data that differs from a pure Huffman byte
stream, or it is doing something evil like allocating an internal
buffer and slyly decompressing the whole lot behind your back in the
hope that its internal buffer will be sufficient to cover the 'cost'
of potentially having to repeat the decompression.




.