[fpc-devel] Unit linking to .obj files and fpcmake.

[J. Peter Mugaas]

On Tue, 11 Apr 2006 11:24:39 +0200 (CEST), Daniël Mantione wrote:
>
>
> Op Tue, 11 Apr 2006, schreef Marco van de Voort:
>
>>
>>> Over the years several indy bugs have been fixed, and nobody
>>> knows the
>>>
>> Several zlib bugs I meant here of course, some quite high-profile.
>>
> Hmmm.... True, but I think that should not stop people from using
> it; if people do not use our libraries, bugs won't get fixed in
> them.
>
I think it goes beyond that.  ZLib 1.20 introduced some new functions (it's hard to determine what version yours is because it simply says 1.2).

There are some ZLib 1.20 functions that your paszlib does not support that the standard ZLib libraries support.

Sumary from the changelog:
===
- New and improved inflate code
    - About 20% faster
    - Does not allocate 32K window unless and until needed
    - Automatically detects and decompresses gzip streams
    - Raw inflate no longer needs an extra dummy byte at end
    - Added inflateBack functions using a callback interface--even faster
      than inflate, useful for file utilities (gzip, zip)
    - Added inflateCopy() function to record state for random access on
      externally generated deflate streams (e.g. in gzip files)
    - More readable code (I hope)
- New and improved crc32()
- Add deflateBound() and compressBound() functions
===
The inflateback functions are much faster than the older inflateinit2_ functions and I use the inflateback functions given their speed.

The header I now have references something that was introduced in ZLib 1.2.0.5 1.2.0.5 - 8 September 200)

 Add Z_BLOCK flush option to return from inflate at block boundary

Then the header I have references the following from (1.2.0.1  - 17 March 2003)
- Add Z_RLE strategy for run-length encoding [Truta]
    - When Z_RLE requested, restrict matches to distance one
    - Update zlib.h, minigzip.c, gzopen(), gzdopen() for Z_RLE

Changes in 1.2.0.2 - 13 July 2003
- Add zlibCompileFlags() function to return compilation information

Usuually, I consider it a good idea to a have a comprehensive header since a lot of headers may wind up being recycled and used in ways you never thought.


-- 
I once had an open mind until people used it as a trashcan. 
J. Peter Mugaas, E-Mail:  oma00215 at mail.wvnet.edu
http://www.wvnet.edu/~oma00215