[Zlib-devel] TR: result of compression test

[Cosmin Truta]

2010/7/27 Török Edwin wrote:
> On Tue, 27 Jul 2010 13:36:50 +0200
>> do you have a sample executable which uses gzdopen te verify if a DLL
>> is full compatible?
>
> An executable no, but John Bowler posted the attached test program a while ago.

Is the user code expected to be that ugly? And gzdopen is meant to be
used primarily as in gzdopen(fileno(stdin),"r"), like fdopen, isn't
it? Not for a contrived case like John's, which, however illustrative,
would be better served by gzopen.

Let's finally release the MinGW-built DLL and call it a day.

In the Google search box, "zlib1.dll" shows up as the 1st suggestion,
as I type. "zlib" comes 2nd. This is needed, clearly, and we waited
too much.

We'd like the new zlib1.dll to be compatible to the old ones, and we'd
like zlib1.dll to work well with present-day Visual Studio.
Unfortunately, we can't have both.

When zlib1.dll was first released, we released a spec (DLL_FAQ) and
made a promise to maintain compatibility and drop-in replaceability,
and compliance to that spec. We can do that with the current MinGW
build, but not with the current VC build. OTOH we can't maintain what
Microsoft is constantly breaking: CRT compatibility across VC
releases. I mean, we can try, but there's only so much we can do. We
are still having a DLL that works "as well as possible".

IMO, the slight advantage in speed offered by the VC build does not
justify the lingering compatibility issues. On the upside, with MinGW,
we're getting a gzprintf implementation that doesn't suck.
(Microsoft's _snprintf is not entirely secure or standard-compliant.)
Win something, lose something.

So let's go ahead and release that DLL. We can still discuss altering
the spec and dropping the MSVCRT dependency (although, after seeing
the example, I'm personally more reluctant to changing it) for 1.2.6,
but we should still follow our own spec. The already-released DLL_FAQ
version 1.2.5 should be complied to by zlib1.dll version 1.2.5.

Best regards,
Cosmin