[Zlib-devel] RE: [png-implement] Binary-incompatible change in the DLL interface of zlib

[Gerard Juyn]

> > I build libmng.dll with Borland C++, which does *not* require any
> > runtime library. Any C-routines required are simply enclosed in the
> > binary. This may make some binaries a bit larger than they could be,
> > but it removes any dependancy on a (not so stable) runtime library.
> 
> It does require and it does use the Borland static C runtime library.
> It's not a dynamically-linked runtime library, but it is, well, a
> runtime library. It will cause problems just like the others.

But it shouldn't matter what runtime library is used internally, unless... and 
now I think I begin to understand the big problem... the zlib API uses C runtime 
types as paramaters in the exported functions. That's another unfortunate 
historic design 'feature'.
 
> Gilles Vollant gave me an additional tip:
> http://support.microsoft.com/?id=94248
> 
> The problems listed there should not avoid a DLL built by linking it to
> the Borland static library. Until someone finds a more concrete article
> about the compatibility between the MS and Borland runtimes, I think we
> should take the safe approach and say "it's not 100% compatible".

It won't be. That's for sure. And if you have to choose one, because of the 
API design you will no doubt disadvantage people using another.

> Works in theory; let's see if it works in practice.
> (so far it didn't work too well. Gilles used to offer ZLIB.DLL, which
> was pointed to from the zlib home page).

Yup. But you can still download the source zlib *without* a standard DLL 
included, right? I even have libmng.dll included in CVS!
 
> > There's already a tool for libmng, which I could extend with your
> > zlib1.dll when it is ready. The installer also has a DirectX-like
> > [...] http://libmng.sf.net/windows32.html
> 
> Interesting. I would be glad to benefit from your knowledge, and from
> the tools you wrote. Joining the efforts to maintain zlib1.dll and
> libmng.dll is something that I'd like to do.
> 
> What I can take care of is the consistency in the zlib configuration
> headers, and in the makefiles. Gilles insisted that a macro ZLIB_STDCALL
> is necessary, and I think he is right - it's just that the macro is not
> enabled for a standard DLL build. I will also add ZLIB_FASTCALL, for
> easier integration with Delphi.

Is there a good way to detemine what calling convention a DLL is built with? 
The problem is stack-corruption when intermixing STDCALL with CDECL, but 
only on the parameters, right? So a global function with no paramters that 
returns a code for the used calling convention inside the DLL could be called 
independantly of what calling-conventions are used in the app or DLL. If such 
a function were in place, my diagnostic tool could check first if the function 
exists and then what it returns without crashing. That would be a good test to 
check zlib1.dll compatibility followed by some other default test to check its 
actual functionality.

Let me know if you think that's useful, and I'll see about adding such a thing 
after my holiday (4-25aug).

Gerard