README.DOS

Some notes about the supplied MSDOS executables and their compilers:

A) The 32-bit DOS executable zip32.exe was compiled with DJGPP v 2.01.
   It requires a DPMI server to run, e.g.: a DOS command prompt window
   under WINDOWS 3.x or Windows 95.  To use this program under plain DOS,
   you should install the free (GPL'ed) DPMI server CWSDPMI.EXE.  Look
   for "csdpmi4b.zip" under "simtelnet/gnu/djgpp/v2misc/" on the SimTelNet
   home site "ftp.cdrom.com" or any mirror site of the SimtelNet archive.

B) There are two 16-bit MSDOS executables provided in zcr22x.zip:
     zip.exe    :  regular Zip program, requires 452 KBytes of contiguous
                   free DOS memory or more.
     zip-sm.exe :  a variant that was compiled with the SMALL_MEM option
                   for minimal memory consumption; requires at minimum
                   320 KBytes of contiguous free DOS memory.

   The SMALL_MEM variant requires much less space for the compression
   buffers, but at the cost of some compression efficiency.
   Therefore, we recommend to use the "SMALL_MEM" 16-bit "zip-sm.exe" only
   in case of "out of memory" problems (DOS memory is low and/or very large
   number of archive entries), when the 32-bit program cannot be used for
   some reason (286 or older; no DPMI server; ...).

C) Hard limits of the Zip archive format:
   Number of entries in Zip archive:            64 k (2^16 - 1 entries)
   Compressed size of archive entry:            4 GByte (2^32 - 1 Bytes)
   Uncompressed size of entry:                  4 GByte (2^32 - 1 Bytes)
   Size of single-volume Zip archive:           4 GByte (2^32 - 1 Bytes)
   Per-volume size of multi-volume archives:    4 GByte (2^32 - 1 Bytes)
   Number of parts for multi-volume archives:   64 k (1^16 - 1 parts)
   Total size of multi-volume archive:          256 TByte (4G * 64k)

   The number of archive entries and of multivolume parts are limited by
   the structure of the "end-of-central-directory" record, where the these
   numbers are stored in 2-Byte fields.

   Length of an archive entry name:             64 kByte (2^16 - 1)
   Length of archive member comment:            64 kByte (2^16 - 1)
   Total length of "extra field":               64 kByte (2^16 - 1)
   Length of a single e.f. block:               64 kByte (2^16 - 1)
   Length of archive comment:                   64 KByte (2^16 - 1)

   Additional limitation claimed by PKWARE:
     Size of local-header structure (fixed fields of 30 Bytes + filename
      local extra field):                     < 64 kByte
     Size of central-directory structure (46 Bytes + filename +
      central extra field + member comment):  < 64 kByte

D) Implementation limits of the Zip executables:

 1. Size limits caused by file I/O and compression handling:
   Size of Zip archive:                 2 GByte (2^31 - 1 Bytes)
   Compressed size of archive entry:    2 GByte (2^31 - 1 Bytes)
   Uncompressed size of entry:          2 GByte (2^31 - 1 Bytes),
                                        (could/should be 4 GBytes...)
   Multi-volume archive creation is not supported.

 2. Limits caused by handling of archive contents lists

 2.1. Number of archive entries (freshen, update, delete)
     a) 16-bit executable:              64k (2^16 -1) or 32k (2^15 - 1),
                                        (unsigned vs. signed type of size_t)
     a1) 16-bit executable:             <16k ((2^16)/4)
         (The smaller limit a1) results from the array size limit of
         the "qsort()" function.)

     b) stack space needed by qsort to sort list of archive entries

     NOTE: In the current executables, overflows of limits a) and b) are NOT
           checked!

     c) amount of free memory to hold "central directory information" of
        all archive entries; one entry needs:
        96 bytes (32-bit) resp. 80 bytes (16-bit)
        + 3 * length of entry name
        + length of zip entry comment (when present)
        + length of extra field(s) (when present, e.g.: UT needs 9 bytes)
        + some bytes for book-keeping of memory allocation

     Conclusion:
     In most cases, the number of archive entries is limited by condition c).
     With approx. 100 kBytes of free memory after loading and initializing
     the program, a 16-bit DOS Zip cannot process more than 600 to 1000 (+)
     archive entries. (For the 16-bit Windows DLL, limit c) is less important
     because Windows executables are not restricted to the 1024k area of real
     mode memory. The 16-bit Windows Zip is limited by conditions a1) and b),
     say: at maximum approx. 16000 entries!)


 2.2. Number of "new" entries (add operation)
     In addition to the restrictions above (2.1.), the following limits
     caused by the handling of the "new files" list apply:

     a) 16-bit executable:              <16k ((2^64)/4)

     b) stack size required for "qsort" operation on "new entries" list.

     NOTE: In the current executables, the overflow checks for these limits
           are missing!

     c) amount of free memory to hold the directory info list for new entries;
        one entry needs:
        24 bytes (32-bit) resp. 22 bytes (16-bit)
        + 3 * length of filename


Please report any problems to:  Zip-Bugs@lists.wku.edu

Last updated:  26 April 1998