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

[Gerard Juyn]

> __stdcall doesn't work with varargs, it is not part of the C standard,
> it is only used in Windows (not in Linux, BSD or whatever). The only
> reason I see is that it is demanded in the older Visual Basic, but this
> sole reason is something that I already knew.

Valid point. I guess I was being nostalgic. I've had problems with porting my 
Delphi-code to Kylix and having to conditionally define all the STDCALL 
conventions along with conditional CDECL conventions. Quite the pain in the 
lower back. Unfortunately I can't go back. I will have to stick to STDCALL.

> Mixing __cdecl with __stdcall can be done by circumventing or otherwise
> avoiding the internal name mangling, but that would mean replacing
> link-time errors with run-time errors.

You've made a good case. I finally read your FAQ before blabbering any more 
comments. The only thing I personally find undesirable is having it linked 
against some external runtime library. Again you've got a good case there, but 
I just have a bad feeling about something like that. It's not uncommon for MS to 
modify these in incompatible ways.

Why not compile without this dependancy? If MSVC or MingW can't do it, use 
another tool. *You* (or someone else, but just *1* origin) should be the sole 
distributor of the standard DLL. This is something you should make more 
clear. Really discourage anyone to build their own 'standard' version. There 
should be just *1* source. And then it doesn't matter which compiler you use. 
That *is* the beaty of DLLs (probably the only one :)

This way you could also 'expand' the standard DLL with a separate STDCALL 
API specifically for older VB. Eg. add all functions with a vb_ prefix or _vb 
suffix or something and include a VB include file that does the magic 
translation. A single standard DLL with everybody happy.... Of course you 
can also leave that out until someone begs for it.

Anyway, the only real advice (that you probably know already) is that you do 
have to work out the best strategy you can think of right now, and then stick 
with it for at least a decade. And make sure there's only ONE (1) source of 
the DLL!!!!

I'll follow your progress, and if its satisfactory I may decide to link the 
standard libmng.dll against your standard zlib.dll
But again unfortunately, anyone using libmng.dll's zlib functions will have 
linked against STDCALL. I'd have to go the same way as you and create a 
libmng2.dll

We might even consider creating a bundle with zlib, libpng, lcms and libmng. 
Having a special Windows installer may help to expedite acceptance too. Just 
another idea....

Gerard

(at 6 eurocents now... :)

Gerard Juyn
gerard at datapartners.nl
www.datapartners.nl