      INSTALL -- Info-ZIP UnZip Installation Instructions
      ===================================================

   UnZip version 6.10.  Revised: 2013-01-26

------------------------------------------------------------------------

   On most system types, the general procedure to build and install
UnZip follows these steps:

      1. Unpack the UnZip source kit.  (Some optional features, such as
      optional compression or encryption methods, may require additional
      source kits.  Obtain and unpack any additional source kits, if
      needed.

      2. Build.  That is, compile and link the programs.  A C compiler
      and a "make" program are usually required.  Other standard utility
      programs for the build environment may also be needed.  (For
      example, on a Unix(-like) system, "cat", "chmod", "cp", "ln",
      "mkdir", "rm", "sed", and so on.)

      3. Test.  The Unix and VMS builders include a very basic test
      procedure.  Careful users should test any programs like these
      using their own data and procedures before relying on them.

      4, Install.  That is, move the executables and associated files to
      their destination directories.

   The details of these steps depend on the system type and on
user-selected options.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   For Mac OS X, follow the Unix procedures.

   For VMS instructions, see [.vms]INSTALL_VMS.txt.

   For Windows, using Cygwin or MinGW, follow the Unix procedures.

   +-------------------------------------------------------------------+
   | Many system types have a system-specific directory ("unix/",      |
   | "[.vms]", "win32\", and so on).  For any system type, look in its |
   | system-specific directory for a system-specific INSTALL*.* and/or |
   | README*.* file, which should explain any system-specific details. |
   +-------------------------------------------------------------------+

------------------------------------------------------------------------

      Unpack the Source Kit(s)
      ------------------------

   UnZip is normally distributed as a Zip archive (which requires some
kind of unzip program to unpack), or as a gzip-compressed "tar" archive
(which requires programs like "gzip" and "tar" to unpack).

   To unpack a Zip-archive kit, use a command like the following:

      unzip unzip61.zip

(But see "Source File Format", below, for details on some relevant UnZip
options.)

   To unpack a tar+gzip kit, use a command like the following:

      gzip -dc unzip61.tgz | tar xf -

This should create an "unzip61" directory which contains the UnZip
source kit, and that is where the rest of the work is done.

   Some unzip programs, such as the Extraction Wizard in Windows, may
want to add another add another "unzip61" directory above the top-level
directory in the Zip archive.  This extra, top-level directory is not
needed, and probably makes finding the archive's top-level directory
harder.  Many of the instructions below assume that you're in the
archive's main (top-level) directory, that is, the directory which
contains this INSTALL file (and many other UnZip files and directories).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Source File Format
   ------------------

   Text files in Info-ZIP source kits generally have Unix-compatible
line endings (line-feed, LF, ASCII 0x0a).  On systems like MS-DOS or
Windows, the norm is different (Carriage Return + Line Feed, CR+LF,
ASCII 0x0d+0x0a).  On those systems, some programs (text editors,
compilers, and so on) may have problems with LF line endings.  In such
situations, one solution is to use Info-ZIP UnZip with its "-a" option
to unpack the source kit.  With "-a", UnZip converts line endings in
text files to the local standard as those files are extracted.  For
example:

      unzip -a unzip61.zip

Alternatively, programs like "flip" or "unix2dos" (or Unix utilities
like "sed" or "tr") can also be used to convert text file line endings.

   Some system-specific text files in an UnZip kit, such as Visual
Studio files, may be archived with CR+LF line endings, and these files
should work on the appropriate systems whether or not "unzip -a" is used
to extract them.  (Unix users could use "unzip -a" to make it easier to
examine these files on their systems.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

      Optional Source Kits
      --------------------

   Advanced Encryption Standard (AES) Encryption
   ---------------------------------------------

   To enable support for AES encryption, a separate IZ_AES_WG source kit
is needed.  On the Info-ZIP FTP server, the IZ_AES_WG source kit should
be found in:

      ftp://ftp.info-zip.org/pub/infozip/crypt/

The latest kit should be:

      ftp://ftp.info-zip.org/pub/infozip/crypt/iz_aes_wg.zip

but other, older kits may also be available there.  Version
compatibility information should be included in the IZ_AES_WG
documentation.  The latest version of that should be:

      ftp://ftp.info-zip.org/pub/infozip/crypt/README_AES_WG.txt

It might be wise to read that before downloading any particular
IZ_AES_WG kit.

   The IZ_AES_WG kit should be unpacked in the main UnZip directory,
where it should populate the "aes_wg" subdirectory.  For example, if the
proper IZ_AES_WG kit is "iz_aes_wg10.zip", then use commands like the
following:

      cd unzip61                        # (If not already there.)
      unzip ../iz_aes_wg10.zip

   See the "Build" section, below, for details on how to build UnZip
with AES encryption support.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   Bzip2 Compression
   -----------------

   To enable support for the bzip2 compression method, the UnZip
programs must be linked with a bzip2 object library, such as "libbz2.a".
For proper error handling, the bzip2 object library should be built with
the C macro BZ_NO_STDIO defined (which is not the bzip2 default).  For
general information on bzip2 compression, or to download a bzip2 source
kit:

      http://www.bzip.org/

Any bzip2 version from 1.0.3 up should be compatible.

   The UnZip builders for Unix systems can use a pre-built (BZ_NO_STDIO)
object library, or they can build a proper bzip2 object library, if they
find bzip2 source files in the "bzip2" subdirectory of the main UnZip
directory.  To have the UnZip builders do the work, let's assume that
you have downloaded a bzip2 kit, like, say, "bzip2-1.0.6.tar.gz", and
put it in the same directory as the UnZip kit.  To unpack that kit, and
put its contents where the UnZip builders expect them, use commands like
the following:

      cd unzip61                        # (If not already there.)
      gzip -dc ../bzip2-1.0.6.tar.gz | tar xf -
      mv bzip2-1.0.6/* bzip2

   The UnZip builders will attempt to build a bzip2 object library from
sources only in the "bzip2" subdirectory of the main UnZip directory.
Existing bzip2 kits in other directory trees should be safe from damage
by UnZip builders.

   See the "Build" section, below, for details on how to build UnZip
with bzip2 compression support.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   LZMA and PPMd Compression
   -------------------------

   All the source files needed to enable support for the LZMA and PPMd
compression methods are included in the UnZip kit.

------------------------------------------------------------------------

      Build
      -----

   What Gets Built
   ---------------

   On most systems, UnZip provides three programs: fUnZip,
UnZip/ZipInfo, and UnZipSFX.  (Actual executable names depend on the
operating system, so, for example, an UnZip executable might be named
"unzip", "unzip.exe", UNZIP.EXE, and so on, on different systems.)
fUnZip is not provided on VMS, where pipeline capabilities are too
limited.  On Amiga, an additional executable, MakeSFX, is provided,
because a self-extracting archive on Amiga cannot be created by simple
concatenation ("cat", COPY), as it can on other systems.

   Various documentation files (Unix "man" files, VMS HELP files, and so
on) may also be created, if they were not already included in the kit.

   Additional shell scripts, utility programs, and so on may also reside
in system-dependent subdirectories.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   How to Build
   ------------

   Before starting the build, move into the unpacked archive's top-level
directory, using a command like the following:

      cd unzip61                        # (If not already there.)

   In many Unix or Unix-like environments, the basic build command looks
like the following:

      make -f unix/Makefile generic

but many options may be specified in the "make" command.  These are
described below.

   In some environments, where "make -f DIR/Makefile" does not work,
copy the appropriate "make" file (in the example above, "DIR/Makefile"),
into the main directory, and then use a "make" command without the "-f
DIR/Makefile" option (or without the "DIR/" part of the path to the
"make" file).

   In most Unix(-like) environments, the "generic" target (as shown
above) works best.  It uses a shell script, "unix/configure", to adjust
the build procedure to the local environment.  (It's also tested better
than the other, older "make" targets.)  If "generic" does not work, then
the "help" target should list the other possible targets (and some of
the popular "make" options):

      make -f unix/Makefile help

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Build Options for the "generic" Target
   --------------------------------------

   When using "make generic", add the "make" macros listed below to
enable the corresponding optional features:

      AES_WG=1          Enable support for WinZip-compatible AES
                        (strong) encryption.  This requires a separate
                        IZ_AES_WG source kit, as described above
                        ("Optional Source Kits").

      CC=gcc            Compile and link using "gcc" instead of "cc".
                        (This method replaces the separate "generic_gcc"
                        target, which was used with UnZip 6.0, and has
                        been removed.)

      IZ_BZIP2=bz2dir   Enable support for the bzip2 compression method.
                        "bz2dir" specifies the directory where the bzip2
                        code resides.  Use "IZ_BZIP2=bzip2" to have the
                        UnZip builders build the required bzip2 object
                        library from source files in the "bzip2"
                        subdirectory.

      IZ_ZLIB=zdir      Use zlib for the Deflate compression method,
                        instead of UnZip's internal Deflate code.
                        "zdir" specifies the directory where the zlib
                        code resides.

      LIBUNZIP=1        Build an UnZip object library.

      LOCAL_UNZIP=<opts>  Build using "<opts>" (C compiler options,
                          typically defining C macros).

      LZMA=1            Enable support for the LZMA compression method.

      PPMD=1            Enable support for the PPMd compression method.


   For example, a build command using "gcc" as the C compiler, with all
the optional compression and encryption methods enabled, might look like
the following:

      make -f unix/Makefile CC=gcc AES_WG=1 IZ_BZIP2=bzip2 \
       LZMA=1 PPMD=1 generic

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   LOCAL_UNZIP
   -----------

   Environment Variables v. "make" Macros
   --------------------------------------

   On many systems, defining an environment variable (or, on VMS, a DCL
symbol) can substitute for specifying a "make" macro on the "make"
command line.  For example, if you regularly build new versions of
UnZip, and always want the same non-standard compiler options, then you
may wish to specify those options in a LOCAL_UNZIP environment variable
(assuming that it's supported in your "make" file).  Under MS-DOS, for
example, you could add something like the following to AUTOEXEC.BAT:

      set LOCAL_UNZIP=-DDOSWILD -DDATE_FORMAT=DF_DMY

For a Bourne-like shell on a Unix(-like) system, you could add something
like the following to "~/.profile":

      LOCAL_UNZIP='-DBZIP2_SFX' ; export LOCAL_UNZIP

You could also use the variable to hold special compiler options.  For
example, -FPi87 for Microsoft C, if the x87 libraries are the only ones
on your disk and they follow Microsoft's default naming conventions.
(MSC also supports the CL environment variable, however.)

   Hiding UnZip build options this way can also cause confusion, because
it may not be obvious why some particular build option was active if
it's not specified explicitly on the "make" command line.  Creating a
shell script with the desired special options may be safer than setting
a LOCAL_UNZIP environment variable.  Also, beware of changes to these
"make" macros from one product version to another.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   Building with Bzip2 Compression
   -------------------------------

   The Unix and VMS builders for UnZip can use a bzip2 source kit which
has been placed in the "bzip2" subdirectory of the main UnZip directory,
as described above ("Optional Source Kits").  Users who regularly work
with multiple UnZip versions can avoid duplicating the bzip2 code by
manually building a bzip2 object library ("libbz2.a" on Unix) with
BZ_NO_STDIO defined, in some common location.  Then, when building
UnZip, specify that bzip2 directory as the value of the "make" macro
IZ_BZIP2.  For example:

      make -f unix/Makefile IZ_BZIP2=../../bzip2/bzip-1.0.6 generic

   Frequent UnZip builders may find it convenient to create a nearby
bzip2 directory, or a nearby link to some particular bzip2 kit
directory. For example:

      make -f unix/Makefile IZ_BZIP2=../iz_bzip2 generic

where "../iz_bzip2" is a real bzip2 directory or a link to one.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   UnZipSFX Considerations
   -----------------------

   Building an optimal UnZipSFX executable is more complicated when
optional compression or encryption methods will be used (or when the
standard method, Deflate, will not be used).  Ideally, UnZipSFX should
be built with only the required compression and encryption methods
enabled, but the list of required compression and encryption methods is
determined when an archive is created, while the list of available
methods is determined when UnZipSFX is built.  As always, when creating
a self-extracting archive, the resulting program+archive bundle should
be tested (on the target system).  Options like "-q -t" should be
helpful for this.

   Normally, to minimize its size, UnZipSFX, the self-extracting archive
program, is built with support for only the Deflate compression method,
and the Traditional (weak) encryption method.  To get an UnZipSFX with
more capability, use the "make" macro LOCAL_UNZIP to specify the
appropriate C macros (described below) when building UnZip.  For
example, to build the same full-featured UnZip as in the earlier
example build command, but also enable support in UnZipSFX for AES
encryption, and for LZMA and PPMd compression, use a command like the
following:

      make -f unix/Makefile CC=gcc AES_WG=1 IZ_BZIP2=bzip2 \
       LOCAL_UNZIP='-DCRYPT_AES_WG_SFX -DLZMA_SFX -DPPMD_SFX' \
       LZMA=1 PPMD=1 generic

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Helping "make generic"
   ----------------------

   In some situations, the "unix/configure" script may not set all the
build options as desired.  One way to work around problems with "make
generic" is to use a two-step procedure.  First, instead of doing "make
generic", do "make flags".  For example:

      make -f unix/Makefile [other-options ...] flags

This should run the "unix/configure" script, which generates a "flags"
file in the main UnZip directory.  The (text) file "flags" contains all
the "make" macros which will be used in the second step.  This file can
be edited to make final adjustments to compile options, link options,
and so on.

   When "flags" has been changed as desired, the second step is to build
using the "generic" target.  For example:

      make -f unix/Makefile generic

This should do the build using the changed "flags" file.

   Of course, it's also possible to edit "unix/configure" and/or
"unix/Makefile", but normally that's not required.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Non-"generic" Builds
   --------------------

   For systems where the "generic" target does not work, and a
system-specific "make" file exists, use a "make" command which specifies
the appropriate "make" program and "make" file.  For example:

      nmake -f os2\makefile.os2 gcc

Or, if necessary, copy that system-specific "make" file into the main
UnZip directory (renaming it, if necessary), and use a "make" command
without the "-f DIR/Makefile" option (or without the "DIR/" part of the
path to the "make" file).  For example:

      copy msdos\makefile.msc .
      nmake -f makefile.msc

   As with a "generic" build, it's also possible to edit a
system-specific "make" file.

   In some environments which have very limited command line lengths
(like 128 characters for MS-DOS?), it may be necessary to add "#define"
directives directly into the "unzip.h" header file (near the top),
instead of specifying many options using the LOCAL_UNZIP "make" macro.

   The Info-ZIP developers do not have access to all the system types
for which support has been included (or suggested) in the various "make"
files. so non-"generic" targets are less well tested, and may need
considerable help from the user to get optimal results (or any success
at all).  Feedback from users of these system types would be gratefully
received.  To get a list of all possible system targets, use a command
like:

      make -f unix/Makefile list

Then "make -f unix/Makefile <target>" for your chosen "<target>".

   The "generic" target works for most systems, but if it fails with a
message about "_ftime unresolved" or "timezone redefined", then try
commands like the following:

      make -f unix/Makefile clean
      make -f unix/Makefile help
and then:
      make -f unix/Makefile generic2
or:
      make -f unix/Makefile generic3
as instructed.  The comments in unix/Makefile may offer some useful
information for building on various target systems.

   Use of "make" targets other than "generic" requires some care,
because other targets typically do not use the unix/configure script (or
its intermediate "flags" file), and this may cause programs to be built
without some expected features enabled.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Build Suggestions for Various Non-"generic" Targets
   ---------------------------------------------------

Macintosh (Mac OS X)
   On Mac OS X, use the Unix build procedure, described above.  See
   below for old infomation on pre-Mac-OS-X Macintosh.

MS-DOS
   See the msdos\Contents file for notes regarding which makefile(s) to
   use with which compiler.  In summary, pick one of msdos\makefile.*
   as appropriate, or use the OS/2 gccdos target for emx+gcc.  There is
   also an mscdos cross-compilation target in os2\makefile.os2.  There
   may have been an sco_dos cross-compilation target in the Unix
   makefile, but it seems to be gone now.  For Watcom 16-bit or 32-bit
   versions, see the comments in the OS/2 section below.

   After choosing the appropriate makefile and editing as necessary or
   desired, invoke the corresponding make utility.  Microsoft's NMAKE
   and the free dmake and GNU make utilities are generally the most
   versatile.  The makefiles in the msdos directory can be invoked in
   place ("nmake -f msdos\makefile.msc", for example).

MVS, z/OS
   Unpack all the files and transfer them to an appropriate PDS with
   ASCII -> EBCDIC conversion enabled, then edit UNZMVSC.JOB as required,
   and execute it to compile and link all the sources.  C/370 2.1 or
   later is required.  See README.MVS for further details.  (This is a
   new port and may need a little more work even to compile.)  There has
   been considerable work on the MVS and z/OS ports lately (indeed, z/OS
   may be split off as its own port soon), so there should be updates to
   these procedures shortly.

VM/CMS
   Unpack all the files and transfer them with ASCII -> EBCDIC
   conversion to an appropriate directory/minidisk/whatever, then
   execute UNZVMC to compile and link all the sources.  This may require
   C/370 version 2.1 or later and certain "nucleus extensions", although
   UnZip 5.3 has been reported to compile fine with the "ADCYCLE C/370
   v1.2 compiler".  (See how current this information is?)  Note that it
   will abend without access to the C/370 runtime library.  See the
   README.CMS file for more details.

Windows (XP, Vista, 7, and so on)
   For creating Windows executables, the Microsoft Visual C++ compiler
   platforms from version 2.x up to 8.0 (Visual Studio .Net C++ 2005)
   should work.  Recent build test have been run on VC++ 6.0, 7.1 and
   8.0.  The linker of newer Microsoft Visual C++ versions (beginning
   with Visual C++ 2008 - [VC++ 9.0]) create executables that are marked
   to run on Windows 2000 and newer, only.  Although these Visual C++
   environments may succeed in building Windows Info-ZIP executables,
   they cannot (and must not) be used to create binaries for public
   distribution, if support for older systems is intended.

   Alternative compilers for the Intel platforms are OpenWatcom C++,
   GNU C (Cygwin and MinGW32 have been tested, others, such as emx/rsxnt
   may also work), Borland C++, or lcc-win32.  DEC C/C++ for NT/Alpha
   may or may not still work.

   For the Watcom compiler, use WMAKE and win32\makefile.wat.

   For the Microsoft compilers, use NMAKE and win32\Makefile.

   For Cygwin or MinGW, use unix/Makefile and the "generic" target.
   (An old win32\Makefile.gcc may still be included in the kit, but it
   lacks support for many features, and may be of little value.)

   With emx+gcc, a good choice is GNUMake 3.75 (or higher) from the
   djgpp V2 distribution used on win32\Makefile.emx.

   The unzip32.dll WinDLL executables can be built using the appropriate
   Makefile in the win32\ subdirectory, or by using the Microsoft Visual
   C++ project files supplied below the windll subdirectory.  Besides the
   MSC compilers, gcc-mingw32, Watcom C and Borland C allow to build the
   Windows UnZip DLL.  By default, the Makefiles for compilers that use
   the Microsoft C runtime are configured to link against the shared
   multithreading C runtime DLL.  Depending on the intended usage for
   unzip32.dll, a statically linked dll might be more suitable.  The
   "make" scripts for MSC support build variants with static linking; you
   should look up the configuration switch DLLSTANDALONE in the MSC
   Makefile or the "Static..." build configurations in the Visual Studio
   project files.

Windows CE
   Only Microsoft Visual C++ 5.0, 6.0 or Visual C++ embedded 3.0 or later
   are supported.  Use the appropriate version of the included project
   files and check wince\README for details.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Build Suggestions for Various Old/Obsolete Non-"generic" Targets
   ----------------------------------------------------------------

   Note: Much of the following information is old, obsolete, and
probably useless, and is included for completeness only.  These system
types have not been tested with recent versions of Info-ZIP programs.
Antique OS enthusiasts are always welcome to contribute changes to
builders, code, or documentation for systems which the Info-ZIP team
lacks.

Acorn (RISC OS)
   Extract the files from the archive and place in standard Acorn C
   form (i.e., *.c, *.h and *.s become c.*, h.* and s.*, respectively),
   either using the UNZIP$EXTS environment variable and a pre-built UnZip
   binary, or using Spark[FS] and doing it manually.  Then copy the
   Acorn.Makefile to the main UnZip directory and either type "amu" or
   use the desktop "make" utility.

AmigaDOS
   SAS/Lattice C and Manx Aztec C are supported.  For SAS C 6.x do "smake
   -f amiga/smakefile all"; for Aztec C do "make -f amiga/makefile.azt
   all".  The Aztec C version supports assembly-language versions of two
   routines; these are enabled by default.

Atari TOS
   Turbo C is no longer supported; use gcc and the MiNT libraries, and
   do "make".  Note that all versions of gcc prior to 2.5.8 have a bug
   affecting 68000-based machines (optimizer adds 68020 instructions).
   See atari\README for comments on using other compilers.

BeOS
   make -f beos/Makefile

Human68K
   (This is a Japanese machine and OS.)  It appears that GNU "make" and
   gcc are required.  Presumably, to build everything, just do:
      gmake -f human68k/Makefile.gcc
   This port has not been tested since the 5.12 release.

Macintosh (Pre-Mac-OS-X)
   On Mac OS X, use the Unix build procedure.  The following information
   for pre-Mac-OS-X Macintosh is old, obsolete, and probably useless,
   and is included for completeness only.

   Metrowerks CodeWarrior Pro 4 with Universal Interfaces 3.1 is the only
   currently supported compiler, although the Mac Programmer's Workbench
   (MPW) and Think C were supported at one time and still have some hooks.
   Other Compilers may work too, no compiler specific instructions
   (pragma, header, macros, ...) were used in the code.

   For CodeWarrior Pro 4, un-BinHex the CodeWarrior project file and
   UnZip resource file (using Stuffit Expander or BinHex 4.0 or later),
   then open the project and click on the compile button.  See
   ":macos:Contents" for the possible project targets.  Link order of
   the standard libraries is very important: Link all sources first and
   all standard libraries last.

OS/2
   GNU "make", "nmake", or "dmake" may be used with the OS/2 makefile.
   All are freely available on the net.  To get a list of supported
   targets, use a command like the following:
      nmake -f os2\makefile.os2
   Comments at the top of the makefile explain the differences between
   some of the same-compiler targets.

TOPS-20
   No longer fully supported due to new, unported features, although
   patches are always welcome.  Unpack all files into the current
   directory only (including those in the kit's tops20 directory), then
   use make.mic and "do make".

------------------------------------------------------------------------

      Test
      ----

   On Unix(-like) systems, after a successful build, a very basic set of
tests can be run using the "make" target "test".  For example:

      make -f unix/Makefile test

   If PPMd compression was enabled, some basic PPMd tests can be run
using the "make" target "test_ppmd".    For example:

      make -f unix/Makefile test_ppmd

See "Known PPMd Compression Problems", below, for an explanation of why
running the PPMd test is important.

   These test sets are simple, not exhaustive.  Before relying on UnZip,
more realistic tests should be run in the user's own environment,
ideally, working with the user's own data.  This is especially true when
using new features, such as new compression and encryption methods.

------------------------------------------------------------------------

      Install
      -------

   Installation details depend on the operating system, and some user
preferences.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Installation Suggestions for Unix Systems
   -----------------------------------------

   On Unix(-like) systems, after a successful build (and, ideally,
testing), a command like the following should install the programs and
the "man" files into their default locations, "/usr/local/bin" and
"/usr/local/man/man1", respectively:

      make -f unix/Makefile install

   The "make" macros BINDIR and MANDIR can be used to specify different
destination directories.  For example:

      make -f unix/Makefile BINDIR=/usr/tools/bin \
       MANDIR=/usr/tools/man1 install

   The user who does the installation needs write permission in all the
destination directories.  Permissions should be set to 755 for the
executables, and 644 for the "man" files.  The "make" macros BINPERMS
and MANPERMS can be used to specify other values.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Installation Suggestions for Non-Unix Systems
   ---------------------------------------------

Amiga, Atari, MS-DOS, OS/2, Windows
   Move or copy unzip.exe (or unzip.ttp, or UnZip, or whatever) to the
   desired destination directory.  Add that directory to your path, if
   necessary.  Also possibly copy or link the UnZip executable to
   zipinfo.exe (or ii.exe), or else create an alias or a batch/command
   file for ZipInfo.  For example, for MS-DOS:
      @unzip -Z %1 %2 %3 %4 %5 %6 %7 %8 %9
   Under djgpp 2.x, zipinfo.exe is a 2K stub symbolically linked to
   unzip.exe.

Acorn RISC OS
   Copy the executables (unzip, funzip, and zipinfo) to the desired
   destination directory.  Add that directory to your Run$Path, if
   necessary.  See your Welcome manual if you don't know about Run$Path.

BeOS
   The default installation location is "/boot/usr/local".  (Executables
   and "man" files go into the "bin" and "man/man1" subdirectories
   there, respectively.  The corresponding plain-text (".txt") files may
   be more useful, however.

Macintosh (Pre-Mac-OS-X)
   MacZip requires at least System 7 and a Macintosh with a minimum of a
   Motorola 68020 or PowerPC 601 processor.  Other configurations may
   work but have not tested at all.
   The application (MacZip) is distributed as a combination of zip and
   unzip in one program. The official release is a fat binary with both
   regular 68K and native PowerPC versions included.
   Move the executable(s) somewhere.  For example, drag it (or them) to
   your Applications folder.  For easy access, make an alias in the
   Launcher Control Panel or directly on your desktop.
   This port supports also Apple-event, so you can install it in your
   Web browser as a helper-app.
   See "macos/README.TXT" (or ":macos:README.TXT" on Mac) for further
   info.

MVS, VM/CMS, z/OS
   More information may be coming soon.

VMS
   See [.vms]INSTALL_VMS.txt.

Human68K, TOPS-20, AOS/VS, etc.
   More information is unlikely to be coming soon.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Post-Installation
   -----------------

   Many operating systems require a timezone variable to be set
correctly (often "TZ").  Unix and VMS generally do so by default.
Windows does, if set up properly.  Other operating systems may not.  See
the discussion of the -f and -u options in the UnZip man page (or
unzip.txt).

------------------------------------------------------------------------

      C Macros to Control UnZip Behavior
      ----------------------------------

   Contents:

      General C macros
      System-Specific C macros
      Unicode-related C macros

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   General C Macros
   ----------------

ACORN_FTYPE_NFS   (needs support for long filenames with embedded commas)
   Enable a -F option that instructs UnZip to interpret the filetype
   information extracted from Acorn RiscOS extra field blocks. The
   filetype IDs are translated into "NFS filetype extensions" and
   appended to the names of the extracted files.  This feature
   facilitates maintenance of Unix-based NFS volumes that are exported
   to Acorn RiscOS systems.

BZIP2_SFX
   Enable bzip2 compression support in UnZipSFX (if it's enabled in
   UnZip).  By default, to reduce the size of the UnZipSFX executable,
   bzip2 compression support is disabled in UnZipSFX even when it's
   enabled in UnZip itself.

BZIP2_SUPPORT   (requires additional external code distribution)
   Enable support for bzip2 compression.  UnZip can optionally support
   the "bzip2" compression algorithm on most ports on 32-bit (or higher)
   platforms.  Currently, this support is integrated in the builders for
   MSDOS 32-bit (DJGPP), Unix, VMS, and Windows.

      Prerequisites:
      You have to obtain the bzip2 source kit (version 1.03 or higher).
      To have the UnZip builder build the bzip2 object library, extract
      the source files into the "bzip2" subdirectory.

      Compilation:
      - MSDOS, Windows: You have to supply the macro definition
        "USEBZ2=1" on the command line when you invoke the "make"
        program.
      - Unix: The target "generic" automatically enables bzip2 support
        when its unix/configure script detects bzip2 sources in the
        "bzip2" subdirectory.  See the Unix section below for details on
        how to specify the use of an existing bzip2 kit somewhere other
        than in the local UnZip "bzip2" subdirectory.  For non-"generic"
        targets, there are two options:
         a) Use a command like:
            make -f unix/Makefile CFLAGS=-DBZIP2_SUPPORT \
             LIB_BZ=BZIP2_DIR/libbz2.a YourTarget
            (Replace YourTarget with the appropriate target name.)
         b) Edit the Makefile to get the C macro BZIP2_SUPPORT defined
            in the compiler commands ("-DBZIP2_SUPPORT"), and the "make"
            macro LIB_BZ defined to locate the bzip2 object library
            ("LIB_BZ=BZIP2_DIR/libbz2.a").
      - VMS: The builders should automatically enable bzip2 support when
        they detect the bzip2 files in the [.bzip2] subdirectory.  The
        user can also specify a different directory where the bzip2
        source and object library can be found using the IZ_BZIP2
        parameter/macro.  See [.vms]INSTALL_VMS.txt for details.

CHEAP_SFX_AUTORUN
   Enable a simple "run command after extraction" feature in
   (command-line) UnZipSFX.  This feature is currently incompatible
   with the "-d <extract_dir>" command line option, therefore
   CHEAP_SFX_AUTORUN implicitly sets the NO_SFX_EXDIR option (below).

COPYRIGHT_CLEAN   (now default)
USE_SMITH_CODE
   The last chunk of code in UnZip that was blatantly derived from Sam
   Smith's unzip 2.0 (as in, "substantially similar") is in unreduce.c.
   Because the Reduce compression method was only used by very early
   PKZIP beta versions (0.9x), support for it is now omitted by default
   (COPYRIGHT_CLEAN).  To include support for Reduce compression, define
   the C macro USE_SMITH_CODE, and replace the stub unreduce.c source
   module with the separately distributed full source code module.  Note
   that this subjects your UnZip to any and all restrictions in Smith's
   copyright.  See the UnZip COPYING.OLD file for details.  The source
   code module unreduce.c is supplied in:
   ftp://ftp.info-zip.org/pub/infozip/src/unreduce_full.zip

IZ_CRYPT_AES_WG   (requires additional external code distribution)
   Enable WinZip/Gladman AES (strong) encryption support.  Currently,
   this support is integrated in the Make procedures of MSDOS 32-bit
   (DJGPP), VMS, Windows, and many Unix systems.  A separately
   distributed IZ_AES_WG source code kit is required.

IZ_CRYPT_AES_WG_SFX
   Enable WinZip/Gladman AES (strong) encryption support in UnZipSFX (if
   it's enabled in UnZip).  By default, to reduce the size of the
   UnZipSFX executable, AES_WG support is disabled in UnZipSFX even when
   it's enabled in UnZip itself.

IZ_CRYPT_TRAD_SFX
   Enable Traditional (weak) encryption support in UnZipSFX.  The
   default setting is to disable Traditional encryption in UnZipSFX, to
   reduce its size.  In UnZip, encryption support is enabled by default.
   See also NO_CRYPT, below.

DATE_FORMAT=DF_DMY or DF_MDY or DF_YMD
   Specify the order in which date components are printed in
   non-ZipInfo-mode listings: day-month-year, month-day-year, or
   year-month-day.  On DOS, FlexOS, OS2, Theos and Windows, the format
   is automatically obtained from the operating system; most others
   default to DF_MDY.

DATE_SEPCHAR='-' or '.' or '/' etc.
   Specify the character that separates the date components shown in
   (non-ZipInfo-mode) listings.  The Windows port obtains the separator
   automatically from the operating system's locale settings.  All
   others default to '-'.

DEBUG
   Used for debugging purposes; enables Trace() statements.  It's
   generally best to compile only one or two modules this way.

DEBUG_TIME
   Used for debugging the timezone code in fileio.c; enables TTrace()
   statements.  This code is only used for the freshen/update options
   (-f and -u), and non-Unix compilers often get it wrong.

DEFLATE64_SUPPORT   (default in UnZip and fUnZip)
NO_DEFLATE64   (default in UnZipSFX)
   The "Deflate64" compression algorithm from PKZIP 4.0 (or newer) is an
   enhanced variant of the Deflate algorithm that achieves slightly
   better compression ratios on highly redundant data.  For better
   compatibility with archives which use this method, UnZip should be
   built with support for Deflate64 enabled.  However, this results in
   significantly larger memory requirements to run the program.  For
   16-bit executables (DOS and OS/2), the special memory management to
   support the 64K history buffer results in a slight speed penalty.
   For UnZipSFX, "Deflate64" support should be unnecessary so long as
   the Info-ZIP Zip utility does not support it.  The NO_DEFLATE64
   option disables Deflate64 support.

DELETE_IF_FULL   (any system with unlink() function)
   If a write error is encountered (most likely due to a full disk),
   enabling this option will cause the incomplete file to be deleted
   instead of closed normally.  This is particularly useful on Windows
   CE, which must generally contend with extremely limited resources.

LZMA_SFX
   Enable LZMA compression support in UnZipSFX (if it's enabled in
   UnZip).  By default, to reduce the size of the UnZipSFX executable,
   LZMA compression support is disabled in UnZipSFX even when it's
   enabled in UnZip itself.

LZMA_SUPPORT
   Enable LZMA compression support in UnZip.

LZW_CLEAN
UNSHRINK_SUPPORT   (now default, as of January 2005)
   The "shrinking" algorithm from PKZIP 1.0 is an LZW variant.  Unisys
   patented the Lempel-Ziv-Welch algorithm in 1985 and has publicly
   claimed that decompression is covered by it.  (IBM also patented the
   same thing in a filing 3 weeks prior to Unisys's.)  In 2004, the
   Unisys and IBM patents expired worldwide, so unshrinking is now
   enabled again by default.  If you do not wish to include the LZW
   method, you may still disable it by defining LZW_CLEAN.  (Unshrinking
   was used by PKZIP 1.0 and 1.1, and Zip 1.0 and 1.1. All newer
   archives use only the deflation method.)

MULT_VOLUME   (experimental for 5.5x, do NOT use in production versions!)
NO_MULT_VOLUME   (default)
   The macro MULT_VOLUME is used to flag code portions needed for
   support of multi-volume archives.  For now, this flag MUST NOT be
   used to build a production version of UnZip. This flag has been
   introduced to allow integration of experimental code for multi-volume
   support in the master source tree.  This feature will become a
   default option in the future 6.1 release of UnZip (with any luck).

NO_ASM
NO_ASM_CRC
   Used by unix/configure ("make generic") to disable automatic
   selection of assembly code for CRC calculations.

NO_CRYPT
   Disable all encryption support in all programs.

NO_CRYPT_TRAD
   Disable Traditional (weak) encryption support in all programs.

NO_DEFLATE_SFX
   Disable Deflate compression support in UnZipSFX.  By default,
   UnZipSFX supports the usual Deflate compression method, but Deflate
   support can be disabled to reduce the size of the UnZipSFX
   executable.  (Currently, Deflate support is always enabled in UnZip
   itself.)

NO_SFX_EXDIR
   Disable the "-d <extract_dir>" option in UnZipSFX.  Since UnZip 5.5,
   "-d" has been enabled by default, to facilitate use with automated
   installation scripts and the like.

NO_ZIPINFO
   Disable ZipInfo mode (-Z).  This makes a smaller UnZip executable,
   because many text strings are left out.  Automatically enabled in
   some small-model builds under MS-DOS and OS/2, so ordinarily there is
   no need to specify this explicitly.  (Note that even with this
   defined, the resulting executable may still be too big to extract
   some zipfiles correctly, if built with the small memory model.)

NOTIMESTAMP
   Disable the -T option, which basically does exactly what Zip's -go
   options do.  That is, set the timestamp of the archive to that of the
   newest file in the archive without rewriting the archive. Unlike Zip,
   however, UnZip supports wildcard specifications for the archive name.
   For example, "unzip -T *.zip" will set the dates of all zipfiles in
   the current directory.  (UnZip's option is also much faster.)

OS2_EAS
   List the sizes of OS/2 EAs and ACLs for each file as two extra
   columns in "unzip -l" output.  This is primarily useful on OS/2
   systems, but, because zipfiles are portable, OS2_EAS can be defined
   for any system. (May be extended someday to show sizes of Mac
   resource forks, RISCOS and VMS file info, etc.)

PPMD_SFX
   Enable PPMd compression support in UnZipSFX (if it's enabled in
   UnZip).  By default, to reduce the size of the UnZipSFX executable,
   PPMd compression support is disabled in UnZipSFX even when it's
   enabled in UnZip itself.

PPMD_SUPPORT
   Enable PPMd compression support in UnZip.

UNIXBACKUP   (default on OS/2, Unix, Windows)
   Enable a -B option that instructs UnZip to rename files that would
   normally be overwritten.  The renamed files are given a tilde suffix
   and a unique sequence number ("~#####").  Note that previously renamed
   files may be overwritten without notice, even if the -n option is given.
   On target ports where UNIXBACKUP is enabled by default, the negated
   option, NO_UNIXBACKUP, may be used to disable this feature.

VMS_TEXT_CONV   (everywhere except VMS)
NO_VMS_TEXT_CONV
   VMS_TEXT_CONV enables conversion of some VMS-specific text file
   formats, and is defined by default in UnZip (but not in UnZipSFX).
   Defining NO_VMS_TEXT_CONV disables this capability.
   VMS Stream_LF-format text files archived with the "-V" option (/VMS),
   but NOT with -VV (/VMS=ALL), should be fine when extracted on other
   systems.  Stream_LF-files archived with -VV should be readable as well,
   but they may get some junk appended.  Text files with other record
   formats (like the common variable-length format, with its embedded
   byte counts) may be only semi-readable at best when extracted on other
   systems.  Defining VMS_TEXT_CONV enables UnZip's -aa option to detect
   and convert VMS variable-length record format text files into the
   native text format.  UnZip on non-VMS systems uses a simple VMS extra
   field analyzer to identify such text files.  (Very old versions of
   UnZip applied some heuristics instead.)

WILD_STOP_AT_DIR   (incompatible with WINDLL!)
   Enables an additional option "-W".  When "-W" is specified, the
   pattern-matching routine is modified so that both "?" (single-char
   wildcard) and "*" (multi-char wildcard) do not match the directory
   separator character "/". Examples:
      "*.c" matches "foo.c" but not "mydir/foo.c"
      "*/*.c" matches "bar/foo.c" but not "baz/bar/foo.c"
      "??*/*" matches "ab/foo" and "abc/foo" but not "a/foo" or "a/b/foo"
   To enable matching across directory separator chars, specify two
   consecutive multi-char wildcards ("**").  This modified behavior is
   like the pattern matching style used by the shells of some of UnZip's
   supported target OSs (for example, Acorn RISC OS).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   System-Specific C Macros
   ------------------------

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   Multi-System
   ------------

ASM_CRC   (Amiga/Aztec C; many x86 systems:  DOS, OS/2, Windows, Unix)
   Use an assembler routine to calculate the CRC checksums.  (Faster
   than the C code?)

ASM_INFLATECODES   (Amiga/Aztec C only, for now)
   Use an assembler version of inflate_codes() for speed.

PASSWD_FROM_STDIN   (Unix, VMS only)
   Used to allow the password on encrypted files to be read from stdin
   rather than the default stderr.  This was useful for those who wished
   to automate the testing or decoding of encrypted archives in a shell
   script, for example, using a command like:
      echo "password" | unzip -tq archive
   As of version 5.3, UnZip has a -P option for passing a password
   directly to the program, making PASSWD_FROM_STDIN unnecessary.
   PASSWD_FROM_STDIN will therefore probably be removed in some future
   version.  Note that the same security warnings given in the
   description of the -P option apply here as well.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   MS-DOS
   ------

DOSWILD   (MS-DOS only)
   Treat trailing "*.*" like Unix "*" (i.e., matches anything); treat
   trailing "*." as match for files without a dot (i.e., matches
   anything, as long as no dots in name).  Special treatment only occurs
   if patterns are at end of arguments.  That is, "a*.*" matches all
   files starting with "a", but "*.*c" matches all files ending in "c"
   only if they have a dot somewhere before the "c".  (The default method
   of specifying files without a dot would be "* -x *.*", making use of
   UnZip's exclude-files option.)  The matching is similar to that in
   Unix, if you pretend that undotted filenames really have an invisible
   dot at the end, which is how DOS and related systems treat filenames
   in general.  All other regular expressions (including "?" and
   "[range_of_chars]") retain their Unix-like behavior.

USE_DJGPP_ENV   (MS-DOS DJGPP 2.0x only)
   Regular DJGPP v2.0x built programs which use ENVIRONMENT are able to
   read from the file "djgpp.env" as well as those set in the
   environment.  This adds about 1KB to the size of the executable.
   This option is disabled by default in Info-ZIP source. If you are
   able to use "djgpp.env" and don't like to clutter the environment
   with many special purpose variables, you may want to build with this
   option set.

USE_DJGPP_GLOB   (MS-DOS DJGPP 2.0x only)
   Enable Unix-shell-like expansion of command-line wildcards (built-in
   "globbing").  This option enables the globbing built into the DJGPP
   startup code.  When using an executable built with this option, you
   normally need to quote wildcard arguments ("*"), to get them passed
   to the program unmodified.  Enabling this option is not recommended,
   because it results in Info-Zip binaries that do not behave as users
   might expect for an MS-DOS program.

USE_VFAT   (MS-DOS only, for using same executable under DOS and Windows)
   djgpp 2.x and emx/gcc+RSX 5.1 can detect when they are running under
   a Windows DOS box and will accordingly enable long-filename support.
   For now, only djgpp 2.x and emx/gcc with RSX 5.1 or later have this
   feature (and it is defined by default in msdos/makefile.dj2 and
   makefile.emx), but if/when other compilers build in similar support,
   define this macro to enable its use.  See also msdos/doscfg.h.  (Note
   that djgpp 2.0's LFN support is flaky; users should upgrade to 2.01
   or later.)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   QDOS
   ----

QLZIP   (Unix only)
   Add some support for QDOS extra fields.  This option enables Unix
   UnZip to append "datalen info" to QDOS exec type files in the same
   format as used by QDOS cross-compilers on Unix or the qltools v2.2(+).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   VMS
   ---

CHECK_VERSIONS   (VMS only)
   Obsolete.  Enable a warning when the VMS version of the system where
   UnZip is being used differs from the VMS version where an archive was
   created.  Long ago, some Info-ZIP developers were concerned that the
   format of the VMS (RMS) file-attribute data (stored in Zip "extra
   fields") might differ between different versions of VMS.  This has
   not been a problem, so this warning has long been disabled by
   default.

RETURN_CODES   (VMS only)
   Obsolete.  Enable a final status (success/error) message which is
   sent to the user's terminal when UnZip exits.  UnZip's internal
   Unix-style exit status codes are normally converted to VMS-style
   status codes in a DCL environment, so enabling this exit message
   would probably be more confusing than helpful.

VMSCLI   (VMS only)
   For internal use only.  Use VMS-style "slash options" (/FOOBAR)
   instead of the default Unix-style hyphen options (-f).  Automatic
   options stored in DCL symbols or logical names (UNZIP_OPTS or
   ZIPINFO_OPTS) must always be in the Unix style.  Beginning with UnZip
   5.32, the VMS builders generate both VMS-style (*_CLI.EXE) and
   Unix-style executables, so a user normally does NOT need to specify
   VMSCLI.

VMSWILD   (VMS only)
   Use parentheses rather than brackets to delimit sets (ranges), and
   use "%" instead of "?" as the single-character wildcard for internal
   filename matching.  (External matching of zipfile names always uses
   the standard VMS wildcard facilities; character sets are disallowed.)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   Windows
   -------

NO_W32TIMES_IZFIX   (Windows, including WinDLL, and Windows CE)
   Disable Info-ZIP's special timestamp adjustment to get stable time
   stamps on NTFS disks that do not change depending on the current time
   being normal vs. daylight saving time.  When this option is set,
   UnZip behaves like other programs; file timestamps on NTFS partitions
   are created so that their current local time representation displayed
   by directory listings (cmd.exe "dir" command or Windows Explorer
   listings) is the same as shown by UnZip's listing. But the actual UTC
   timestamp values stored in the NTFS file attributes vary depending on
   whether extraction is done at summer or winter time.
   This option is not recommended because it sacrifices the timestamp
   comparison checks when extracting or modifying archives in "update
   only newer" mode.  However, for environments where consistency of
   displayed dates of files extracted to NTFS vs. FAT disks is
   considered more important than correctly working update/freshen tasks
   of Zip and UnZip, this option may be used.  PLEASE DO NOT PUBLISH
   executables that were built with this option!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Unicode-Related C Macros
   ------------------------

UNICODE_SUPPORT
   Enable restoring from UTF-8 encoded paths.  These paths are stored
   either in extra fields or directly in the path fields if a new UTF-8
   bit is set in the flag word.  If the extra field is used, the UTF-8
   is stored in a backward-compatible way so that archives with UTF-8
   paths still work on zips and unzips that don't support Unicode. If
   the UTF-8 bit is used the UTF-8 is directly stored in the main path
   field, so an unzip with Unicode support (such as UnZip 6.0 or later)
   is needed to correctly interpret the UTF-8.  This support follows the
   recent additions to the PKWARE APPNOTE for Unicode support, except
   that Unicode comments on systems where UTF-8 is not the current
   character set is not implemented in this release.

   Internally, Unicode support can be achieved by three methods:
   a) The charset encoding used by the system is already UTF-8, so
      the program just has to select the UTF-8 versions of the stored
      filenames for file name handling.  (Such as most current Unix.)
      This method is enabled by defining the C macro UTF8_MAYBE_NATIVE;
      this activates code to check for native UTF-8 encoding in the
      locale settings.
   b) The operating system and the compilation environment support
      "wide character" data in Unicode encoding (UCS-2/UTF-16 or UCS-4),
      which are used to translate between UTF-8 and the native
      extended-ASCII character encoding.  The code for this method is
      activated by setting the C macro UNICODE_WCHAR.  It may be enabled
      together with UTF8_MAYBE_NATIVE to provide more versatile Unicode
      support and additional "debugging" options for checking the
      correct recognition of non-ASCII Unicode characters.
   c) The operating system and the compilation environment allow use of
      Unicode-encoded "wide character" data for native text strings
      support.  Complete support for this method requires a thorough
      revision of the UnZip code to convert the MBCS 8-bit string calls
      used now to the equivalent wide character calls.  All internal
      string handling and text output needs to be ported to use wchar_t
      character storage, which for the most part requires just proper
      type updating.  This capability could be included in UnZip 6.10.

   UnZip 6.10b (beta) now includes full wide character support of UTF-8
   paths on Windows NT and later.  On these OS the UTF-8 is converted to
   wide character paths and those paths used to recreate the Unicode
   paths on the file system.  What are not implemented on Windows are
   language-dependent messages, wide-character console input and output,
   and wide character list support.  These may be implemented in UnZip
   6.10.

   On current Linux and similar systems, UnZip now supports UTF-8 names
   and patterns on the command line as well as display of UTF-8 listings
   on the console.

   On some ports UNICODE_SUPPORT is set automatically:
   - Windows (and WinCE) use method b) by defining UNICODE_SUPPORT and
     UNICODE_WCHAR.  On Windows NT and later, paths are now created
     using wide character strings as in method c), but console input and
     output still use method b).  These are now the defaults.
   - On Unix, the automatic configuration script enables UNICODE_WCHAR
     if ISO-10646 compatible wide characters are supported and
     UTF8_MAYBE_NATIVE if the locale detection call is available.  For
     these ports, setting NO_UNICODE_SUPPORT forces deactivation of the
     Unicode support.

