with the ZLIB_WINAPI macro turned on, and with the minizip    functionality built in.  For more information, please read    the notes inside "contrib/vstudio/readme.txt", found in the    zlib distribution. 8. I need to use zlib in my Microsoft .NET project.  What can I    do?  - Henrik Ravn has contributed a .NET wrapper around zlib.  Look    into contrib/dotzlib/, inside the zlib distribution. 9. If my application uses ZLIB1.DLL, should I link it to    MSVCRT.DLL?  Why?  - It is not required, but it is recommended to link your    application to MSVCRT.DLL, if it uses ZLIB1.DLL.    The executables (.EXE, .DLL, etc.) that are involved in the    same process and are using the C run-time library (i.e. they    are calling standard C functions), must link to the same    library.  There are several libraries in the Win32 system:    CRTDLL.DLL, MSVCRT.DLL, the static C libraries, etc.    Since ZLIB1.DLL is linked to MSVCRT.DLL, the executables that    depend on it should also be linked to MSVCRT.DLL.10. Why are you saying that ZLIB1.DLL and my application should    be linked to the same C run-time (CRT) library?  I linked my    application and my DLLs to different C libraries (e.g. my    application to a static library, and my DLLs to MSVCRT.DLL),    and everything works fine.  - If a user library invokes only pure Win32 API (accessible via    <windows.h> and the related headers), its DLL build will work    in any context.  But if this library invokes standard C API,    things get more complicated.    There is a single Win32 library in a Win32 system.  Every    function in this library resides in a single DLL module, that    is safe to call from anywhere.  On the other hand, there are    multiple versions of the C library, and each of them has its    own separate internal state.  Standalone executables and user    DLLs that call standard C functions must link to a C run-time    (CRT) library, be it static or shared (DLL).  Intermixing    occurs when an executable (not necessarily standalone) and a    DLL are linked to different CRTs, and both are running in the    same process.    Intermixing multiple CRTs is possible, as long as their    internal states are kept intact.  The Microsoft Knowledge Base    articles KB94248 "HOWTO: Use the C Run-Time" and KB140584    "HOWTO: Link with the Correct C Run-Time (CRT) Library"    mention the potential problems raised by intermixing.    If intermixing works for you, it's because your application    and DLLs are avoiding the corruption of each of the CRTs'    internal states, maybe by careful design, or maybe by fortune.    Also note that linking ZLIB1.DLL to non-Microsoft CRTs, such    as those provided by Borland, raises similar problems.11. Why are you linking ZLIB1.DLL to MSVCRT.DLL?  - MSVCRT.DLL exists on every Windows 95 with a new service pack    installed, or with Microsoft Internet Explorer 4 or later, and    on all other Windows 4.x or later (Windows 98, Windows NT 4,    or later).  It is freely distributable; if not present in the    system, it can be downloaded from Microsoft or from other    software provider for free.    The fact that MSVCRT.DLL does not exist on a virgin Windows 95    is not so problematic.  Windows 95 is scarcely found nowadays,    Microsoft ended its support a long time ago, and many recent    applications from various vendors, including Microsoft, do not    even run on it.  Furthermore, no serious user should run    Windows 95 without a proper update installed.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 a static C library (LIBC.LIB, or      LIBCMT.LIB) is not a good option.  People are using the DLL      mainly to save disk space.  If you are linking your program      to a static C library, you may as well consider linking zlib      in statically, too.    * Linking ZLIB1.DLL to CRTDLL.DLL looks appealing, because      CRTDLL.DLL is present on every Win32 installation.      Unfortunately, it has a series of problems: it does not      work properly with Microsoft's C++ libraries, it does not      provide support for 64-bit file offsets, (and so on...),      and Microsoft discontinued its support a long time ago.    * 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.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.15. May I include additional pieces of code that I find useful,    link them in ZLIB1.DLL, and export them?  - No.  A legitimate build of ZLIB1.DLL must not include code    that does not originate from the official zlib source code.    But you can make your own private DLL build, under a different    file name, as suggested in the previous answer.    For example, zlib is a part of the VCL library, distributed    with Borland Delphi and C++ Builder.  The DLL build of VCL    is a redistributable file, named VCLxx.DLL.16. May I remove some functionality out of ZLIB1.DLL, by enabling    macros like NO_GZCOMPRESS or NO_GZIP at compile time?  - No.  A legitimate build of ZLIB1.DLL must provide the complete    zlib functionality, as implemented in the official zlib source    code.  But you can make your own private DLL build, under a    different file name, as suggested in the previous answer.17. I made my own ZLIB1.DLL build.  Can I test it for compliance?  - We prefer that you download the official DLL from the zlib    web site.  If you need something peculiar from this DLL, you    can send your suggestion to the zlib mailing list.    However, in case you do rebuild the DLL yourself, you can run    it with the test programs found in the DLL distribution.    Running these test programs is not a guarantee of compliance,    but a failure can imply a detected problem.**This document is written and maintained byCosmin Truta <cosmint@cs.ubbcluj.ro>