[Zlib-devel] RE: [png-implement] Binary-incompatible change in the DL

[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

(that's already 6 eurocents now... :)