Subversion Repositories Kolibri OS

__________________________________________________________________________

  This is the Info-ZIP file INSTALL (for UnZip), last updated 16 Apr 2009.

__________________________________________________________________________

  Yes, this is a rather long file, but don't be intimidated:  much of its

  length is due to coverage of multiple operating systems and of optional

  customization features, large portions of which may be skipped.

__________________________________________________________________________

To compile UnZip, UnZipSFX and/or fUnZip (quick-start instructions):

========================================

(1) Unpack everything into a work directory somewhere, and make sure you're

    in the main UnZip directory (the one with this file in it).

    * (See note below concerning line termination format used in the source

       distribution)

(2) Copy the appropriate makefile into the current directory, except under

    OS/2.

(3) Run your "make" utility on the makefile (e.g., "nmake -f makefile.msc").

(4) Try out your new UnZip the way you would any new utility:  read the

    docs first.

    Ah ha ha ha!!  Oh, that kills me.  But seriously...  For VMS, see the

    Install section below or [.vms]README. for details.

    For DOS and other OSes without explicit timezone support (i.e., everybody

    but Unix, Windows 95 and NT), make sure the "TZ" environment variable is

    set to a valid and reasonable value; see your compiler docs for details.

(*) The unzip sources as well as other Info-ZIP source archives are packaged

    in Unix format. All text files use single LF (Ascii 0x0a) characters as

    line terminators.  On systems that use different conventions for plain text

    files (e.g.:DOS,Win9x,WinNT,OS/2 -> combined CR+LF; MacOS -> single CR),

    some utilities (editors, compilers, etc.) may not accept source files

    with LF line terminators.

    For these systems, we recommend to use Info-ZIP's UnZip utility for

    extraction of our distribution archives, applying the command option

    "-a" (= translate text files to native format) in the extraction command.

    In case this procedure is not applicable, an appropiate third-party

    conversion utility may be used to achieve the desired line termination

    style (examples: "flip", available for Unix, DOS, OS/2; or "tr" on Unix).

To compile UnZip, UnZipSFX and/or fUnZip (detailed instructions):

========================================

