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

[Gerard Juyn]

> - There are a couple that do not support STDCALL.

That's quite amazing. What are those? How on earth could they access the 
Windows core API which is all 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.

As you know, the purpose of a standard DLL is that you don't recompile it. 
You need an import-library or import-unit (in the case of Delphi) which 
automatically links to the standard DLL, and loads it at run-time, or if you make 
some smart glue-code it can be loaded on demand. I wouldn't go that way 
with zlib unless it is used rather infrequently in several apps. But I do go that 
way with the standard libmng.dll and the Delphi interface. Works like a charm.
 
> 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.

Not quite. I would want a standard DLL. I wouldn't want to recompile it for my 
development platform. As it is now I've hard-linked zlib into libmng.dll because 
I can't rely on the rest of the world (for historic reasons, which you are 
familiar with) to have the same copy of zlib.dll. So far, I've run into 3 different 
kinds, but I'm sure there will be more floating around.

I would want to split libmng.dll into its constituant parts. But both zlib and the 
ijgsrc have a nasty design flaw. They depend on structures. Structures 
change. That's an age old problem we're all familiar with. lcms is a different 
story. It was designed more recently and flourishes as a standalone 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.

Do you want to consider zlib as giving core functionality (something that 
should have been in the core Windows API in the first place), or do you 
consider a useful addition?
If the first than STDCALL should be your choice. If the second I'd still say go 
with STDCALL. I certainly wouldn't consider MS samples a way-of-life.
 
> 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.

Yes. I saw the discussion, but didn't feel like budding in. A standard libpng.dll 
is of little use to me. A standard zlib.dll is, but not with CDECL convention.
As I remember some of the problems were name-mangling and even 
performance reasons. The latter I really can't follow as we're talking about 
high-level API functions that are called a few hundred times at most, more 
likely a lot less. So you'd save a few msecs to decompress a 2MB zipfile, so 
what...

> The nastiest problem was caused by having different
> conventions for the static lib and for the DLL.

(I think John Bowler just answered this one...)

A DLL and static lib have nothing to do with each other. Perhaps the test or 
development environment wasn't suited for one or the other, or someone was 
trying to use both from a single test-app. Consider a DLL and static-lib 
separate items. Also a static-lib isn't a static-lib between different 
development platforms.
 
> 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.

zlib is used extensively in Windows as well. Perhaps you could ask them to 
provide a standard interface for all their own dev-platforms.... :)

Just kidding of course. But if you and others in this project think you've made 
the right choice, than that's fine with me. It just won't be useful in my case. 
Doesn't matter, I've got other fish to fry anyway. Just confirming my 2 
eurocents....

Gerard