zlibのインストール

Zlibパッケージをインストールすると、各種プログラムで使用できる圧縮・伸張 (解凍) を行う関数が使えます。

Zlibをインストールするには、公式サイトよりzlibソースファイルをダウンロードします。

zlib公式サイト

コマンド(ターミナル)より直接ダウンロードする場合はURLを調べて、wgetコマンドを実行します。

ダウンロード

wget http://www.zlib.net/zlib-1.2.3.tar.gz

ダウンロードしたファイルが正しいものかどうか検証するには次のコマンドを実行します。 

md5sum zlib-1.2.3.tar.gz

これがダウンロードリンクにあるmd5チェックサムと一致するかを確認します。

解凍

ダウンロードしたファイルは圧縮されいてるため、そのままではインストールできません。

一般的には、/usr/local/srcに解凍します。
解凍後は解凍されたディレクトリに移動します。

tar zxvf zlib-1.2.3.tar.gz -C /usr/local/src
cd /usr/local/src/zlib-1.2.3/

インストール

使用したい設定にあわせてconfigureオプションを指定し、makeでビルド、make installで実行します。

make clean
./configure --shared --libdir=/lib
make
make install

共有ライブラリに入れるには下記のオプションでも可能です。

./configure -s

インストールされるライブラリ

  • libz.a
  • libz.so

ライセンスなど

 (C) 1995-2004 Jean-loup Gailly and Mark Adler

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
     claim that you wrote the original software. If you use this software
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

ソースファイルについているFAQ

                Frequently Asked Questions about zlib


