[Zlib-devel] zlib 1.2.5

[John Bowler]

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.

>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.)

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.

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.

John Bowler <jbowler at acm.org>