HAVE_WORKING_ISPRINT
NO_WORKING_ISPRINT
   HAVE_WORKING_ISPRINT enables enhanced filtering of non-printable
   characters in filenames by the fnfilter() function.  On some systems
   (Unix, VMS, some Windows compilers), this setting is enabled by
   default. In cases where isprint() flags printable extended characters
   as unprintable, defining NO_WORKING_ISPRINT disables the enhanced
   filtering capability in fnfilter().  (The ASCII control codes 0x01 to
   0x1f are always escaped on ASCII systems.)  If UNICODE_SUPPORT is
   enabled, the isprint() check is now done using wide characters for
   MBCS compatibility.

NO_SETLOCALE (for Unix)
   On Unix, it is now assumed that <locale.h> and the setlocale function
   are available, to set up locale-aware filtering of displayed
   filenames.  The option NO_SETLOCALE disables the dependency on
   <locale.h> and setlocale() on systems where this assumption is
   invalid (and the auto-configuring "make" target "generic" cannot be
   used for automatic capability detection).

_MBCS
NO_MBCS
   Enable multi-byte character set support.  This is the default for the
   Human68k system (originated from Japan) and for Windows (here only
   DBCS "double-byte character set" support).  MBCS support should also
   be enabled on systems which are capable of using UTF-8 as the native
   charset.  For MBCS support, the C runtime library must supply
   implementations for the mblen() function and the MB_CUR_MAX runtime
   macro/function.  NO_MBCS explicitly disables MBCS support for testing
   purposes, or when MBCS support does not work as expected.

