[Zlib-devel] zlib 1.2.5

[Cosmin Truta]

On Mon, May 24, 2010 at 3:28 PM, John Bowler <jbowler at frontiernet.net> wrote:
> From: Cosmin Truta
>>That one won't work. It's ABI-incompatible, mainly because it uses a
>>different, non-default calling convention (stdcall).
>
> IRC MS seem to have fixed this - linking something with "C" calls to a DLL that provides "WINAPI" entries seemed to work.  I didn't investigate in detail but it seemed likely that the linker was inserting a compatibility layer.

Interesting to know. Performance degradation? Yes, but it's still more
useful than a crash.

>>Even leaving
>>backwards compatibility aside, we'll run again into the problems that
>>we had some 10 years ago in libpng, when switching between DLL-enabled
>>and non-DLL-enabled builds would lead to crashes, because of the
>>different calling conventions used across these two kinds of builds.
>
> That doesn't happen because, as William says, the two DLLs use different names - hand swapping the DLL on disk to one with a different API results in a program that simply doesn't load because of unresolved references.  (I think I verified this.)

You are right, but I was referring to something different.

Many years ago we on the libpng list were clueless for a long while as
to why using the zlib dll leads to crashes. Until I realized that
enabling the DLL build automatically enabled the stdcall convention in
the zlib build, but it was still cdecl in use. In addition to that,
the exports were by ordinals, so we did not get "unresolved reference"
errors, we got crashes. That happened as of zlib-1.1.3, 1.1.4.

For that reason, I insisted on by-name exports and cdecl calling
convention in the redesigned dll, whose name I also changed: the new
zlib1.dll.

> What does happen is that libpng users who pass (FILE*) objects into libpng (the normal usage) can get crashes in libpng when libpng uses a different C runtime DLL (and the same applies to zlib itself, but libpng doesn't use the zlib APIs in question.)  This is definitely one of the problems that was happening 10 years ago and it definitely still happens.

That is also well-known problem indeed, worth paying attention to, but
it's not what I was referring to.

> This is why we really do need an official zlib DLL and why we (as in libpng) should also be providing one - so that the C runtime issues, difficult enough to solve, don't get complicated by different libpng (or zlib) runtime DLL requirements.

And we do! The DLL FAQ is what I would consider the official
specification, and any build that complies to that specification can
be distributed on zlib.net as an official build.

Speaking of which, since William is recuperating from hand surgery,
maybe I can try and do a DLL build myself, later today. I haven't done
that in a long while. William, I hope you get well soon! :-)

William A. Rowe Jr. wrote:
> Gilles' is useful for some folks, but perhaps it should be zlib32.dll (e.g.
> falling in the foo32.dll convention of typical win32 API libraries).

After zlib1.dll was first published, Gilles renamed his build to zlibwapi.dll.

Best regards,
Cosmin