[Zlib-devel] Problem with ZLIB1.DLL and Visual C++ .Net

[Cosmin Truta]

[Note: Although I wrote this message before Mark's announcement, I am
sending it only now. If you agree with its contents, perhaps I will put
the updated DLL_FAQ in the DLL distribution only, accompanied by a note
stating that this FAQ is more up to date.]


Hi,

Although Andrei Polushin raised rather radical demands regarding the DLL
interface of zlib (to which I will respond separately, later), there is
something of interest in his request: the support for VC7 (.Net).

The trouble (which I discovered only this week) is that the C runtime
that comes with VC7 (that is, MSVCR70.DLL for VC7.0 and MSVCR71.DLL for
VC7.1) is no longer considered a system component. Applications should
not assume that these DLLs reside in the SYSTEM or SYSTEM32 directory,
nor should they install the DLLs in there. Instead, they should install
the DLLs in their private directories.

See the Microsoft Knowledge Base article KB326922 "INFO: Redistribution
of the Shared C Runtime Component in Visual C++ .NET":

  http://support.microsoft.com/default.aspx?scid=kb;en-us;326922

Since ZLIB1.DLL is designed as a shared, system component, it may not
depend on a private, non-system runtime, such as MSVCRT7[01].DLL.
This is quite unfortunate, and the best solution that I'm seeing so far
is not to use ZLIB1.DLL at all in VC7, unless the user has access to
the library of VC6 or earlier. Otherwise, zlib should be used as a
static lib; or, if dynamic loading is required, zlib should be built as
a private DLL, with different naming conventions, as if it would depend
on any other non-Microsoft runtime (Borland's, Cygwin's, etc.)

I propose to change the DLL_FAQ as follows: update the answer to Q12
(which is no longer accurate), shift all questions from Q13 on by one,
and insert a new Q13 about this particular VC7 issue. The quotes are
below. Note that the recommendation stated in the old Q13/new Q14 about
private builds of zlib, is consistent with Microsoft's recommendation
regarding MSVCR7[01].DLL.


12. Why are you not linking ZLIB1.DLL to
    <<my favorite C run-time library>> ?

  - We considered and abandoned the following alternatives:

    * [...]

    * Linking ZLIB1.DLL to MSVCR70.DLL or MSVCR71.DLL, supplied
      with the Microsoft .Net platform, and Visual C++ 7.0/7.1,
      raises problems related to the status of ZLIB1.DLL as a
      system component.  According to the Microsoft Knowledge Base
      article KB326922 "INFO: Redistribution of the Shared C
      Runtime Component in Visual C++ .NET", MSVCR70.DLL and
      MSVCR71.DLL are not supposed to function as system DLLs,
      because they may clash with MSVCRT.DLL.  Instead, the
      application's installer is supposed to put these DLLs
      (if needed) in the application's private directory.
      If ZLIB1.DLL depends on a non-system runtime, it cannot
      function as a redistributable system component.

    * Linking ZLIB1.DLL to non-Microsoft runtimes, such as
      Borland's, or Cygwin's, raises problems related to the
      reliable presence of these runtimes on Win32 systems.
      It's easier to let the DLL build of zlib up to the people
      who distribute these runtimes, and who may proceed as
      explained in the answer to Question 14.


13. If ZLIB1.DLL cannot be linked to MSVCR70.DLL or MSVCR71.DLL,
    how can I build/use ZLIB1.DLL in Microsoft Visual C++ 7.0
    (Visual Studio .Net) or newer?

  - Due to the problems explained in the Microsoft Knowledge Base
    article KB326922 (see the previous answer), the C runtime that
    comes with the VC7 environment is no longer considered a
    system component.  That is, it should not be assumed that this
    runtime exists, or may be installed in a system directory.
    Since ZLIB1.DLL is supposed to be a system component, it may
    not depend on a non-system component.

    In order to link ZLIB1.DLL and your application to MSVCRT.DLL
    in VC7, you need the library of Visual C++ 6.0 or older.  If
    you don't have this library at hand, it's probably best not to
    use ZLIB1.DLL.

    We are hoping that, in the future, Microsoft will provide a
    way to build applications linked to a proper system runtime,
    from the Visual C++ environment.  Until then, you have a
    couple of alternatives, such as linking zlib in statically.
    If your application requires dynamic linking, you may proceed
    as explained in the answer to Question 14.


[Q14 is the former Q13]
14. I need to link my own DLL build to a CRT different than
    MSVCRT.DLL.  What can I do?

  - Feel free to rebuild the DLL from the zlib sources, and link
    it the way you want.  You should, however, clearly state that
    your build is unofficial.  You should give it a different file
    name, and/or install it in a private directory that can be
    accessed by your application only, and is not visible to the
    others (e.g. it's not in the SYSTEM or the SYSTEM32 directory,
    and it's not in the PATH).  Otherwise, your build may clash
    with applications that link to the official build.

    For example, in Cygwin, zlib is linked to the Cygwin runtime
    CYGWIN1.DLL, and it is distributed under the name CYGZ.DLL.


[Q15 is the former Q14]
15. [...]


**

Best regards,
Cosmin