[Zlib-devel] ZLIB.DLL considered harmful

[Cosmin Truta]

Hello, again,


Ironically, I am the first to challenge my own proposal

  http://www.cs.toronto.edu/~cosmin/pngtech/zlib/zlib_dll.faq


Right now, as I said in the previous email, the proposal is much
about reverting to the old zlib-1.1.4 status, where the static
lib is compiled using CDECL, but the DLL is compiled using STDCALL.

But I have the following point, which Gilles might not like :)
even though I would appreciate his (and others') opinion.
If you don't want to read the rest, I'll tell you directly the
conclusion:

ZLIB.DLL is doomed. It is even more doomed than I thought
(details below), and no matter what course of action we will
take with respect to STDCALL vs. CDECL, it will crash someone's
application.

So I propose to just deprecate it and leave it as is, and start
again fresh. Start building and maintaining an official
ZLIB1.DLL, clean up the source code, too, and don't upgrade the
old one. The old applications that need binary compatibility will
not suffer, because they won't need the new stuff from zlib-1.2.x
(except, perhaps, the crc32 and inflation's extra speed, but that
is not a big issue). The new applications won't need binary
compatibility: since they are new, obviously, they are being
rebuilt, and they need source compatibility instead. The old
ZLIB.DLL and the new ZLIB1.DLL can stay in the system without
even knowing about each other; this solution is in fact common
practice.

The name ZLIB1.DLL comes from the "zlib"+"major version" naming
scheme. I expect there will be big changes in a future zlib-2.0,
and binary compatibility may be broken again. In that case, the DLL
name should become ZLIB2.DLL, etc. Tying the version number to the
library build's name is another common practice.

**

It goes like this:
There are even more problems with the "official" ZLIB.DLL currently
distributed. I am referring to the build distributed by Winimage.

  http://www.winimage.com/zLibDll

- It includes non-official code (minizip), which is indeed useful,
  but it breaks the zlib license. My complaint is not of legal
  nature (and I don't think the copyright holders, Jean-Loup and
  Mark, will sue anyone :) but it is about the implications of
  having non-official code exported from an official library build.
  See Question 11 in the ZLIB.DLL FAQ.

- The rule of thumb when making an official build is to type
  "make" (or hit the "build" button or whatever) and use an
  official make file or project file. No tweaks, no custom
  schemes or anything.
  ==OR==
  If anything is done differently, the result should still be
  practically the same as if it were done using the standard way.

  Well, Winimage's ZLIB.DLL does not conform to the latter rule,
  either. The official make file (at least in zlib-1.1.4 archive) is
  the file "nt/makefile.nt". That makefile does NOT enable the
  ZLIB_DLL macro, therefore the calling convention used, is CDECL,
  not STDCALL. Winimage's ZLIB.DLL is NOT binary compatible to the
  one that is supposed to be official, and yet it claims itself
  "official".

So far it's only theory. Now to the real problem:

The GNU-Win32 community is porting and rebuilding much of the
available open-source software under Win32, using the MinGW/GCC
compiler. There are very many ports available already, and many
established users.

  http://gnuwin32.sourceforge.net

It's no surprise that zlib has its own port, too. Well, believe it
or not, it is not compatible to the Winimage's ZLIB.DLL, but to
the one built by "nt/makefile.nt". Moreover, it includes only
official zlib code, no extras (so it complies to the zlib license).
It has a few quirks, such as it links to MSVCRT.DLL instead of
the static lib ("nt/makefile.nt" links it to the static lib), and
the export ordinals in the .DEF file are different (which is not
much of a problem, because ordinals are ignored by Windows if the
export names are present).

I don't claim that Winimage's users are less important than
GNU-Win32 users, but it's not the other way around, either.
What do we choose?

1. Take the STDCALL path and satisfy the users of a DLL that
   is built (sorry, Gilles!) incorrectly, binary-incompatible
   with the one produced by the official makefile, non-compliant
   to the license, but otherwise claims itself "official".

2. Take the CDECL path and satisfy the users of a DLL that is
   built almost "by the book", and pretty much compatible to
   one built entirely "by the book", with the only problem
   that it is not "official".

We don't have enough grounds to punish neither the users of
Winimage's ZLIB.DLL, nor the users of GNU-Win32's ZLIB.DLL,
with our decision.

Not to mention that I found a 16-bit ZLIB.DLL lurking on the
net.

As I said, ZLIB.DLL is doomed, and we cannot help much here.
But at least we can start it fresh, and do the job properly
this time. Imagine how nice would it be to get rid of more
than half of the issues that I presented in the ZLIB.DLL FAQ.


Cosmin