(1) Unpack *.c and *.h (the actual source files), preserving the directory

    structure (e.g., ./unix/unix.c).  The sole exception is TOPS-20, where

    tops20/* should be unpacked into the current directory, but TOPS-20

    is no longer fully supported anyway.

    As of UnZip 5.41, full decryption support has been integrated in the

    UnZip source distribution.  If you wish to compile binaries without

    decryption support, you must define the preprocessor flag NO_CRYPT.

    For many environments, you may add this flag to the custom compilation

    flags supplied by the environment variable LOCAL_UNZIP.  For more

    details, see the make procedures and accompanied documentation for your

    particular target OS.

    As of UnZip 5.53, support for the bzip2 compression algorithm has been

    added to UnZip. However, this support requires the original sources of

    the bzip2 compression library which have to be aquired separately;

    see "http://www.bzip.org/" for further reference.

(2) Choose the appropriate makefile based on the description in the Con-

    tents file for your OS (that is, there's only one for Unix or OS/2, but

    MS-DOS and several other OSes have several, depending on the compiler).

    Copy it into the current directory and rename if necessary or desired.

    (Some makefiles can be invoked in place; see (5) below.)

    Don't be afraid to read the makefile!  Many options will be explained only

    in the comments contained therein.  The defaults may not quite suit your

    system.  When making changes, remember that some "make" utilities expect

    tabs as part of the makefile syntax.  Failure with cryptic error messages

    will result if your editor quietly replaces those tabs with spaces.

    Special point of confusion:  some non-MSDOS makefiles contain MS-DOS

    targets (useful for cross-compilations). An example is the OS/2 makefile

    os2/makefile.os2 that contains the gccdos target for DOS emx+gcc and

    some more DOS related targets for Watcom C and MSC. But since version 5.3,

    the msdos subdirectory contains makefiles for all supported DOS compilers.

    [The old djgpp, djgpp1 and gcc_dos targets in unix/Makefile have been

    removed in 5.3; use msdos/makefile.dj* instead.]

    Extra-special point of confusion:  makefile.os2 expects to remain in

    the os2 subdirectory.  Invoke it via "nmake -f os2/makefile.os2 gcc",

    for example.

(3) If you want a non-standard version of UnZip, define one or more of the

    following optional macros, either by adding them to the LOCAL_UNZIP

    environment variable or by editing your makefile as appropriate.  The

    syntax differs from compiler to compiler, but macros are often defined

    via "-DMACRO_NAME" or similar (for one called MACRO_NAME).  Note that

    some of these may not be fully supported in future releases (or even

    in the current release).  Note also that very short command lines in

    MS-DOS (128 characters) may place severe limits on how many of these

    can be used; if need be, the definitions can be placed at the top of

    unzip.h instead (it is included in all source files)--for example,

    "#define MACRO_NAME", one macro per line.

      DOSWILD   (MS-DOS only)

        Treat trailing "*.*" like Unix "*" (i.e., matches anything); treat

        trailing "*." as match for files without a dot (i.e., matches any-

        thing, as long as no dots in name).  Special treatment only occurs

        if patterns are at end of arguments; i.e., "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 actually the same as

        Unix, if you assume 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.

      WILD_STOP_AT_DIR   (incompatible with WINDLL!)

        Enables an additional option "-W".  When this qualifier 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, two consecutive

        multi-char wildcards "**" should be specified.

        This modified behaviour is equivalent to the pattern matching style

        used by the shells of some of UnZip's supported target OSs (one

        example is Acorn RISC OS).

      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.)

      VMSCLI   (VMS only)

        Use VMS-style "slash options" (/FOOBAR) instead of the default Unix-

        style hyphenated options (-f).  This capability does not affect options

        stored in environment variables (UNZIP_OPTS or ZIPINFO_OPTS); those use

        the Unix style regardless.  Beginning with UnZip 5.32, the supplied

        VMS build methods generate both VMS-style and default "UNIX-style"

        executables; you should NOT add VMSCLI to the custom options.

      CHECK_VERSIONS   (VMS only)

        UnZip "extra fields" are used to store VMS (RMS) filesystem info,

        and the format of this information may differ in various versions

        of VMS.  Defining this option will enable UnZip warnings when the

        stored extra-field VMS version(s) do(es) not match the version of

        VMS currently being used.  This is a common occurrence in zipfiles

        received from other sites, but since the format of the filesystem

        does not seem to have changed in years (including on Alpha and

        IA64 systems), the warnings are not enabled by default.

      RETURN_CODES   (VMS only)

        VMS interprets return codes according to a rigid set of guidelines,

        which means it misinterprets normal UnZip return codes as all sorts

        of really nasty errors.  Therefore VMS UnZip returns an alternate set

        of return codes; since these may be difficult to interpret, define

        RETURN_CODES for human-readable explanations.

      VMS_TEXT_CONV   (everybody except VMS)

        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 formats (like the default VFC, with its

        embedded byte counts) may be only semi-readable at best when

        extracted on other systems.  Defining this option enables UnZip's

        -aa option to detect and convert VMS VFC-record text files into

        native text format.  Non-VMS UnZips now use a rudimentary VMS extra

        field analyser to relyably determine such text files. (Earlier

        versions of UnZip applied some heuristics instead.)

        Therefore this option is now enabled by default for the main program

        (but not the SFX stub), because it can be extremely useful on those

        rare occasions when a VMS text file must be extracted as normal text.

      USE_DJGPP_ENV   (MS-DOS DJGPP 2.0x only)

        Regular DJGPP v2.0x compiled 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 compile with

        this option set.

      USE_DJGPP_GLOB  (MS-DOS DJGPP 2.0x only)

        If you like to get UnZip binaries that handle command line arguments

        similar to Unix tools which are run in an Unix shell, you might want

        to set this compilation option.  This option enables the support for

        globbing command line arguments containing wildcards that is built

        into the DJGPP startup code.  When using a binary compiled with this

        option, you may have to enclose wildcard arguments in double quotes

        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 expected for MS-DOS programs.

      USE_VFAT  (MS-DOS only, for using same executable under DOS and Win95/NT)

        djgpp 2.x and emx/gcc+RSX 5.1 can detect when they are running under a

        Win32 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.]

      NO_W32TIMES_IZFIX (Win32 including WinDLL, and WinCE)

        By specifying this option, you can 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 exactly 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 sacrifies 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&UnZip, this

        option may be used.

        >> DO NOT DISTRIBUTE OR PUBLISH executables that were compiled with

        this option! <<

      NOTIMESTAMP

        This option disables the -T option, which basically does exactly what

        Zip's -go options do (i.e., set the timestamp of the zipfile 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.)

      DATE_FORMAT=DF_DMY or DF_MDY or DF_YMD

        This option controls the order in which date components are printed

        in non-ZipInfo-mode listings:  day-month-year or month-day-year or

        year-month-day.

        For DOS, FlexOS, OS2, Theos and Win32, the format is automatically

        obtained from the operating system; most others default to DF_MDY.

      DATE_SEPCHAR='-' or '.' or '/' etc.

        This option controls the character that separates the date components

        shown in (non-ZipInfo-mode) listings.  The Win32 port obtains the

        separator automatically from the operating system's locale settings;

        all others default to '-'.

      ACORN_FTYPE_NFS  (needs support for long filenames with embedded commas)

        This option enables 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.

      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(+).

      UNIXBACKUP   (default on OS/2, Unix, Win32)

        This option enables 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.

      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 for 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.)

      DELETE_IF_FULL  (anybody 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 for the

        Windows CE port, which must generally contend with extremely limited

        resources.

      ASM_CRC   (Amiga/Aztec C; many x86 systems:  DOS, OS/2, Win32, Unix)

        Use an assembler routine to calculate the CRC for each file (speed).

      ASM_INFLATECODES   (Amiga/Aztec C only, for now)

        Use an assembler version of inflate_codes() for speed.

      OLD_EXDIR

        No longer supported.

      SFX_EXDIR

        Enable the "-d " option for UnZipSFX.  This is now

        enabled by default (since UnZip 5.5) to facilitate use with

        automated installation scripts and the like.  For disabling

        this feature, see the NO_SFX_EXDIR option.

      NO_SFX_EXDIR

        Disables the "-d " option for UnZipSFX to generate the

        smallest possible executable stub.  (Prior to the UnZip 5.5 release,

        this was the default.)

      CHEAP_SFX_AUTORUN

        Enable a simple "run command after extraction" feature for

        the (command line) UnZipSFX stub.  This feature is currently

        incompatible with the "-d " command line option,

        therefore CHEAP_SFX_AUTORUN implicitely sets the NO_SFX_EXDIR

        option.

      NO_ZIPINFO

        Compile without ZipInfo mode (-Z) enabled; makes a smaller executable

        because many text strings are left out.  Automatically enabled for

        some small-model compiles 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 compiled with the small memory model.)

      USE_DEFLATE64 (default for UnZip and fUnZip)

      NO_DEFLATE64 (default for UnZipSFX stub)

        The "deflate64" 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.  Normally, UnZip should

        be compiled with support for this compression algorithm 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 performance (= speed) penalty.  And for the SFX stub,

        "deflate64" support might be unnessessary as long as the Info-ZIP

        Zip utility does not support it (quite likely, this will never

        get implemented).  So, the NO_DEFLATE64 option is provided to allow

        exclusion of the deflate64 support.

      USE_BZIP2 (requires additional external code distribution)

       UnZip can optionally support the "bzip2" compression algorithm for

       most ports on 32-bit (or higher) platforms. Currently, this support

       is integrated in the Make procedures of MSDOS 32-bit (DJGPP), VMS,

       Win32, and many Unix systems.

       Prerequisites:

       You have to obtain the bzip2 source distribution (version 1.03 or

       higher) and extract it into the "bzip2" subdirectory.

       Compilation:

       - MSDOS, Win32: You have to supply the symbol definition

         "USEBZ2=1" on the command line when you invoke the make program.

       - Unix: The target "generic" automatically activates bzip2 support

         when its configure script detects the presence of the bzip2 sources.

         For other targets, there are two options:

         a) Use the command

            "make -f unix/Makefile D_USE_BZ2=-DUSE_BZIP2 L_BZ2=-lbz2 \

                   LIBBZ2=bzip2/libbz2.a YourTarget"

           (Do not use the continuation line and replace YourTarget with

           the appropiate target name.)

         b) Edit the Makefile and remove the comment signs from the lines

            that define the macros D_USE_BZ2, L_BZ2, and LIBBZ2 (at about

            line 84 ff.).

       - VMS: The MMS/MMK build program should automatically activate the

         bzip2 support when it detects the presence of the bzip2 sources.

      MULT_VOLUME (experimental for 5.5x, do NOT use in production versions!)

      NO_MULT_VOLUME (default)

        The symbol MULT_VOLUME is used to flag code portions needed for

        support of multi-volume archives. For now, this flag MUST NOT be

        used to compile a production versions 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.

      LZW_CLEAN

      USE_UNSHRINK (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.)

      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.

        Since reducing was only used by very early PKZIP beta versions (0.9x),

        support for it is now omitted by default (COPYRIGHT_CLEAN).  To in-

        clude unreducing capability, define USE_SMITH_CODE and replace the

        stub unreduce.c source file by the separatly distributed full source

        code module.  Note that this subjects UnZip to any and all restrictions

        in Smith's copyright; see the UnZip COPYING.OLD file for details.

      USE_CRYPT

        Enable decryption support for all binaries.  The default setting

        is to disable decryption support for the SFX stub to keep its size

        as small as possible. For other binaries of the UnZip distribution,

        decryption support is enabled by default.

      NO_CRYPT

        Disable decryption support for all binaries.

      PASSWD_FROM_STDIN   (with full crypt sources only; 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 (say, in a

        shell script via ``echo "password" | unzip -tq archive''), but as of

        version 5.3, UnZip has a -P option for passing a password directly to

        the program.  PASSWD_FROM_STDIN will therefore probably be phased out

        in future versions.  Note that the same security warnings given in the

        description of the -P option apply here as well.

      UNICODE_SUPPORT

        Enable restoring from UTF-8 encoded paths.  These paths are stored

        in extra fields in a backward-compatible way so that archives with

        UTF-8 paths still work on zips and unzips that don't support Unicode.

        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.

           This method is enabled by setting the symbol 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 preprocessor

           symbol UNICODE_WCHAR.

           It may be activated 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 to use

           unicode-encoded "wide character" data for native text strings

           support.

           Complete support for this method requires a throughout revision

           of the UnZip code. All internal string handling and text output

           needs to be ported to use wchar_t character storage.

           This porting is still in an experimental stage and not ready

           for general distribution.

        On some ports UNICODE_SUPPORT is set automatically:

        - WIN32 (and WinCE) use method b) by defining UNICODE_SUPPORT and

          UNICODE_WCHAR.

        - 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.

      NO_SETLOCALE (for Unix)

        On Unix, it is now assumed that  and the setlocale function

        are available, to setup locale-aware filtering of displayed filenames.

        The option NO_SETLOCALE allows to disable the dependency on 

        and setlocale() on systems where this assumption is invalid (and the

        auto-configuring make target "generic" cannot be used for capabilities

        detection).

      _MBCS

      NO_MBCS

       Enable multi-byte character set support.  This is the default for the

       Human68k system (originated from Japan) and for Win32 (here only DBCS

       "double-byte character set" support).  The MBCS support should also be

       enabled on systems which are capable of using UTF-8 as native charset.

       For MBCS support, the C runtime library must supply implementations

       for the mblen() function and the MB_CUR_MAX runtime macro/function.

       The NO_MBCS symbol allows to explicitely disable MBCS support for

       testing purpose, or when MBCS support does not work as expected.

      HAVE_WORKING_ISPRINT

      NO_WORKING_ISPRINT

        The symbol HAVE_WORKING_ISPRINT enables enhanced non-printable chars

        filtering for filenames in the fnfilter() function.  On some systems

        (Unix, VMS, some Win32 compilers), this setting is enabled by default.

        In cases where isprint() flags printable extended characters as

        unprintable, defining NO_WORKING_ISPRINT allows to disable the enhanced

        filtering capability in fnfilter().  (The ASCII control codes 0x01 to

        0x1f are always escaped on ASCII systems.)

      DEBUG

        Used for debugging purposes; enables Trace() statements.  Generally

        it's 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.

(4) If you regularly compile new versions of UnZip and always want the same

    non-standard option(s), you may wish to add it (them) to the LOCAL_UNZIP

    environment variable (assuming it's supported in your makefile).  Under

    MS-DOS, for example, add this to AUTOEXEC.BAT:

        set LOCAL_UNZIP=-DDOSWILD -DDATE_FORMAT=DF_DMY

    You can also use the variable to hold special compiler options (e.g.,

    -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).

(5) Run the make utility on your chosen makefile:

      Unix

        For most systems it's possible to invoke the makefile in place, at

        the possible cost of an ignorable warning; do "make -f unix/Makefile

        list" to get a list of possible system targets, and 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, do "make clean", "make help", and

        then either "make generic2" or "make generic3" as instructed.  If all

        else fails, read the makefile itself; it contains numerous comments.

        (One of these days we'll make a configure script that automates this

        procedure better.)

      VMS (OpenVMS):

        On VMS, two build methods are provided: a command procedure, and

        description files for MMS or MMK.  Both methods must be run from

        the main directory, not the [.VMS] subdirectory.

        A simple build using the command procedure looks like this:

             @ [.VMS]BUILD_UNZIP.COM

        A simple build using MMS or MMK looks like this:

             MMS /DESCRIP = [.VMS]DESCRIP.MMS      ! Or, with MMK, ...

             MMK /DESCRIP = [.VMS]DESCRIP.MMS

        Various options for each build method are explained in comments in

        the main builder file, either BUILD_UNZIP.COM or DESCRIP.MMS.

        Here are some more complex build examples:

        o Build with the large-file option enabled (non-VAX only):

             @ [.VMS]BUILD_UNZIP LARGE

          or:

             MMS /DESC = [.VMS] /MACRO = LARGE=1

        o Re-link the executables (small-file and large-file):

             @ [.VMS]BUILD_UNZIP LINK

             @ [.VMS]BUILD_UNZIP LARGE LINK

          or

             MMK /DESC = [.VMS] CLEAN_EXE  ! Deletes existing executables.

             MMK /DESC = [.VMS]            ! Builds new executables.

             MMK /DESC = [.VMS] /MACRO = LARGE=1 CLEAN_EXE

             MMK /DESC = [.VMS] /MACRO = LARGE=1

        o Build a large-file product from scratch, for debug, getting

          compiler listings and link maps:

             mms /desc = [.vms] clean

             mms /desc = [.vms] /macro = (DBG=1, LARGE=1. LIST=1)

        On VAX, the builders attempt to cope with the various available C

        compilers: DEC/Compaq/HP C, VAX C, or GNU C.  If DEC/Compaq/HP C is

        not available or not desired, comments in the relevant builder file

        explain the command-line options used to select a different

        compiler.

        System-architecture-specific files (like objects and executables)

        are placed in separate directories, such as [.ALPHA], [.IA64], or

        [.VAX].  Large-file products get their own directories, [.ALPHAL]

        or [.IA64L].  On VAX, VAX C products are placed in [.VAXV], GNU C

        products in [.VAXG].  Each product builder announces what the

        destination directory will be when it is run.

        Common files, such as the help libraries (UNZIP.HLP for the

        default UNIX-like command-line interface, UNZIP_CLI.HLP for the

        VMS-like command-line interface), are placed in the main

        directory.  With a mixed-architecture VMS cluster, the same main

        directory on a shared disk may may be used by all system types.

        (Using the NOHELP option with BUILD_UNZIP.COM can keep it from

        making the same help files repeatedly.)

        Some further information may be found in the files

        [.VMS]README. and [.VMS]00BINARY.VMS, though much of what's

        there is now obsolete.

      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 (as noted above) use the OS/2 gccdos target for

        emx+gcc.  There is also an mscdos cross-compilation target in

        os2\makefile.os2 and a sco_dos cross-compilation target in the Unix

        makefile.  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).

      OS/2

        Either GNU make, nmake or dmake may be used with the OS/2 makefile;

        all are freely available on the net.  Do "nmake -f os2\makefile.os2",

        for example, to get a list of supported targets.  More generally,

        read the comments at the top of the makefile for an explanation of

        the differences between some of the same-compiler targets.

      Win32 (WinNT or Win9x)

        For creating Win32 executables, the Microsoft Visual C++ compiler

        platforms from version 2.x up to 8.0 (Visual Studio .Net C++ 2005)

        are supported.  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 Win32 Info-ZIP executables,

        they cannot (and must not) be used to create binaries for public

        distribution.

        Alternative compilers for the Intel platforms are OpenWatcom C++,

        GNU C (preferably the mingw32 port, CygWin and 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 mingw32 and

        CygWin, GNU Make and win32\Makefile.gcc should do the job.

        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 appropiate

        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.

      WinCE (WinCE or WinNT)

        Only Microsoft Visual C++ 5.0, 6.0 or Visual C++ embedded 3.0 or later

        are supported.  Use the appropiate version of the included project

        files and check wince\README for details.

      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.

      Macintosh

        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.

      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.

      VM/CMS

        Unpack all the files and transfer them with ASCII -> EBCDIC conver-

        sion 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.'  Note that it will abend without access to the C/370

        runtime library.  See the README.CMS file for more details.

      MVS

        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.]

      Human68K

        [This is a Japanese machine and OS.]  It appears that GNU make and

        gcc are required; presumably just do "gmake -f human68k/Makefile.gcc"

        to build everything.  This port has not been tested since the 5.12

        release.

      TOPS-20

        [No longer fully supported due to new, unported features, although

        patches are always accepted.]  Unpack all files into the current

        directory only (including those in the zipfile's tops20 directory),

        then use make.mic and "do make".

      BeOS

        You can run the BeOS makefile in place by typing "make -f

        beos/Makefile".  In fact, this is how the author tests it.

    Running the appropriate make utility should produce three executables on

    most systems, one for UnZip/ZipInfo, one for UnZipSFX, and one for fUnZip.

    (VMS is one prominent exception:  fUnZip makes no sense on it.  The Amiga

    produces a fourth executable called MakeSFX, which is necessary because

    Amiga self-extracting archives cannot be created by simple concatenation.

    If necessary the source amiga/makesfx.c can be compiled on other systems.)

    Read any OS-specific README files for notes on setting things up for

    normal use (especially for VMS) and for warnings about known quirks and

    bugs in various compilers (especially for MS-DOS).

    Also note that many OSes require a timezone variable to be set correctly

    (often "TZ"); Unix and VMS generally do so by default, Win95/NT do if set

    up properly, but other OSes generally do not.  See the discussion of the

    -f and -u options in the UnZip man page (or unzip.txt).  BeOS doesn't

    currently support timezone information at all, but this will probably be

    added soon.

    Then test your new UnZip on a few archives and let us know if there are

    problems (but *please* first make certain that the archives aren't actu-

    ally corrupted and that you didn't make one of the silly mistakes dis-

    cussed in the documentation).  If possible, double-check any problems

    with PKUNZIP or with a previous version of UnZip prior to reporting a

    "bug."  The zipfile itself may be damaged.

To install:

===========

Unix

  The default prefix for the installation location is /usr/local (things

  go into the bin and man/man1 subdirectories beneath the prefix), and

  the default man-page extension is "1" (corresponding to man/man1, above).

  To install as per the defaults, do "make install"; otherwise do "make

  prefix=/your/path manext=your_extension install".  (For Intel Unix flavors

  where the assembler CRC routines were used [ASM_CRC], use the install_asm

  target instead of the regular install target.)  For example, to install

  in your home directory with "l" as the man-page extension (for "local"),

  do "make prefix=$HOME manext=l install".  Permissions will be 755 for the

  executables and 644 for the man pages.  In general root must perform in-

  stallation into a public directory.  Do "rehash" if your shell requires

  it in order to find the new executables.

VMS

  To complete the installation, the executables may be left in place,

  or moved (or copied) to a convenient place.  While other methods

  (like DCL$PATH) exist, most users define symbols to make the UnZip

  executables available as foreign commands.  These symbol definitions

  may be placed in a user's SYS$LOGIN:LOGIN.COM, or in a more central

  location, like SYS$MANAGER:SYLOGIN.COM.  Typical symbol definitions

  might look like these:

     UNZIP :== $ dev:[dir]UNZIP.EXE             ! UNIX-like command line.

  or:

     UNZIP :== $ dev:[dir]UNZIP_CLI.EXE         ! VMS-like command line.

  For convenience, a ZIPINFO symbol could also be defined, so:

     ZIPINFO :== $ dev:[dir]UNZIP.EXE """-Z"""

  On a non-VAX system, different symbols could be defined for the

  small-file and large-file programs.  For example:

     UNZIPS  :== $ dev:[dir.ALPHA]UNZIP.EXE     ! UNZIPS = small-file UnZip.

     UNZIP*L :== $ dev:[dir.ALPHAL]UNZIP.EXE    ! UNZIP[L] = large-file UnZip.

  The builders create help text files, UNZIP.HLP and UNZIP_CLI.HLP.

  These may be incorporated into an existing help library, or a separate

  UnZip help library may be created using commands like these, using

  either UNZIP.HLP (as shown) or UNZIP_CLI.HLP:

      $ LIBRARY /HELP dev:[dir]existing_library.HLB UNZIP.HLP

      $ LIBRARY /CREATE /HELP UNZIP.HLB UNZIP.HLP

  UnZip help may then be accessed from a separate UnZip help library

  using a command like:

          $ HELP /LIBRARY = device:[directory]UNZIP.HLB

  For greater ease, the user (or system manager) may define a

  HLP$LIBRARY logical name to allow the HELP utility to find the UnZip

  help library automatically.  See HELP HELP /USERLIBRARY for more

  details.   The command procedure HLP_LIB_NEXT.COM may be used to

  determine the next available HLP$LIBRARY logical name, and could be

  adapted to define a HLP$LIBRARY logical name for an UnZip help library.

  The kit includes MAKESFX.COM, a command procedure intended to simplify

  creating a self-extracting archive.  It may be helpful to install this

  procedure near the UnZip executables.  MAKESFX.COM expects another

  symbol definition, like one of these:

     UNZIPSFX :== $ dev:[dir]UNZIPSFX.EXE       ! UNIX-like command line.

  or:

     UNZIPSFX :== $ dev:[dir]UNZIPSFX_CLI.EXE   ! VMS-like command line.

  Again here, on a non-VAX system, either a small-file or a large-file

  UNZIPSFX program may be used.  (MAKESFX.COM could be modified to allow

  a run-time choice to be made.)

OS/2, MS-DOS, NT, Atari, Amiga

  Move or copy unzip.exe (or unzip.ttp, or UnZip, or whatever) to a direc-

  tory in your path; also possibly copy the UnZip executable to zipinfo.exe

  (or ii.exe), or else create an alias or a batch/command file for ZipInfo

  ("@unzip -Z %1 %2 %3 %4 %5 %6 %7 %8 %9" under MS-DOS).  The latter is only

  relevant if NO_ZIPINFO was *not* defined, obviously...  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 somewhere in your

  Run$Path.  See your Welcome manual if you don't know about Run$Path.

BeOS

  The default prefix for the installation location is /boot/usr/local

  (things go into the bin and man/man1 subdirectories beneath the prefix),

  and the default man-page extension is "1" (corresponding to the man/man1,

  above).  Of course, these Unix man-pages aren't useful until someone ports

  something that can format them... plain text versions are also installed

  with an extension of ".txt".  To install, do a "make install", or to

  change the prefix, do "make prefix=/your/path install".  For example, to

  install in /boot/bin, do "make prefix=/boot/bin install".

Macintosh

  (This port is for Macintosh OS before Mac OS X.  See Unix Apple below for

  Mac OS X and later.)

  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 it is not tested at all.

  The application (MacZip) is distributed as a combination of zip and unzip

  in one program. The offical 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

  WWW-Browser as a helper-app.

  Look into "macos/README.TXT" (or ":macos:README.TXT" on Mac) for further

  info.

Macintosh OS X (Unix Apple)

  Mac OS X and later are based on BSD Unix and are supported by the Unix

  port.  See the Unix port for details.  Though support is currently

  minimal, we plan to support additional Mac OS X features, such as resource

  forks, in future releases.

Human68K, TOPS-20, AOS/VS, MVS, VM/CMS, etc.

  Dunno, sorry...