[fpc-devel] Unit linking to .obj files and fpcmake.
J. Peter Mugaas
jpmugaas at charter.net
Tue Apr 11 16:27:04 CEST 2006
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
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 126.96.36.199 188.8.131.52 - 8 September 200)
Add Z_BLOCK flush option to return from inflate at block boundary
Then the header I have references the following from (184.108.40.206 - 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 220.127.116.11 - 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
More information about the fpc-devel