[Zlib-devel] zlib 1.2.4 released!

[William A. Rowe Jr.]

On 3/17/2010 1:33 PM, John Bowler wrote:
> From: Török Edwin [mailto:edwintorok at gmail.com] 
> On 03/17/2010 06:18 PM, John Bowler wrote:
>>> "* * * ***passes CRT objects across the boundary*** * * *"
>>>
>>> Zlib does *not* do this, so it's
>>
>> gzdopen() gets a file descriptor that was opened in the app.
> 
> A 'file descriptor' is not a 'CRT object'.  Ok, I admit this depends on the implementation, on UNIX it's an index into the U-area file table, so it definitely isn't a CRT object, on Windows I have my doubts about whether this works:

Yes, it is a CRT object.  The fd is an index to an array of crt structs of which
HFILE is but one member.  Remember 'fd's support several posix modalities which
aren't part of the Win32 API, so more context is required.

>> I was suggesting there should be more versions of zlib DLL, just how
>> there are multiple versions of pthreads DLL (4 I think).
> 
> I agree, I was only commenting on what 'zlib1' did.  Having 'zlib1mt' (/MT linked) and 'zlib1vb' (__stdcall API) is fine and probably good *iff* the (large) maintenance overhead is acceptable, and viable.

The /MT solution is certainly wrong; it completely breaks fd-passing in
all cases for gzdopen(), even when using a *consistent* crt library.  You
will already have MSVCRT.DLL loaded due to the underlying Win32 API, so
it's always the worst choice.

There is an msvcrt.dll on all windows machines out there today.  That isn't
true of msvcr70, msvcr71, msvcr80, msvcr90, or msvcr100.  What a mess the VC
team is capable of creating over a 10 year period :)

For users who want a combination, they best build zlib with their own
compiler.  As pointed out, zlib1.dll distribution is to benefit those
who didn't/couldn't compile it themselves.  So as a "system" library, the
current makes sense, and these other five alternatives are easily built by
the developer of any other software.