[Zlib-devel] RE : ZLIB_STDCALL or ZLIB_DLL_STDCALL macro

[Cosmin Truta]

On Mon, 28 Jul 2003, Gilles Vollant wrote:

> I prefer ZLIB_DLL_STDCALL because it is, in my opinion, easyier for my user
> replace ZLIB_DLL by ZLIB_DLL_STDCALL

But there is no point in using the "_DLL_" part, because this doesn't
have to apply only to the DLL. It can apply to the static library, too.

We are still discussing it with the libpng people, but so far the
consensus is that there should be no distinction between the flags used
for the DLL vs. the flags used for the static library.

AND

As explained at the end of Question 2 in the DLL_FAQ, there is still a
ZLIB_DLL macro, that enables a more efficient build of the DLL, but it
doesn't affect compatibility anymore. With or without ZLIB_DLL, the new
applications and the new ZLIB1.DLL will be compatible with each other.


So you should choose ZLIB_STDCALL, not ZLIB_DLL_STDCALL.


On the other hand, if the DLL name is changed, there is no need for
STDCALL compatibility. When the applications are recompiled, they should
work fine with the new DLL and with CDECL (unless the convention is
hardcoded in the app sources, which is not so good).

As I asked the other people: now that binary compatibility issue is
eliminated with the renaming of the DLL, what are the other reasons why
you want STDCALL, except for the old Visual Basic, and at the expense of
the rest of non-C programming languages?

Please note that, as we could do it separately for Delphi in
"contrib/delphi/", we can do it separately for Visual Basic, too.
We shouldn't have to pollute the header file, because VB doesn't need C
header files, anyway. And maintaining separate builds for VB and for the
rest of the world, using a unified family of macros and separate
projects, is easier than maintaining a single DLL binary but separate
(static vs. DLL) compilation options that are dangerous to mix, and
separate macro names in the zlib headers.


Cosmin


P.S.:
To clarify, I don't have any problem to add ZLIB_STDCALL and
ZLIB_FASTCALL to zlib.h -- but I still wish to know what is the *real*
reason why am I doing this. Binary compatibility is not the real reason,
as I explained in so many details; and source compatibility was never
problematic.