gosu 0.7.16 → 0.7.17

data/dependencies/zlib/trees.h

@@ -1,128 +0,0 @@
-/* header created automatically with -DGEN_TREES_H */
-
-local const ct_data static_ltree[L_CODES+2] = {
-{{ 12},{  8}}, {{140},{  8}}, {{ 76},{  8}}, {{204},{  8}}, {{ 44},{  8}},
-{{172},{  8}}, {{108},{  8}}, {{236},{  8}}, {{ 28},{  8}}, {{156},{  8}},
-{{ 92},{  8}}, {{220},{  8}}, {{ 60},{  8}}, {{188},{  8}}, {{124},{  8}},
-{{252},{  8}}, {{  2},{  8}}, {{130},{  8}}, {{ 66},{  8}}, {{194},{  8}},
-{{ 34},{  8}}, {{162},{  8}}, {{ 98},{  8}}, {{226},{  8}}, {{ 18},{  8}},
-{{146},{  8}}, {{ 82},{  8}}, {{210},{  8}}, {{ 50},{  8}}, {{178},{  8}},
-{{114},{  8}}, {{242},{  8}}, {{ 10},{  8}}, {{138},{  8}}, {{ 74},{  8}},
-{{202},{  8}}, {{ 42},{  8}}, {{170},{  8}}, {{106},{  8}}, {{234},{  8}},
-{{ 26},{  8}}, {{154},{  8}}, {{ 90},{  8}}, {{218},{  8}}, {{ 58},{  8}},
-{{186},{  8}}, {{122},{  8}}, {{250},{  8}}, {{  6},{  8}}, {{134},{  8}},
-{{ 70},{  8}}, {{198},{  8}}, {{ 38},{  8}}, {{166},{  8}}, {{102},{  8}},
-{{230},{  8}}, {{ 22},{  8}}, {{150},{  8}}, {{ 86},{  8}}, {{214},{  8}},
-{{ 54},{  8}}, {{182},{  8}}, {{118},{  8}}, {{246},{  8}}, {{ 14},{  8}},
-{{142},{  8}}, {{ 78},{  8}}, {{206},{  8}}, {{ 46},{  8}}, {{174},{  8}},
-{{110},{  8}}, {{238},{  8}}, {{ 30},{  8}}, {{158},{  8}}, {{ 94},{  8}},
-{{222},{  8}}, {{ 62},{  8}}, {{190},{  8}}, {{126},{  8}}, {{254},{  8}},
-{{  1},{  8}}, {{129},{  8}}, {{ 65},{  8}}, {{193},{  8}}, {{ 33},{  8}},
-{{161},{  8}}, {{ 97},{  8}}, {{225},{  8}}, {{ 17},{  8}}, {{145},{  8}},
-{{ 81},{  8}}, {{209},{  8}}, {{ 49},{  8}}, {{177},{  8}}, {{113},{  8}},
-{{241},{  8}}, {{  9},{  8}}, {{137},{  8}}, {{ 73},{  8}}, {{201},{  8}},
-{{ 41},{  8}}, {{169},{  8}}, {{105},{  8}}, {{233},{  8}}, {{ 25},{  8}},
-{{153},{  8}}, {{ 89},{  8}}, {{217},{  8}}, {{ 57},{  8}}, {{185},{  8}},
-{{121},{  8}}, {{249},{  8}}, {{  5},{  8}}, {{133},{  8}}, {{ 69},{  8}},
-{{197},{  8}}, {{ 37},{  8}}, {{165},{  8}}, {{101},{  8}}, {{229},{  8}},
-{{ 21},{  8}}, {{149},{  8}}, {{ 85},{  8}}, {{213},{  8}}, {{ 53},{  8}},
-{{181},{  8}}, {{117},{  8}}, {{245},{  8}}, {{ 13},{  8}}, {{141},{  8}},
-{{ 77},{  8}}, {{205},{  8}}, {{ 45},{  8}}, {{173},{  8}}, {{109},{  8}},
-{{237},{  8}}, {{ 29},{  8}}, {{157},{  8}}, {{ 93},{  8}}, {{221},{  8}},
-{{ 61},{  8}}, {{189},{  8}}, {{125},{  8}}, {{253},{  8}}, {{ 19},{  9}},
-{{275},{  9}}, {{147},{  9}}, {{403},{  9}}, {{ 83},{  9}}, {{339},{  9}},
-{{211},{  9}}, {{467},{  9}}, {{ 51},{  9}}, {{307},{  9}}, {{179},{  9}},
-{{435},{  9}}, {{115},{  9}}, {{371},{  9}}, {{243},{  9}}, {{499},{  9}},
-{{ 11},{  9}}, {{267},{  9}}, {{139},{  9}}, {{395},{  9}}, {{ 75},{  9}},
-{{331},{  9}}, {{203},{  9}}, {{459},{  9}}, {{ 43},{  9}}, {{299},{  9}},
-{{171},{  9}}, {{427},{  9}}, {{107},{  9}}, {{363},{  9}}, {{235},{  9}},
-{{491},{  9}}, {{ 27},{  9}}, {{283},{  9}}, {{155},{  9}}, {{411},{  9}},
-{{ 91},{  9}}, {{347},{  9}}, {{219},{  9}}, {{475},{  9}}, {{ 59},{  9}},
-{{315},{  9}}, {{187},{  9}}, {{443},{  9}}, {{123},{  9}}, {{379},{  9}},
-{{251},{  9}}, {{507},{  9}}, {{  7},{  9}}, {{263},{  9}}, {{135},{  9}},
-{{391},{  9}}, {{ 71},{  9}}, {{327},{  9}}, {{199},{  9}}, {{455},{  9}},
-{{ 39},{  9}}, {{295},{  9}}, {{167},{  9}}, {{423},{  9}}, {{103},{  9}},
-{{359},{  9}}, {{231},{  9}}, {{487},{  9}}, {{ 23},{  9}}, {{279},{  9}},
-{{151},{  9}}, {{407},{  9}}, {{ 87},{  9}}, {{343},{  9}}, {{215},{  9}},
-{{471},{  9}}, {{ 55},{  9}}, {{311},{  9}}, {{183},{  9}}, {{439},{  9}},
-{{119},{  9}}, {{375},{  9}}, {{247},{  9}}, {{503},{  9}}, {{ 15},{  9}},
-{{271},{  9}}, {{143},{  9}}, {{399},{  9}}, {{ 79},{  9}}, {{335},{  9}},
-{{207},{  9}}, {{463},{  9}}, {{ 47},{  9}}, {{303},{  9}}, {{175},{  9}},
-{{431},{  9}}, {{111},{  9}}, {{367},{  9}}, {{239},{  9}}, {{495},{  9}},
-{{ 31},{  9}}, {{287},{  9}}, {{159},{  9}}, {{415},{  9}}, {{ 95},{  9}},
-{{351},{  9}}, {{223},{  9}}, {{479},{  9}}, {{ 63},{  9}}, {{319},{  9}},
-{{191},{  9}}, {{447},{  9}}, {{127},{  9}}, {{383},{  9}}, {{255},{  9}},
-{{511},{  9}}, {{  0},{  7}}, {{ 64},{  7}}, {{ 32},{  7}}, {{ 96},{  7}},
-{{ 16},{  7}}, {{ 80},{  7}}, {{ 48},{  7}}, {{112},{  7}}, {{  8},{  7}},
-{{ 72},{  7}}, {{ 40},{  7}}, {{104},{  7}}, {{ 24},{  7}}, {{ 88},{  7}},
-{{ 56},{  7}}, {{120},{  7}}, {{  4},{  7}}, {{ 68},{  7}}, {{ 36},{  7}},
-{{100},{  7}}, {{ 20},{  7}}, {{ 84},{  7}}, {{ 52},{  7}}, {{116},{  7}},
-{{  3},{  8}}, {{131},{  8}}, {{ 67},{  8}}, {{195},{  8}}, {{ 35},{  8}},
-{{163},{  8}}, {{ 99},{  8}}, {{227},{  8}}
-};
-
-local const ct_data static_dtree[D_CODES] = {
-{{ 0},{ 5}}, {{16},{ 5}}, {{ 8},{ 5}}, {{24},{ 5}}, {{ 4},{ 5}},
-{{20},{ 5}}, {{12},{ 5}}, {{28},{ 5}}, {{ 2},{ 5}}, {{18},{ 5}},
-{{10},{ 5}}, {{26},{ 5}}, {{ 6},{ 5}}, {{22},{ 5}}, {{14},{ 5}},
-{{30},{ 5}}, {{ 1},{ 5}}, {{17},{ 5}}, {{ 9},{ 5}}, {{25},{ 5}},
-{{ 5},{ 5}}, {{21},{ 5}}, {{13},{ 5}}, {{29},{ 5}}, {{ 3},{ 5}},
-{{19},{ 5}}, {{11},{ 5}}, {{27},{ 5}}, {{ 7},{ 5}}, {{23},{ 5}}
-};
-
-const uch _dist_code[DIST_CODE_LEN] = {
- 0,  1,  2,  3,  4,  4,  5,  5,  6,  6,  6,  6,  7,  7,  7,  7,  8,  8,  8,  8,
- 8,  8,  8,  8,  9,  9,  9,  9,  9,  9,  9,  9, 10, 10, 10, 10, 10, 10, 10, 10,
-10, 10, 10, 10, 10, 10, 10, 10, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11,
-11, 11, 11, 11, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12,
-12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 13, 13, 13, 13,
-13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13,
-13, 13, 13, 13, 13, 13, 13, 13, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
-14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
-14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
-14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 15, 15, 15, 15, 15, 15, 15, 15,
-15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15,
-15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15,
-15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15,  0,  0, 16, 17,
-18, 18, 19, 19, 20, 20, 20, 20, 21, 21, 21, 21, 22, 22, 22, 22, 22, 22, 22, 22,
-23, 23, 23, 23, 23, 23, 23, 23, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24,
-24, 24, 24, 24, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25,
-26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26,
-26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 27, 27, 27, 27, 27, 27, 27, 27,
-27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27,
-27, 27, 27, 27, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28,
-28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28,
-28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28,
-28, 28, 28, 28, 28, 28, 28, 28, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29,
-29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29,
-29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29,
-29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29
-};
-
-const uch _length_code[MAX_MATCH-MIN_MATCH+1]= {
- 0,  1,  2,  3,  4,  5,  6,  7,  8,  8,  9,  9, 10, 10, 11, 11, 12, 12, 12, 12,
-13, 13, 13, 13, 14, 14, 14, 14, 15, 15, 15, 15, 16, 16, 16, 16, 16, 16, 16, 16,
-17, 17, 17, 17, 17, 17, 17, 17, 18, 18, 18, 18, 18, 18, 18, 18, 19, 19, 19, 19,
-19, 19, 19, 19, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
-21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 22, 22, 22, 22,
-22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 23, 23, 23, 23, 23, 23, 23, 23,
-23, 23, 23, 23, 23, 23, 23, 23, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24,
-24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24, 24,
-25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25,
-25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 25, 26, 26, 26, 26, 26, 26, 26, 26,
-26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26, 26,
-26, 26, 26, 26, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27,
-27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 27, 28
-};
-
-local const int base_length[LENGTH_CODES] = {
-0, 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 14, 16, 20, 24, 28, 32, 40, 48, 56,
-64, 80, 96, 112, 128, 160, 192, 224, 0
-};
-
-local const int base_dist[D_CODES] = {
-    0,     1,     2,     3,     4,     6,     8,    12,    16,    24,
-   32,    48,    64,    96,   128,   192,   256,   384,   512,   768,
- 1024,  1536,  2048,  3072,  4096,  6144,  8192, 12288, 16384, 24576
-};
-