------------------------------------------------------------------------

        Known PPMd Compression Problems
        ===============================

   Run-time problems have been observed with PPMd compression in UnZip
and Zip programs built using GCC on AIX/PowerPC and HP-UX/PA-RISC
systems (but not on HP-UX/IA64 systems).  On AIX systems, the programs
may hang/loop.  In HP-UX systems, the programs may fail/abort.  Zip may
produce corrupt archives.  The "make test_ppmd" procedure described
above should reveal the problem, if it exists in UnZip.  The Zip
builders lack a similar PPMd test capability, but it's very likely that
Zip will have PPMd problems in any environment where UnZip has PPMd
problems.

   One work-around for this problem is to re-compile the sensitive PPMd
module using a lower level of optimization than the usual, and then
re-link the programs.  On AIX, "-O2" seems to work.  On HP-UX, "-O1"
seems to work.  For example:

    make -f unix/Makefile PPMD=1 [options] CC=gcc generic   # Build.
    make -f unix/Makefile test_ppmd                         # Test.
    gcc -c -O1 szip/Ppmd8.c                                 # (Or "-O2"?)
    make -f unix/Makefile PPMD=1 [options] CC=gcc generic   # Re-link.
    make -f unix/Makefile test_ppmd                         # Re-test.

Other compilers (AIX xlC?) may need some other optimization setting.  In
any case, re-run the test after re-building UnZip, to verify that the
program is behving properly.

   We would be grateful to receive reports describing environments where
this problem occurs.

------------------------------------------------------------------------
