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

[Cosmin Truta]

On Mon, 28 Jul 2003, Gerard Juyn wrote:

> IMHO using CDECL for a DLL is a 'bad design decision' [...]

This is addressed in Question 5 in the DLL_FAQ:
  http://www.cs.toronto.edu/~cosmin/pngtech/zlib/DLL_FAQ.txt

As a matter of fact, the default convention is more friendly to the
foreign languages:
- All of them, except VB, support CDECL
  (although VB.NET should work fine).
- There are a couple that do not support STDCALL.
- By going with the default convention, it just as easy to override
  ZEXPORT in the makefile to whatever you want, for specialized
  purposes, such as VB.


> Pascal compilers and a few others may (Delphi for sure) work with it
> [...]

But you should use the Borland runtime with Delphi (see the end of
Question 7), so you need a separate build anyway. See "contrib/delphi/",
where ZEXPORT is overriden to __fastcall.

> STDCALL or WINAPI or whatever name you want to give it (even MS change
> their naming-habit as we all love...), it is still *the* Windows
> default and IMHO should be used for *every* DLL....

Not for the CRT DLLs, and not even for the MS demos that use the C API
(not the Windows API). See again Question 5.

If you search for "libpng.dll" over the png-implement archive in 2000,
you will see that Simon-Pierre Cadieux and I proposed to use STDCALL,
but then decided to use CDECL to avoid the (too many) problems that we
could have run into. The nastiest problem was caused by having different
conventions for the static lib and for the DLL. If you remember, we were
unable to have a running libpng.dll for a few months, until we finally
figured out what's wrong in the makefile.

Now libpng.dll is ok, and there is a separate build for VB, which keeps
the mess separate. We didn't have any other problem since then, and I
still think it's a good idea.

The problem could have been avoided by having STDCALL (or whatever) all
the way, but that was unacceptable when using zlib in other programming
languages. From the point of view of foreign languages (because there
are other issues as well), I think it's better to choose a single victim
(that is, the older Visual Basic), than many others. Besides, in VB,
some people would like to use COM interfaces and IDL/GUID/etc. junk, so
they would probably need a customized build of the DLL, anyway.


Cosmin