data/dependencies/zlib/uncompr.c

@@ -1,61 +0,0 @@
-/* uncompr.c -- decompress a memory buffer
- * Copyright (C) 1995-2003 Jean-loup Gailly.
- * For conditions of distribution and use, see copyright notice in zlib.h
- */
-
-/* @(#) $Id$ */
-
-#define ZLIB_INTERNAL
-#include "zlib.h"
-
-/* ===========================================================================
-     Decompresses the source buffer into the destination buffer.  sourceLen is
-   the byte length of the source buffer. Upon entry, destLen is the total
-   size of the destination buffer, which must be large enough to hold the
-   entire uncompressed data. (The size of the uncompressed data must have
-   been saved previously by the compressor and transmitted to the decompressor
-   by some mechanism outside the scope of this compression library.)
-   Upon exit, destLen is the actual size of the compressed buffer.
-     This function can be used to decompress a whole file at once if the
-   input file is mmap'ed.
-
-     uncompress returns Z_OK if success, Z_MEM_ERROR if there was not
-   enough memory, Z_BUF_ERROR if there was not enough room in the output
-   buffer, or Z_DATA_ERROR if the input data was corrupted.
-*/
-int ZEXPORT uncompress (dest, destLen, source, sourceLen)
-    Bytef *dest;
-    uLongf *destLen;
-    const Bytef *source;
-    uLong sourceLen;
-{
-    z_stream stream;
-    int err;
-
-    stream.next_in = (Bytef*)source;
-    stream.avail_in = (uInt)sourceLen;
-    /* Check for source > 64K on 16-bit machine: */
-    if ((uLong)stream.avail_in != sourceLen) return Z_BUF_ERROR;
-
-    stream.next_out = dest;
-    stream.avail_out = (uInt)*destLen;
-    if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR;
-
-    stream.zalloc = (alloc_func)0;
-    stream.zfree = (free_func)0;
-
-    err = inflateInit(&stream);
-    if (err != Z_OK) return err;
-
-    err = inflate(&stream, Z_FINISH);
-    if (err != Z_STREAM_END) {
-        inflateEnd(&stream);
-        if (err == Z_NEED_DICT || (err == Z_BUF_ERROR && stream.avail_in == 0))
-            return Z_DATA_ERROR;
-        return err;
-    }
-    *destLen = stream.total_out;
-
-    err = inflateEnd(&stream);
-    return err;
-}

data/dependencies/zlib/win32/DLL_FAQ.txt

@@ -1,397 +0,0 @@
-
-            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.
-
-**
-
-This document is written and maintained by
-Cosmin Truta <cosmint@cs.ubbcluj.ro>