If your question is not there, please check the zlib home page
http://www.zlib.org which may have more recent information.
The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html


 1. Is zlib Y2K-compliant?

    Yes. zlib doesn't handle dates.

 2. Where can I get a Windows DLL version?

    The zlib sources can be compiled without change to produce a DLL.
    See the file win32/DLL_FAQ.txt in the zlib distribution.
    Pointers to the precompiled DLL are found in the zlib web site at
    http://www.zlib.org.

 3. Where can I get a Visual Basic interface to zlib?

    See
        * http://www.dogma.net/markn/articles/zlibtool/zlibtool.htm
        * contrib/visual-basic.txt in the zlib distribution
        * win32/DLL_FAQ.txt in the zlib distribution

 4. compress() returns Z_BUF_ERROR.

    Make sure that before the call of compress, the length of the compressed
    buffer is equal to the total size of the compressed buffer and not
    zero. For Visual Basic, check that this parameter is passed by reference
    ("as any"), not by value ("as long").

 5. deflate() or inflate() returns Z_BUF_ERROR.

    Before making the call, make sure that avail_in and avail_out are not
    zero. When setting the parameter flush equal to Z_FINISH, also make sure
    that avail_out is big enough to allow processing all pending input.
    Note that a Z_BUF_ERROR is not fatal--another call to deflate() or
    inflate() can be made with more input or output space. A Z_BUF_ERROR
    may in fact be unavoidable depending on how the functions are used, since
    it is not possible to tell whether or not there is more output pending
    when strm.avail_out returns with zero.

 6. Where's the zlib documentation (man pages, etc.)?

    It's in zlib.h for the moment, and Francis S. Lin has converted it to a
    web page zlib.html. Volunteers to transform this to Unix-style man pages,
    please contact us (zlib@gzip.org). Examples of zlib usage are in the files
    example.c and minigzip.c.

 7. Why don't you use GNU autoconf or libtool or ...?

    Because we would like to keep zlib as a very small and simple
    package. zlib is rather portable and doesn't need much configuration.

 8. I found a bug in zlib.

    Most of the time, such problems are due to an incorrect usage of
    zlib. Please try to reproduce the problem with a small program and send
    the corresponding source to us at zlib@gzip.org . Do not send
    multi-megabyte data files without prior agreement.

 9. Why do I get "undefined reference to gzputc"?

    If "make test" produces something like

       example.o(.text+0x154): undefined reference to `gzputc'

    check that you don't have old files libz.* in /usr/lib, /usr/local/lib or
    /usr/X11R6/lib. Remove any old versions, then do "make install".

10. I need a Delphi interface to zlib.

    See the contrib/delphi directory in the zlib distribution.

11. Can zlib handle .zip archives?

    Not by itself, no.  See the directory contrib/minizip in the zlib
    distribution.

12. Can zlib handle .Z files?

    No, sorry. You have to spawn an uncompress or gunzip subprocess, or adapt
    the code of uncompress on your own.

13. How can I make a Unix shared library?

    make clean
    ./configure -s
    make

14. How do I install a shared zlib library on Unix?

    After the above, then:

    make install

    However, many flavors of Unix come with a shared zlib already installed.
    Before going to the trouble of compiling a shared version of zlib and
    trying to install it, you may want to check if it's already there! If you
    can #include <zlib.h>, it's there. The -lz option will probably link to it.

15. I have a question about OttoPDF.

    We are not the authors of OttoPDF. The real author is on the OttoPDF web
    site: Joel Hainley, jhainley@myndkryme.com.

16. Can zlib decode Flate data in an Adobe PDF file?

    Yes. See http://www.fastio.com/ (ClibPDF), or http://www.pdflib.com/ .
    To modify PDF forms, see http://sourceforge.net/projects/acroformtool/ .

17. Why am I getting this "register_frame_info not found" error on Solaris?

    After installing zlib 1.1.4 on Solaris 2.6, running applications using zlib
    generates an error such as:

        ld.so.1: rpm: fatal: relocation error: file /usr/local/lib/libz.so:
        symbol __register_frame_info: referenced symbol not found

    The symbol __register_frame_info is not part of zlib, it is generated by
    the C compiler (cc or gcc). You must recompile applications using zlib
    which have this problem. This problem is specific to Solaris. See
    http://www.sunfreeware.com for Solaris versions of zlib and applications
    using zlib.

18. Why does gzip give an error on a file I make with compress/deflate?

    The compress and deflate functions produce data in the zlib format, which
    is different and incompatible with the gzip format. The gz* functions in
    zlib on the other hand use the gzip format. Both the zlib and gzip
    formats use the same compressed data format internally, but have different
    headers and trailers around the compressed data.

19. Ok, so why are there two different formats?

    The gzip format was designed to retain the directory information about
    a single file, such as the name and last modification date. The zlib
    format on the other hand was designed for in-memory and communication
    channel applications, and has a much more compact header and trailer and
    uses a faster integrity check than gzip.

20. Well that's nice, but how do I make a gzip file in memory?

    You can request that deflate write the gzip format instead of the zlib
    format using deflateInit2(). You can also request that inflate decode
    the gzip format using inflateInit2(). Read zlib.h for more details.

21. Is zlib thread-safe?

    Yes. However any library routines that zlib uses and any application-
    provided memory allocation routines must also be thread-safe. zlib's gz*
    functions use stdio library routines, and most of zlib's functions use the
    library memory allocation routines by default. zlib's Init functions allow
    for the application to provide custom memory allocation routines.

    Of course, you should only operate on any given zlib or gzip stream from a
    single thread at a time.

22. Can I use zlib in my commercial application?

    Yes. Please read the license in zlib.h.

23. Is zlib under the GNU license?

    No. Please read the license in zlib.h.

24. The license says that altered source versions must be "plainly marked". So
    what exactly do I need to do to meet that requirement?

    You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h. In
    particular, the final version number needs to be changed to "f", and an
    identification string should be appended to ZLIB_VERSION. Version numbers
    x.x.x.f are reserved for modifications to zlib by others than the zlib
    maintainers. For example, if the version of the base zlib you are altering
    is "1.2.3.4", then in zlib.h you should change ZLIB_VERNUM to 0x123f, and
    ZLIB_VERSION to something like "1.2.3.f-zachary-mods-v3". You can also
    update the version strings in deflate.c and inftrees.c.

    For altered source distributions, you should also note the origin and
    nature of the changes in zlib.h, as well as in ChangeLog and README, along
    with the dates of the alterations. The origin should include at least your
    name (or your company's name), and an email address to contact for help or
    issues with the library.

    Note that distributing a compiled zlib library along with zlib.h and
    zconf.h is also a source distribution, and so you should change
    ZLIB_VERSION and ZLIB_VERNUM and note the origin and nature of the changes
    in zlib.h as you would for a full source distribution.

25. Will zlib work on a big-endian or little-endian architecture, and can I
    exchange compressed data between them?

    Yes and yes.

26. Will zlib work on a 64-bit machine?

    It should. It has been tested on 64-bit machines, and has no dependence
    on any data types being limited to 32-bits in length. If you have any
    difficulties, please provide a complete problem report to zlib@gzip.org

27. Will zlib decompress data from the PKWare Data Compression Library?

    No. The PKWare DCL uses a completely different compressed data format
    than does PKZIP and zlib. However, you can look in zlib's contrib/blast
    directory for a possible solution to your problem.

28. Can I access data randomly in a compressed stream?

    No, not without some preparation. If when compressing you periodically
    use Z_FULL_FLUSH, carefully write all the pending data at those points,
    and keep an index of those locations, then you can start decompression
    at those points. You have to be careful to not use Z_FULL_FLUSH too
    often, since it can significantly degrade compression.

29. Does zlib work on MVS, OS/390, CICS, etc.?

    We don't know for sure. We have heard occasional reports of success on
    these systems. If you do use it on one of these, please provide us with
    a report, instructions, and patches that we can reference when we get
    these questions. Thanks.

30. Is there some simpler, easier to read version of inflate I can look at
    to understand the deflate format?

    First off, you should read RFC 1951. Second, yes. Look in zlib's
    contrib/puff directory.

31. Does zlib infringe on any patents?

    As far as we know, no. In fact, that was originally the whole point behind
    zlib. Look here for some more information:

    http://www.gzip.org/#faq11

32. Can zlib work with greater than 4 GB of data?

    Yes. inflate() and deflate() will process any amount of data correctly.
    Each call of inflate() or deflate() is limited to input and output chunks
    of the maximum value that can be stored in the compiler's "unsigned int"
    type, but there is no limit to the number of chunks. Note however that the
    strm.total_in and strm_total_out counters may be limited to 4 GB. These
    counters are provided as a convenience and are not used internally by
    inflate() or deflate(). The application can easily set up its own counters
    updated after each call of inflate() or deflate() to count beyond 4 GB.
    compress() and uncompress() may be limited to 4 GB, since they operate in a
    single call. gzseek() and gztell() may be limited to 4 GB depending on how
    zlib is compiled. See the zlibCompileFlags() function in zlib.h.

    The word "may" appears several times above since there is a 4 GB limit
    only if the compiler's "long" type is 32 bits. If the compiler's "long"
    type is 64 bits, then the limit is 16 exabytes.

33. Does zlib have any security vulnerabilities?

    The only one that we are aware of is potentially in gzprintf(). If zlib
    is compiled to use sprintf() or vsprintf(), then there is no protection
    against a buffer overflow of a 4K string space, other than the caller of
    gzprintf() assuring that the output will not exceed 4K. On the other
    hand, if zlib is compiled to use snprintf() or vsnprintf(), which should
    normally be the case, then there is no vulnerability. The ./configure
    script will display warnings if an insecure variation of sprintf() will
    be used by gzprintf(). Also the zlibCompileFlags() function will return
    information on what variant of sprintf() is used by gzprintf().

    If you don't have snprintf() or vsnprintf() and would like one, you can
    find a portable implementation here:

        http://www.ijs.si/software/snprintf/

    Note that you should be using the most recent version of zlib. Versions
    1.1.3 and before were subject to a double-free vulnerability.

34. Is there a Java version of zlib?

    Probably what you want is to use zlib in Java. zlib is already included
    as part of the Java SDK in the java.util.zip package. If you really want
    a version of zlib written in the Java language, look on the zlib home
    page for links: http://www.zlib.org/

35. I get this or that compiler or source-code scanner warning when I crank it
    up to maximally-pedantic. Can't you guys write proper code?

    Many years ago, we gave up attempting to avoid warnings on every compiler
    in the universe. It just got to be a waste of time, and some compilers
    were downright silly. So now, we simply make sure that the code always
    works.

36. Valgrind (or some similar memory access checker) says that deflate is
    performing a conditional jump that depends on an uninitialized value.
    Isn't that a bug?

    No.  That is intentional for performance reasons, and the output of
    deflate is not affected.  This only started showing up recently since
    zlib 1.2.x uses malloc() by default for allocations, whereas earlier
    versions used calloc(), which zeros out the allocated memory.

37. Will zlib read the (insert any ancient or arcane format here) compressed
    data format?

    Probably not. Look in the comp.compression FAQ for pointers to various
    formats and associated software.

38. How can I encrypt/decrypt zip files with zlib?

    zlib doesn't support encryption. The original PKZIP encryption is very weak
    and can be broken with freely available programs. To get strong encryption,
    use GnuPG, http://www.gnupg.org/ , which already includes zlib compression.
    For PKZIP compatible "encryption", look at http://www.info-zip.org/

39. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?

    "gzip" is the gzip format, and "deflate" is the zlib format. They should
    probably have called the second one "zlib" instead to avoid confusion
    with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616
    correctly points to the zlib specification in RFC 1950 for the "deflate"
    transfer encoding, there have been reports of servers and browsers that
    incorrectly produce or expect raw deflate data per the deflate
    specficiation in RFC 1951, most notably Microsoft. So even though the
    "deflate" transfer encoding using the zlib format would be the more
    efficient approach (and in fact exactly what the zlib format was designed
    for), using the "gzip" transfer encoding is probably more reliable due to
    an unfortunate choice of name on the part of the HTTP 1.1 authors.

    Bottom line: use the gzip format for HTTP 1.1 encoding.

40. Does zlib support the new "Deflate64" format introduced by PKWare?

    No. PKWare has apparently decided to keep that format proprietary, since
    they have not documented it as they have previous compression formats.
    In any case, the compression improvements are so modest compared to other
    more modern approaches, that it's not worth the effort to implement.

41. Can you please sign these lengthy legal documents and fax them back to us
    so that we can use your software in our product?

    No. Go away. Shoo.

ソースファイルについているDLLファイルについてのFAQ

            Frequently Asked Questions about ZLIB1.DLL


This document describes the design, the rationale, and the usage
of the official DLL build of zlib, named ZLIB1.DLL.  If you have
general questions about zlib, you should see the file "FAQ" found
in the zlib distribution, or at the following location:
  http://www.gzip.org/zlib/zlib_faq.html


 1. What is ZLIB1.DLL, and how can I get it?

  - ZLIB1.DLL is the official build of zlib as a DLL.
    (Please remark the character '1' in the name.)

    Pointers to a precompiled ZLIB1.DLL can be found in the zlib
    web site at:
      http://www.zlib.org/

    Applications that link to ZLIB1.DLL can rely on the following
    specification:

    * The exported symbols are exclusively defined in the source
      files "zlib.h" and "zlib.def", found in an official zlib
      source distribution.
    * The symbols are exported by name, not by ordinal.
    * The exported names are undecorated.
    * The calling convention of functions is "C" (CDECL).
    * The ZLIB1.DLL binary is linked to MSVCRT.DLL.

    The archive in which ZLIB1.DLL is bundled contains compiled
    test programs that must run with a valid build of ZLIB1.DLL.
    It is recommended to download the prebuilt DLL from the zlib
    web site, instead of building it yourself, to avoid potential
    incompatibilities that could be introduced by your compiler
    and build settings.  If you do build the DLL yourself, please
    make sure that it complies with all the above requirements,
    and it runs with the precompiled test programs, bundled with
    the original ZLIB1.DLL distribution.

    If, for any reason, you need to build an incompatible DLL,
    please use a different file name.


 2. Why did you change the name of the DLL to ZLIB1.DLL?
    What happened to the old ZLIB.DLL?

  - The old ZLIB.DLL, built from zlib-1.1.4 or earlier, required
    compilation settings that were incompatible to those used by
    a static build.  The DLL settings were supposed to be enabled
    by defining the macro ZLIB_DLL, before including "zlib.h".
    Incorrect handling of this macro was silently accepted at
    build time, resulting in two major problems:

    * ZLIB_DLL was missing from the old makefile.  When building
      the DLL, not all people added it to the build options.  In
      consequence, incompatible incarnations of ZLIB.DLL started
      to circulate around the net.

    * When switching from using the static library to using the
      DLL, applications had to define the ZLIB_DLL macro and
      to recompile all the sources that contained calls to zlib
      functions.  Failure to do so resulted in creating binaries
      that were unable to run with the official ZLIB.DLL build.

    The only possible solution that we could foresee was to make
    a binary-incompatible change in the DLL interface, in order to
    remove the dependency on the ZLIB_DLL macro, and to release
    the new DLL under a different name.

    We chose the name ZLIB1.DLL, where '1' indicates the major
    zlib version number.  We hope that we will not have to break
    the binary compatibility again, at least not as long as the
    zlib-1.x series will last.

    There is still a ZLIB_DLL macro, that can trigger a more
    efficient build and use of the DLL, but compatibility no
    longer dependents on it.


 3. Can I build ZLIB.DLL from the new zlib sources, and replace
    an old ZLIB.DLL, that was built from zlib-1.1.4 or earlier?

  - In principle, you can do it by assigning calling convention
    keywords to the macros ZEXPORT and ZEXPORTVA.  In practice,
    it depends on what you mean by "an old ZLIB.DLL", because the
    old DLL exists in several mutually-incompatible versions.
    You have to find out first what kind of calling convention is
    being used in your particular ZLIB.DLL build, and to use the
    same one in the new build.  If you don't know what this is all
    about, you might be better off if you would just leave the old
    DLL intact.


 4. Can I compile my application using the new zlib interface, and
    link it to an old ZLIB.DLL, that was built from zlib-1.1.4 or
    earlier?

  - The official answer is "no"; the real answer depends again on
    what kind of ZLIB.DLL you have.  Even if you are lucky, this
    course of action is unreliable.

    If you rebuild your application and you intend to use a newer
    version of zlib (post- 1.1.4), it is strongly recommended to
    link it to the new ZLIB1.DLL.


 5. Why are the zlib symbols exported by name, and not by ordinal?

  - Although exporting symbols by ordinal is a little faster, it
    is risky.  Any single glitch in the maintenance or use of the
    DEF file that contains the ordinals can result in incompatible
    builds and frustrating crashes.  Simply put, the benefits of
    exporting symbols by ordinal do not justify the risks.

    Technically, it should be possible to maintain ordinals in
    the DEF file, and still export the symbols by name.  Ordinals
    exist in every DLL, and even if the dynamic linking performed
    at the DLL startup is searching for names, ordinals serve as
    hints, for a faster name lookup.  However, if the DEF file
    contains ordinals, the Microsoft linker automatically builds
    an implib that will cause the executables linked to it to use
    those ordinals, and not the names.  It is interesting to
    notice that the GNU linker for Win32 does not suffer from this
    problem.

    It is possible to avoid the DEF file if the exported symbols
    are accompanied by a "__declspec(dllexport)" attribute in the
    source files.  You can do this in zlib by predefining the
    ZLIB_DLL macro.


 6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling
    convention.  Why not use the STDCALL convention?
    STDCALL is the standard convention in Win32, and I need it in
    my Visual Basic project!

    (For readability, we use CDECL to refer to the convention
     triggered by the "__cdecl" keyword, STDCALL to refer to
     the convention triggered by "__stdcall", and FASTCALL to
     refer to the convention triggered by "__fastcall".)

  - Most of the native Windows API functions (without varargs) use
    indeed the WINAPI convention (which translates to STDCALL in
    Win32), but the standard C functions use CDECL.  If a user
    application is intrinsically tied to the Windows API (e.g.
    it calls native Windows API functions such as CreateFile()),
    sometimes it makes sense to decorate its own functions with
    WINAPI.  But if ANSI C or POSIX portability is a goal (e.g.
    it calls standard C functions such as fopen()), it is not a
    sound decision to request the inclusion of <windows.h>, or to
    use non-ANSI constructs, for the sole purpose to make the user
    functions STDCALL-able.

    The functionality offered by zlib is not in the category of
    "Windows functionality", but is more like "C functionality".

    Technically, STDCALL is not bad; in fact, it is slightly
    faster than CDECL, and it works with variable-argument
    functions, just like CDECL.  It is unfortunate that, in spite
    of using STDCALL in the Windows API, it is not the default
    convention used by the C compilers that run under Windows.
    The roots of the problem reside deep inside the unsafety of
    the K&R-style function prototypes, where the argument types
    are not specified; but that is another story for another day.

    The remaining fact is that CDECL is the default convention.
    Even if an explicit convention is hard-coded into the function
    prototypes inside C headers, problems may appear.  The
    necessity to expose the convention in users' callbacks is one
    of these problems.

    The calling convention issues are also important when using
    zlib in other programming languages.  Some of them, like Ada
    (GNAT) and Fortran (GNU G77), have C bindings implemented
    initially on Unix, and relying on the C calling convention.
    On the other hand, the pre- .NET versions of Microsoft Visual
    Basic require STDCALL, while Borland Delphi prefers, although
    it does not require, FASTCALL.

    In fairness to all possible uses of zlib outside the C
    programming language, we choose the default "C" convention.
    Anyone interested in different bindings or conventions is
    encouraged to maintain specialized projects.  The "contrib/"
    directory from the zlib distribution already holds a couple
    of foreign bindings, such as Ada, C++, and Delphi.


 7. I need a DLL for my Visual Basic project.  What can I do?

  - Define the ZLIB_WINAPI macro before including "zlib.h", when
    building both the DLL and the user application (except that
    you don't need to define anything when using the DLL in Visual
    Basic).  The ZLIB_WINAPI macro will switch on the WINAPI
    (STDCALL) convention.  The name of this DLL must be different
    than the official ZLIB1.DLL.

    Gilles Vollant has contributed a build named ZLIBWAPI.DLL,
    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.

関連記事

スポンサーリンク

== 文字列を比較する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る