[Zlib-devel] zlib 1.2.0.1 available for testing

[Cosmin Truta]

On Sun, 23 Mar 2003, Gilles Vollant wrote:

> <<Cosmin Truta wrote>>
> <<you will have to have one for static-singlethreaded, one for
> static-multithreaded, and one to link with MSVCRT.DLL. All of these are
> mutually incompatible. And I didn't mention the non-Microsoft Win32
> platforms...>>
>
> I don't agree. The way the DLL itself get the C runtime library did not
> made compatibility problem.

Well, Gilles, you may disagree with me, but you cannot disagree with a
specification. See the following text in MSDN:

"CAUTION: Do not mix static and dynamic versions of the run-time
 libraries. Having more than one copy of the run-time libraries in a
 process can cause problems, because static data in one copy is not
 shared with the other copy. The linker prevents you from linking with
 both static and dynamic versions within one .exe file, but you can
 still end up with two (or more) copies of the run-time libraries. For
 example, a dynamic-link library linked with the static (non-DLL)
 versions of the run-time libraries can cause problems when used with an
 .exe file that was linked with the dynamic (DLL) version of the
 run-time libraries. (You should also avoid mixing the debug and
 non-debug versions of the libraries in one process.)"

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.MD.2c_2f.ML.2c_2f.MT.2c_2f.LD.asp

In fact, it's not hard to imagine: some CRTL functions may have internal
variables that are not mutually compatible: every library has its own
internals that do not interact, when they probably should. Furthermore,
there is a notable difference between the implementation of the
single-threaded and the multi-threaded library.

I believe you when you say that you tested various combinations and
noticed that they work. But you also have to believe me that I run into
trouble because of this reason. Figuring out what's the problem, was so
time consuming and not fun (you don't have a clue what's happening, all
you can see is crashes...)

This is one of those cases where "It Works For Me (TM)" is even more
problematic than not working at all, because the evil is at large and
you don't know it.


> Just for info, my zlib.dll uses C runtime from CRTDLL.DLL (an old DLL
> with C Runtime, found in all version of Win32).
> I don't make a DLL that need   MSVCRT.DLL or MSVCRT70.DLL because somes
> users don't have these DLL

CRTDLL.DLL may be found in all Win32, but it has a bunch of problems
(thread-unsafety is the biggest one, I think), and both Microsoft and
MinGW abandoned it; Microsoft even discourages its use, they only supply
it for backwards compatibility.

Linking to a static lib is not a good approach because ZLIB.DLL becomes
big. If one is not so interested in space savings, then one wouldn't
use the DLL in the first place.

For example, ZLIB.DLL supplied by Mozilla links to MSVCRT.DLL, so is the
one supplied by MinGW.

The presence of MSVCRT.DLL, on the other hand, is not really so
problematic. The only OS that doesn't have it is Win95 (and WinNT 3.51,
but that one is out of question anyway because the apps linked with the
newer linker require WinVer 4.0 and refuse to run on WinNT 3.51).
Whoever installs Internet Explorer, or any Windows service pack, is
guaranteed to have MSVCRT.DLL. So you shouldn't worry about those Win95
users who didn't install any service release (not even a newer IE),
because those users don't even have a Y2K-compliant system, not to
mention the security fixes. I doubt that serious users of a pristine
Win95 still exist.


Gilles wrote:

> There is another question for contrib/minizip : with your source, I
> need add "#define ZLIB_INTERNAL" on zip.c and unzip.c before include
> zlib.h to have no "definition of dllimport function not allowed" error
> at each function.
>
> Pehaps the solution is give the same status for minizip than gzio : a
> part of zlib itself, (or an optional part that uses internal thing).

Well, ZLIB_INTERNAL really means "this source file is part of zlib".
Normal users should not employ it.

So it's not a good idea to put minizip in ZLIB.DLL. From the text in
contrib/README.contrib, it can be clearly inferred that whatever is in
the contrib/ directory, is not a part of zlib.

According to the zlib license, if you hook any unofficial piece of code
into a binary build of zlib, it means that you are building an "altered
version", and you must clearly state that the build is actually an
alteration. You cannot claim that it's an official build.
Preferably, you should even use a private name, different than ZLIB.DLL.

So if you want to build a ZLIB.DLL with minizip inside, minizip has to
become an official part of zlib first (perhaps we can have a separate
discussion about this issue, on this list).

FYI: Info-ZIP maintains dll versions of zip and unzip, with full
functionality, including the support 3rd party zip fields.


Best regards,
Cosmin