========================================================================
* README
========================================================================

This is the README file for the 20 April 2009 public release of the
Info-ZIP group's portable UnZip zipfile-extraction program (and related
utilities).

unzip60.zip       portable UnZip, version 6.0, source code distribution
unzip60.tar.Z     same as above, but compress'd tar format
unzip60.tar.gz    same as above, but gzip'd tar format

__________________________________________________________________________

BEFORE YOU ASK:  UnZip, its companion utility Zip, and related utilities
and support files can be found in many places; read the file "WHERE" for
further details.  To contact the authors with suggestions, bug reports,
or fixes, continue reading this file (README) and, if this is part of a
source distribution, the file "ZipPorts" in the proginfo directory.  Also
in source distributions:  read "BUGS" for a list of known bugs, non-bugs
and possible future bugs; INSTALL for instructions on how to build UnZip;
and "Contents" for a commented listing of all the distributed files.
__________________________________________________________________________


GENERAL INFO
------------
UnZip is an extraction utility for archives compressed in .zip format (also
called "zipfiles").  Although highly compatible both with PKWARE's PKZIP
and PKUNZIP utilities for MS-DOS and with Info-ZIP's own Zip program, our
primary objectives have been portability and non-MSDOS functionality.

This version of UnZip has been ported to a stupendous array of hardware--
from micros to supercomputers--and operating systems:  Unix (many flavors),
VMS, OS/2 (including DLL version), Windows NT and Windows 95 (including DLL
version), Windows CE (GUI version), Windows 3.x (including DLL version),
MS-DOS, AmigaDOS, Atari TOS, Acorn RISC OS, BeOS, Macintosh (GUI version),
SMS/QDOS, MVS, VM/CMS, FlexOS, Tandem NSK, Human68k (mostly), AOS/VS (partly)
and TOPS-20 (partly).  UnZip features not found in PKUNZIP include source
code; default extraction of directory trees (with a switch to defeat this,
rather than the reverse); system-specific extended file attributes; and, of
course, the ability to run under most of your favorite operating systems.
Plus, it's free. :-)

For source distributions, see the main Contents file for a list of what's
included, and read INSTALL for instructions on compiling (including OS-
specific comments).  The individual operating systems' Contents files (for
example, vms/Contents) may list important compilation info in addition to
explaining what files are what, so be sure to read them.  Some of the ports
have their own, special README files, so be sure to look for those, too.

See unzip.1 or unzip.txt for usage (or the corresponding UnZipSFX, ZipInfo,
fUnZip and ZipGrep docs).  For VMS, unzip_def.rnh or unzip_cli.help may be
compiled into unzip.hlp and installed as a normal VMS help entry; see
vms/descrip.mms.


CHANGES AND NEW FEATURES
------------------------
UnZip 6.0 finally supports nowadays "large" files of sizes > 2 GiB!
This is the first release containing support for the PKWARE Zip64
enhancements.
Major changes are:
   - Support PKWARE ZIP64 extensions, allowing Zip archives and Zip archive
     entries larger than 4 GiBytes and more than 65536 entries within a single
     Zip archive. This support is currently only available for Unix,
     OpenVMS and Win32/Win64.
   - Support for bzip2 compression method.
   - Support for UTF-8 encoded entry names, both through PKWARE's "General
     Purpose Flags Bit 11" indicator and Info-ZIP's new "up" unicode path
     extra field.  (Currently, on Windows the UTF-8 handling is limited to
     the character subset contained in the configured non-unicode "system
     code page".)
   - Added "wrong implementation used" warning to error messages of the MSDOS
     port when used under Win32, in an attempt to reduce false bug reports.
   - Fixed "Time of Creation/Time of Use" vulnerability when setting attributes
     of extracted files, for Unix and Unix-like ports.
   - Fixed memory leak when processing invalid deflated data.
   - Fixed long-standing bug in unshrink (partial_clear), added boundary checks
     against invalid compressed data.
   - On Unix, keep inherited SGID attribute bit for extracted directories
     unless restoration of owner/group id or SUID/SGID/Tacky attributes was
     requested.
   - On Unix, allow extracted filenames to contain embedded control characters
     when explicitly requested by specifying the new command line option "-^".
   - On Unix, support restoration of symbolic link attributes.
   - On Unix, support restoration of 32-bit UID/GID data using the new "ux"
     IZUNIX3 extra field introduced with Zip 3.0.
   - Support for ODS5 extended filename syntax on new OpenVMS systems.
   - Support symbolic links zipped up on VMS.
   - On VMS (only 8.x or better), support symbolic link creation.
   - On VMS, support option to create converted text files in Stream_LF format.
   - New -D option to suppress restoration of timestamps for extracted
     directory entries (on those ports that support setting of directory
     timestamps).  By specifying "-DD", this new option also allows to suppress
     timestamp restoration for ALL extracted files on all UnZip ports which
     support restoration of timestamps.
     On VMS, the default behaviour is now to skip restoration of directory
     timestamps; here, "--D" restores ALL timestamps, "-D" restores none.
   - On OS/2, Win32, and Unix, the (previously optional) feature UNIXBACKUP
     to allow saving backup copies of overwritten files on extraction is now
     enabled by default.

For the UnZip 6.0 release, we want to give special credit to Myles Bennet,
who started the job of supporting ZIP64 extensions and Large-File (> 2GiB)
and provided a first (alpha-state) port.

The 5.52 maintenance release fixes a few minor problems found in the 5.51
release, closes some more security holes, adds a new AtheOS port, and
contains a Win32 extra-field code cleanup that was not finished earlier.
The most important changes are:

   - (re)enabled unshrinking support by default, the LZW patents have expired
   - fixed an extraction size bug for encrypted stored entries (12 excess bytes
     were written with 5.51)
   - fixed false "uncompressed size mismatch" messages when extracting
     encrypted archive entries
   - do not restore SUID/SGID/Tacky attribute bits on Unix (BeOS, AtheOS)
     unless explicitely requested by new "-K" command line qualifier
   - optional support for "-W" qualifier to modify the pattern matching syntax
     (with -W: "*" stops at directory delimiter, "**" matches unlimited)
   - prevent buffer overflow caused by bogus extra-long Zipfile specification
   - performance enhancements for VMS port
   - fixed windll interface handling of its extraction mode qualifiers
     nfflag, ExtractOnlyNewer, noflag, PromptToOverwrite; added detailed
     explanation of their meanings and interactions to the windll documentation

The 5.51 maintenance release adds a command-line CE port, intended for
batch processing. With the integration of this port, the pUnZip port
has been revised and "revitalized".
The most important changes for the general public are a number of
bug fixes, mostly related to security issues:

   - repair a serious bug in the textmode output conversion code for the 16-bit
     ports (16-bit MSDOS, OS/2 1.x, some variants of AMIGA, possibly others)
     which was introduced by the Deflate64 support of release 5.5
   - fix a long standing bug in the the inflate decompression method that
     prevented correct extraction in some rare cases
   - fixed holes in parent dir traversal security code (e.g.: ".^C." slipped
     through the previous version of the check code)
   - fixed security hole: check naming consistency in local and central header
   - fixed security hole: prevent extracted symlinks from redirecting file
     extraction paths

The main addition in the 5.5 release is support for PKWARE's new Deflate64(tm)
algorithm, which appeared first in PKZIP 4.0 (published November 2000).
As usual, some other bugfixes and clean-ups have been integrated:

   - support for Deflate64 (Zip compression method #9)
   - support for extracting VMS variable length record text files on
     any system
   - optional "cheap autorun" feature for the SFX stub
   - security fixes:
     * strip leading slash from stored pathspecs,
     * remove "../" parent dir path components from extracted file names
   - new option "-:" to allow verbatim extraction of file names containing
     "../" parent dir path specs
   - fixed file handle leak for the DLL code
   - repaired OS2 & WinNT ACL extraction which was broken in 5.42

The 5.42 maintenance release fixes more bugs and cleans up the redistribution
conditions:

   - removal of unreduce.c and amiga/timelib.c code to get rid of the last
     distribution restrictions beyond the BSD-like Info-ZIP LICENSE
   - new generic timelib replacement (currently used by AMIGA port)
   - more reasonable mapping rules of UNIX "leading-dot" filenames to the
     DOS 8.3 name convention
   - repaired screensize detection in MORE paging code
     (was broken for DOS/OS2/WIN32 in 5.41)

The 5.41 maintenance release adds another new port and fixes some bugs.

   - new BSD-like LICENSE
   - new Novell Netware NLM port
   - supports extraction of archives with more than 64k entries
   - attribute handling of VMS port was broken in UnZip 5.4
   - decryption support integrated in the main source distribution

The 5.4 release adds new ports, again. Other important items are changes
to the listing format, new supplemental features and several bug fixes
(especially concerning time-stamp handling...):

   - new IBM OS/390 port, a UNIX derivate (POSIX with EBCDIC charset)
   - complete revision of the MacOS port
   - changed listing formats to enlarge the file size fields for more digits
   - added capability to restore directory attributes on MSDOS, OS/2, WIN32
   - enabled support of symbolic links on BeOS
   - Unix: optional Acorn filetype support, useful for volumes exported via NFS
   - several changes/additions to the DLL API
   - GUI SFX stub for Win16 (Windows 3.1) and Win32 (Windows 9x, Windows NT)
   - new free GCC compiler environments supported on WIN32
   - many time-zone handling bug fixes for WIN32, AMIGA, ...

The 5.32 release adds two new ports and a fix for at least one relatively
serious bug:

   - new FlexOS port
   - new Tandem NSK port
   - new Visual BASIC support (compatibility with the Windows DLLs)
   - new -T option (set zipfile timestamp) for virtually all ports
   - fix for timestamps beyond 2038 (e.g., 2097; crashed under DOS/Win95/NT)
   - fix for undetected "dangling" symbolic links (i.e., no pointee)
   - fix for VMS indexed-file extraction problem (stored with Zip 2.0 or 2.1)
   - further performance optimizations

The 5.31 release included nothing but small bug-fixes and typo corrections,
with the exception of some minor performance tweaks.

The 5.3 release added still more ports and more cross-platform portability
features:

   - new BeOS port
   - new SMS/QDOS port
   - new Windows CE graphical port
   - VM/CMS port fully updated and tested
   - MVS port fully updated and tested
   - updated Windows DLL port, with WiZ GUI spun off to a separate package
   - full Universal Time (UTC or GMT) support for trans-timezone consistency
   - cross-platform support for 8-bit characters (ISO Latin-1, OEM code pages)
   - support for NT security descriptors (ACLs)
   - support for overwriting OS/2 directory EAs if -o option given
   - updated Solaris/SVR4 package facility

What is (still!) not added is multi-part archive support (a.k.a. "diskette
spanning", though we really mean archive splitting and not the old diskette
spanning) and a unified and more powerful DLL interface.  These are the two
highest priorities for the 6.x releases.  Work on the former is almost
certain to have commenced by the time you read this.  This time we mean it!
You betcha. :-)

Although the DLLs are still basically a mess, the Windows DLLs (16- and 32-
bit) now have some documentation and a small example application.  Note that
they should now be compatible with C/C++, Visual BASIC and Delphi.  Weirder
languages (FoxBase, etc.) are probably Right Out.


INTERNET RESOURCES
------------------

Info-ZIP's web site is at http://www.info-zip.org/pub/infozip/
and contains the most up-to-date information about coming releases,
links to binaries, and common problems.
(See http://www.info-zip.org/pub/infozip/FAQ.html for the latter.)
Files may also be retrieved via ftp://ftp.info-zip.org/pub/infozip/ .
Thanks to LEO (Munich, Germany) for previously hosting our primary site.


DISTRIBUTION
------------
If you have a question regarding redistribution of Info-ZIP software, either
as is, as packaging for a commercial product, or as an integral part of a
commercial product, please read the Frequently Asked Questions (FAQ) section
of the included COPYING file.  All Info-ZIP releases are now covered by
the Info-ZIP license.  See the file LICENSE.  The most current license
should be available at http://www.info-zip.org/license.html and
ftp://ftp.info-zip.org/pub/infozip/license.html.

Insofar as C compilers are rare on some platforms and the authors only have
direct access to a subset of the supported systems, others may wish to pro-
vide ready-to-run executables for new systems.  In general there is no prob-
lem with this; we require only that such distributions include this README
file, the WHERE file, the LICENSE file (contains copyright/redistribution
information), and the appropriate documentation files (unzip.txt and/or
unzip.1 for UnZip, etc.).  If the local system provides a way to make self-
extracting archives in which both the executables and text files can be
stored together, that's best (in particular, use UnZipSFX if at all possible,
even if it's a few kilobytes bigger than the alternatives); otherwise we
suggest a bare UnZip executable and a separate zipfile containing the re-
maining text and binary files.  If another archiving method is in common
use on the target system (for example, Zoo or LHa), that may also be used.


BUGS AND NEW PORTS:  CONTACTING INFO-ZIP
----------------------------------------
All bug reports and patches (context diffs only, please!) should be
submitted either through the new Info-ZIP Discussion Forum at
http://www.info-zip.org/board/board.pl or through the Info-ZIP SourceForge
site at http://sourceforge.net/projects/infozip/.  The forum allows file
attachments while SourceForge provides a place to post patches.  The old
Zip-Bugs@lists.wku.edu e-mail address for the Info-ZIP authors was
discontinued after heavy continuous spam, as was the QuickTopic discussion
forum.  The above methods are public, but we also can be reached directly
using the web reply page at http://www.info-zip.org/zip-bug.html.  If you
need to send us files privately, contact us first for instructions.

"Dumb questions" that aren't adequately answered in the documentation
should also be directed to Zip-Bugs rather than to a global forum such
as Usenet.  (Kindly make certain that your question *isn't* answered by
the documentation, however--a great deal of effort has gone into making
it clear and complete.)

Suggestions for new features can be discussed on the new Discussion Forum.
A new mailing list for Info-ZIP beta testers and interested parties may
be created someday, but for now any issues found in the betas should use
the forum.  We make no promises to act on all suggestions or even all
patches, but if it is something that is manifestly useful, sending the
required patches to Zip-Bugs directly (as per the instructions in the
ZipPorts file) is likely to produce a quicker response than asking us to
do it--the authors are always ridiculously short on time.  (Please do
NOT send patches or encoded zipfiles to the Info-ZIP list.  Please DO
read the ZipPorts file before sending any large patch.  It would be
difficult to over-emphasize this point...)

If you are considering a port, not only should you read the ZipPorts file,
but also please check in with Zip-Bugs BEFORE getting started, since the
code is constantly being updated behind the scenes.  (For example, VxWorks,
VMOS and Netware ports were once claimed to be under construction, although
we have yet to see any up-to-date patches.)  We will arrange to send you the
latest sources.  The alternative is the possibility that your hard work will
be tucked away in a subdirectory and mostly ignored, or completely ignored
if someone else has already done the port (and you'd be surprised how often
this has happened).


BETA TESTING:  JOINING INFO-ZIP
-------------------------------
If you'd like to keep up to date with our UnZip (and companion Zip utility)
development, join the ranks of beta testers, add your own thoughts and
contributions, or simply lurk, you may join one of our mailing lists.
There is an announcements-only list (Info-ZIP-announce) and a general
discussion/testing list (Info-ZIP). You must be a subscriber to post, and
you can subscribe via the links on our Frequently Asked Questions page:

        http://www.info-zip.org/pub/infozip/FAQ.html#lists

(Please note that as of late May 2004, the lists are unavailable pending
a move to a new site; we hope to have them restored shortly.  In the
interim ...)  Feel free to use our bug-reporting web page for bug reports
and to ask questions not answered on the FAQ page above:

        http://www.info-zip.org/zip-bug.html

For now the best option is to monitor and contribute to the various threads
on the new discussion forum site at:

      http://www.info-zip.org/board/board.pl

The second best way to contribute is through the various features at
SourceForge, such as the bug posting areas.

There is also a closed mailing list for internal discussions of our core
development team. This list is now kept secret to prevent us from being
flooded with spam messages.


-- Greg Roelofs (sometimes known as Cave Newt), principal UnZip developer
   guy, with inspiration from David Kirschbaum, was Author of this text.

-- Christian Spieler (shorthand: SPC), current UnZip maintenance coordinator,
   applied the most recent changes, with Ed Gordon providing a few additions.

========================================================================
* macos/README.TXT
========================================================================

A free Macintosh Port of Info-ZIP's
Zip and UnZip
By Dirk Haase, d_haase@sitec.net
Home page: www.sitec.net/maczip
Mirror page:
www.haase-online.de/dirk/maczip
================================



Abstract:
---------
MacZip is a cross-platform compatible tool that includes
both Zip (for compression) and UnZip (for extraction).

Zip is a compression and file packaging utility for Unix,
VMS, MSDOS, OS/2, Windows 9x, Windows NT, Atari, Macintosh,
Amiga, Acorn RISC OS, and other systems.

UnZip unpacks zip archives. The Zip and UnZip programs can
process archives produced by PKZIP, and PKZIP and PKUNZIP
can work with archives produced by zip. Zip version 2.2 is
compatible with PKZIP 2.04.

If you are new to MacZip please read first the file
"ReadMe.1st".



License:
--------
  Copyright (c) 1990-2001 Info-ZIP.  All rights reserved.

  See the accompanying file LICENSE, version 2000-Apr-09 or later
  (the contents of which are also included in unzip.h) for terms of use.
  If, for some reason, all these files are missing, the Info-ZIP license
  also may be found at:  ftp://ftp.info-zip.org/pub/infozip/license.html



Requirements
------------
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 is distributed as a fat binary with both
regular 68K and native PowerPC versions included.



Installation
------------
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. The GUI is very simple. It was not my intention to
make a full-blown GUI, however I think it is comfortable
enough to use it as regular tool.

This port supports also Apple-event. So you can install it
in your WWW-Browser as a helper app.

For more Info about the contents of this package, take a
look into the "macos/Contents" (or :macos:Contents) file.
Some notes on how to rebuild the Macintosh applications can
be found in INSTALL.



Usage:
------

Basically there are four ways to start MacZip:

a) Drag'n Drop
b) using the Dialog box (Menu: File -> Zip/Unzip):

Please read the file "ReadMe.1st"
for the description of the items a and b.

c) Using the Command line (Menu: File->Command Line):
   The Zip & UnZip tools are command line tools. So the
   behavior is exactly the same like the Zip & UnZip tools on
   Unix or Windows/DOS. This means, if you want to zip some
   files, you have to write a command line like this: "zip
   [switches] path_to_zip_archive path_to_files_folders"

   - Go to "File", select "Command Line" and the
     "MacZip Entry box" Dialog Box appears.

   An example:

   a: your zip may be created at
           Macintosh HD:applications:archive.zip

   b: your files may be found at
           Macintosh HD:somewhere:my_folder_to_archive:*

   Note: At the end of the path there must be a filename or
         a wildcard !
   (see Footnotes: 1 wildcard, 2 Mac path names)

   So the command line should look like (one line!):

   zip "Macintosh HD:applications:archive.zip" "Macintosh HD:somewhere:my_folder_to_archive:*"

   - Click on "Enter" to start the task.

   Since you can not set a default folder you have to enter
   always a full qualified path names. Full-qualified path
   names are path names including the Volume name ! (see
   Footnote: 2 Mac path names)



d) Using Applescript:

There is only one additional event defined: "do_cmd". You
can enter every valid command line. The first word must be
"zip" or "unzip" to select the action (compress or
extraction).

See sample Applescript:

    tell application "MacZip (PPC)"
        activate
        with timeout of 90000 seconds
            do_cmd "zip -rjjN Volume:archive \"My Volume:*\" "
        end timeout
    end tell

This script opens MacZip, brings it to the foreground on the
Mac, starts the zip action with the command line: zip -rjjN
Volume:archive "My Volume:*" .


A short introduction is also available online:
http://www.sitec.net/maczip/How-To-Do/

It's possible to stop the run of Zip/Unzip with the well
known shortcut [Command] + [.].


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

There are some Mac-specific switches available.
Zip Module:
       -df    [MacOS] Include only data-fork of files zipped into
              the  archive.   Good for exporting files to foreign
              operating-systems.  Resource-forks will be  ignored
              at all.

       -jj    [MacOS] record Fullpath (+ Volname).  The  complete
              path  including  volume  will be stored. By default
              the relative path will be stored.

       -S     [MSDOS, OS/2, WIN32 and ATARI] Include  system  and
              hidden files.
              [MacOS]  Includes finder invisible files, which are
              ignored otherwise.

Unzip Module:
       -E     [MacOS only] display contents of MacOS extra  field
              during restore operation.

       -i     [MacOS only] ignore filenames stored in MacOS extra
              fields.  Instead,  the  most  compatible   filename
              stored in the generic part of the entry's header is
              used.

       -J     [MacOS only] ignore MacOS extra fields.  All Macin-
              tosh  specific  info  is  skipped.  Data-fork   and
              resource-fork are restored as separate files.


Select [File]->[Get Help on Zip/Unzip] for a complete list
of switches.



Limitations / Problems:
-----------------------

    - Aliases are not supported. I tried, but I got broken
      aliases. This port will silently ignore all aliases.
      It's on my to-do list for future releases.

    - Zip needs much memory to compress many files: You may need
      to increase the 'Preferred Size' in 'Get Info'. Values of 12
      Megabytes or more are possible

    - Unzip needs about 500 Kbytes of memory to unzip no matter
      how many files were compressed and expanded.

    - and finally one big macintosh-related problem:
      This port has one weak point: It's based on path names.
      As you may be already know: Path names are not unique on a Mac !
      The main reason is that an attempt to implement support exact
      saving of the MacOS specific internal file structures would
      require a throughout rewrite of major parts of shared code,
      probably sacrifying compatibility with other systems. I have
      no solution at the moment. The port will just warn you if you
      try zip from / to a volume which has a duplicate name.
      MacZip has problems to find the archive or the files. My
      (Big) recommendation: Name all your volumes with a unique
      name and MacZip will run without any problem.


Known Bugs:

    - crypted files in a zip archive are sometimes corrupt:
      I get an error message: invalid compressed data to inflate.
      Appearance of this error is purely be chance: I did a small
      test: Unzipping an archive containing 3589 files 56 files
      fails to unzip, so about 1.5%. Root cause is completely
      unclear to me :(

I strongly recommend to test your archive (e.g. unzip -t archive).





Zip Programs / Macintosh Extra-Data:
-----------------------------------------
A brief overview:
Currently, as far as I know, there are 6 Zip programs
available for the Macintosh platform. These programs build
(of course) different variants of Zip files:

    - Info-ZIP's first Port of Zip. Ported by Johnny Lee
      This port is rather outdated and no longer supported (since 1992).
      68K only. Only minimal Mac-info is stored
      (Creator/Type, Finder attributes). Creator/Type: '????' / '????'
      Until year 1998, only UnZip 5.32 survived.

    - ZipIt by Tom Brown. This is Shareware and still supported I think.
      ZipIt has a nice GUI, but I found it can't handle large Zip files
      quite well. ZipIt compresses Macintosh files using the Mac Binary
      format. So, transferring files to other platforms is not so easy.
      Only minimal Mac-info is stored (Creator/Type, Finder attributes).
      Mac filenames are changed to a most compatible filename.
      Creator/Type: 'ZIP ' / 'ZIP '

    - PKZIP/mac v2.03/210d. This is Shareware.
      This Zip implementation for the Mac can be found on ASI's web site
      (http://www.asizip.com/products/products.htm).  The name of this
      program is misleading, it is NOT a product from PKWARE.  ASI's last
      release version is v2.03, and they also offer a newer beta version
      PKZIP/mac 210d. But even the Beta version is rather outdated (1995).
      Only minimal Mac-info is stored (Creator/Type, Finder attributes).
      The Zipfile format looks like incompatible to other platforms.
      (More details about the compatibility issue can be found in
      proginfo/3rdparty.bug!). Type: 'PKz1'
      Mac filenames are restored without any change.

    - Aladdin DropZip 1999, This is Shareware. Aladdin chose
      the format of ZipIt. Therefore, it has the some drawbacks
      like ZipIt.
      Creator/Type: 'SITx' / 'ZIP '

    - SmartZip 1.0 1999 - by Marco Bambini Vampire Software.
      This is Shareware. SmartZip compresses Macintosh files using the
      Mac Binary. Therefore, it has the same drawbacks like ZipIt.
      Creator/Type: 'dZIP' / 'ZIP '

and finally:
    - Info-ZIP's latest Port of Zip. MacZip 1.0. Ported by me :-)
      It is supported (of course) and up to date. Full set of macintosh
      info is stored: Creator/Type, Finder attributes, Finder comments,
      MacOS 8.0 Folder settings, Icon/Folder Positions ...
      Mac filenames are restored without any change.
      Creator/Type: 'IZip' / 'ZIP '


Compatibility of my port; Extraction:
   - Archives from Info-ZIP's first port (by Johnny Lee) are
     still compatible.
   - Extraction of ZipIt archives is supported. This support
     is not complete: Filenames are correct but Directory names
     are sometimes mangled to a DOS compatible form. Segmented
     archives are not supported.
   - PKZiP/mac archive files are extracted without resource-forks
     and without any Finder info. I have no information about
     that zip format.

Compatibility of my port; Compression:
   - My port supports only the new Info-ZIP format (introduced
     with this port). Therefore archives created by MacZip 1.0
     (March 1999) must be extracted with this version or later
     releases of Info-ZIP's UnZip to restore the complete set of
     Macintosh attributes.

Note: This port is complete unrelated to the shareware ZipIt.
Even more, handling of special Macintosh attributes is
incompatible with ZipIt. This port (MacZip) may be used to
extract archives created by ZipIt, but make sure that you
get the result as you expected.



Macintosh Files; File Forks:
----------------------------

All Macintosh files comprise two forks, known as the data
fork and the resource fork.  Unlike the bytes stored in the
resource fork, the bytes in the data fork do not have to
exhibit any particular internal structure. The application
is responsible for interpreting the bytes in the data fork
in whatever manner is appropriate. The bytes in the resource
fork usually have a defined internal structure and contain
data object like menus, dialog boxes, icons and pictures.
Although all Macintosh files contain both a data fork and a
resource fork, one or both of these forks may be empty.

MacZip stores data-forks and resource-forks separately. The
Zipfile format does not allow to store two archive entries
using exactly the same name. My solution is to modify the
Path name of the resource-fork. All resource-fork names are
prepended with a leading special directory named
"XtraStuf.mac". So, when extracting on a Mac, you should
never see this directory "XtraStuf.mac" on your *disk*.

On all foreign systems that support directories in filenames
(e.g.: OS/2, Unix, DOS/Windows, VMS) you will get a
directory "XtraStuf.mac" when extracting MacZip archives.
You can delete the complete directory "XtraStuf.mac" since
Mac resources do not make much sense outside the MacOS
world.



Text encoding; Charsets of the Filenames:
-----------------------------------------

The following information is only important if you plan to
transfer archives across different platforms/language systems:

A typical Zip archive does not support different charsets.
All filenames stored in the public area (= accessible by
foreign systems other than MacOS) must be coded in the
charset ISO-8859-1 (CP1252 in the Microsoft Windows world)
or CP850 (DOSLatin1). The latter should only be used by Zip
programs that mark the archive entries as "created under
DOS". Apart from Macs, the commonly used platforms either
support ISO-8859-1 directly, or are compatible with it. To
achieve maximum compatibility, MacZip convert filenames from
the Mac OS Roman character set to ISO-8859-1 and vice versa.
But not every char of the charset MacRoman has their
equivalent in ISO-8859-1. To make the mapping in most cases
possible, I chose most similar chars or at least the MIDDLE
DOT.

Mac OS Roman character set is used for at least the
following Mac OS localizations: U.S., British, Canadian
French, French, Swiss French, German, Swiss German, Italian,
Swiss Italian, Dutch, Swedish, Norwegian, Danish, Finnish,
Spanish, Catalan, Portuguese, Brazilian, and the default
International system.

In all Mac OS encodings, character codes 0x00-0x7F are
identical to ASCII, except that
  - in Mac OS Japanese, yen sign replaces reverse solidus
  - in Mac OS Arabic, Farsi, and Hebrew, some of the
    punctuation in this range is treated as having strong
    left-right directionality, although the corresponding
    Unicode characters have neutral directionality
So, for best compatibility, confine filenames to the standard
7-bit ASCII character set.

If you generate a filename list of your archive (unzip -l),
you will see the converted filenames. Your can also extract
the archive with the switch '-i' (= ignore mac filenames),
and test your result.

This MacZip port uses its own filename stored in the
archive. At the moment, the filename will be not converted.
However, I'm planning to add support for Unicode.

Currently, the following Mac OS encodings are NOT supported:
Japanese, ChineseTrad, Korean, Arabic, Hebrew, Greek,
Cyrillic, Devanagari, Gurmukhi, Gujarati, Oriya, Bengali,
Tamil, Telugu Kannada, Malayalam, Sinhalese, Burmese, Khmer,
Thai, Laotian, Georgian, Armenian, ChineseSimp, Tibetan,
Mongolian, Ethiopic, Vietnamese, ExtArabic and finally:
Symbol - this is the encoding for the font named "Symbol".
Dingbats - this is the encoding for the font named "Zapf Dingbats".
If you extract an archive coded with one of these
charsets you will probably get filenames with funny
characters.

These problems apply only to filenames and NOT to the file
content.
of course: The content of the files will NEVER be converted !!



File-/Creator Type:
-------------

This port uses the creator type 'IZip' and it is registered
at Apple (since 08. March 1998). File types can not be
registered any more. This port uses 'ZIP ' for Zip archive
files. The creator 'IZip' type should be used for all future
versions of MacZip.



Hints for proper restoration of file-time stamps:
-------------------------------------------------

UnZip requires the host computer to have proper time zone
information in order to handle certain tasks correctly (see
unzip.txt).  To set the time zone on the Macintosh, go to
the Map Control Panel and enter the correct number of hours
(and, in a few locales, minutes) offset from Universal
Time/Greenwich Mean Time.  For example, the US Pacific time
zone is -8 hours from UTC/GMT during standard (winter) time
and -7 hours from UTC/GMT during Daylight Savings Time.  The
US Eastern time zone is -5 hours during the winter and -4
hours during the summer.

Discussion of Daylight Savings Time
-----------------------------------
The setting in the Date & Time control panel for Daylight
Savings time is a universal setting. That is, it assumes
everybody in the world is observing Daylight Savings time
when its check box is selected.

If other areas of the world are not observing Daylight
Savings time when the check box is selected in the Date &
Time control panel, then the Map control panel will be off
by an hour for all areas that are not recognizing Daylight
Savings time.

Conversely, if you set the Map control panel to an area that
does not observe Daylight Savings time and deselect/uncheck
the check box for Daylight Savings time in the Date & Time
control panel, then time in all areas celebrating Daylight
Savings time will be off by an hour in the Map control
panel.

Example:
     In the case of Hawaiians, sometimes they are three hours
     behind Pacific Standard Time (PST) and sometimes two hours
     behind Pacific Daylight Time (PDT). The Map control panel
     can only calculate differences between time zones relative
     to Greenwich Mean Time (GMT). Hawaii will always show up as
     three hours past the Pacific time zone and five hours past
     the Central time zone.

     When Hawaiians are not observing Daylight Savings time, but
     the rest of the country is, there is no combination of
     settings in Map and Date & Time control panels which will
     enable you to display Hawaiian local time correctly AND
     concurrently display the correct time in other places that
     do observe Daylight Savings time.

     The knowledge about which countries observe Daylight Savings
     time and which do not is not built into the Map control
     panel, so it does not allow for such a complex calculation.

     This same situation also occurs in other parts of the world
     besides Hawaii. Phoenix, Arizona is an example of an area of
     the U.S. which also does not observe Daylight Savings time.

Conclusion:
MacZip only knows the GMT and DST offsets of the
current time, not for the time in question.


Projects & Packages:
--------------------

A Note to version numbers: Version of MacZip is currently
1.06 and is based on the zip code version 2.3 and unzip code
version 5.42. See About Box for current version and compiler
build date.

Because of the amount of sources I splitted this port into
several projects. See http://www.sitec.net/maczip for
updates.

- core source parts:
    unzxxx.zip
    zipxxx.zip
      These archives contains the main parts of the port. You can
      build libraries and a standalone App with Metrowerks
      standard console SIOUX. They contain only sources, no
      executables. These archives are exact copies of the standard
      Info-ZIP source distributions; they were only repackaged
      under MacOS using MacZip, with one minor addition: For those
      files that are stored in BinHex'ed format in the Info-ZIP
      reference source archives, unpacked version that are ready
      for use have been added.

- additional source part:
    MacZipxxx.zip: contains all the GUI stuff and the project
      files to build the main-app.  Only sources of the GUI, no
      zip or unzip code. To build MacZip successfully you will
      need to also download the zip and unzip packages.

- executables:
    MacZipxxxnc.hqx: contains only executables and 'README.TXT',
                     This version is without en-/decryption support !
    MacZipxxxc.hqx:  contains only executables and 'README.TXT',
                     This version supports en-/decryption !

- encryption sources:
    zcryptxx.zip: To build crypt versions of MacZip.
    download from ftp://ftp.icce.rug.nl/infozip/ (and subdirectories)

- documentation:
    MacZipDocu.zip: contains some further docus about the algorithm,
                    limits, Info-ZIP's appnote and a How-to-do Webpage.


Credits:
--------

Macstuff.c and recurse.c: All the functions are from More Files.
More Files fixes many of the broken or underfunctional parts of
the file system. Thanks to Jim Luther. (see morefiles.doc)




---------------------------------------------------------------------------
Footnotes:

1. wildcard:
    The '*' is a wildcard and means 'all files'
    Just in case you don't know wildcards:
    '*' is a place holder for any character.
    e.g.:
    "this*" matches with "this_file" or  "this_textfile" but it
    doesn't match with "only_this_file" or  "first_this_textfile"
    "*this*" matches with "this_file" or  "this_textfile" AND
    matches with "only_this_file" or  "first_this_textfile"


2. Mac pathnames:
The following characteristics of Macintosh pathnames should
be noted:

    A full pathname never begins with a colon, but must contain
    at least one colon.
    A partial pathname always begins with a colon separator except
    in the case where the file partial pathname is a simple file or
    directory name.
    Single trailing separator colons in full or partial pathnames
    are ignored except in the case of full pathnames to volumes.
    In full pathnames to volumes, the trailing separator colon is
    required.
    Consecutive separator colons can be used to ascend a level
    from a directory to its parent directory. Two consecutive
    separator colons will ascend one level, three consecutive
    separator colons will ascend two levels, and so on. Ascending
    can only occur from a directory; not a file.





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

Dirk Haase
==========

========================================================================
* wince/README
========================================================================

_______________________________________________________________________________

   This is the Windows CE Info-ZIP port README, last updated 17 September 2003.
_______________________________________________________________________________

   Copyright and Disclaimer
_______________________________________________________________________________

Copyright

     All the source files for Pocket UnZip are copyrighted by Info-ZIP.
     For details on terms and conditions look into the LICENSE file
     that should be part of the source distribution.
     The original author Steve P. Miller has gracefully allowed to
     put his own source contributions for "Pocket UnZip" under the
     Info-ZIP license.

Disclaimer

     All project files are provided "as is" with no guarantee of
     their correctness.  The authors are not liable for any outcome
     that is the result of using this source.  The source for Pocket
     UnZip has been placed in the public domain to help provide an
     understanding of its implementation.  You are hereby granted
     full permission to use this source in any way you wish, except
     to alter Pocket UnZip itself.  For comments, suggestions, and
     bug reports, please write to stevemil@pobox.com or to the
     generic Info-ZIP e-mail address Zip-Bugs@lists.wku.edu.

_______________________________________________________________________________

   About the Windows CE Port (known as "Pocket UnZip")
_______________________________________________________________________________

The Windows CE port, known as Pocket UnZip, is designed to run on Microsoft's
Windows CE operating system.  The port is completely contained in the files
listed above.  There were very few minor modifications made to the Info-ZIP
code in order for this port to work.  This was possible because the Info-ZIP
code is fairly generic and also because several hooks have already been placed
in the code from past Windows ports.  The Windows CE port leverages off of
these efforts for two reasons.  Mainly, I wanted to avoid modifying the
Info-ZIP core code since people don't like it when your changes break other
ports.  Second, this makes the Windows CE port easy to upgrade when fixes and
features are released by the Info-ZIP group.

The port is made up of the project file (punzip.dsp), one global header
(punzip.h), three main source modules (winmain.cpp/h, intrface.cpp/h,
and wince.cpp/h), the resource script files (punzip.rc, punzip.rcv, and
resource.h), several resources (punzip.ic2, zipfile.ic2, imglist.2bp,
ilmask.bmp, toolbar.2bp, punzip.ico, zipfile.ico, imglist.bmp, and
toolbar.bmp), and the help file (punzip.htp).

The application's entry point is WinMain(), which is located in winmain.cpp
(what a surprise).  winmain.cpp basically contains all the Windows code and
the user interface.  It knows nothing about the Info-ZIP code or things like
the Globals struct.  That stuff is the job of the intrface module.
intrface.cpp implements an easy (or at least easier) to understand interface
to the Info-ZIP routines.  It also handles all the callbacks from Info-ZIP
and relays the appropriate information back to the code in winmain.cpp.
The final module is wince.cpp.  This module implements all the Win32 APIs
and C runtime functions that are called by the rest of the code, but are
not natively implemented on Windows CE.  Most all of this module is excluded
for NT native builds.

Two preprocessor defines are used in conjunction with several defines from
the Info-ZIP code and from other ports.  The two that are specific to the
Windows CE port are:

     POCKET_UNZIP   Always set for the Windows CE port (CE and NT).
     _WIN32_WCE     Set for Windows CE native; not set for Windows NT native.

These three defines are the minimum defines that must be addressed by the
project file in order to build this port.  This port's main header, punzip.h,
gets included by all the Info-ZIP source files when POCKET_UNZIP is defined.
punzip.h in turn ensures that all the other relevant Info-ZIP defines are set
to correctly build the port.  If you wish to alter the Info-ZIP defines used
to build this port, you can do so by altering punzip.h.

There are quite a few _WIN32_WCE checks throughout the source files for this
port.  These checks allow the application to build natively for Windows NT for
debugging purposes, and just because it can with little effort due to the
similarities between the Windows CE API and the Windows NT API. Any non-Windows
CE code is assumed to be for Windows NT only.  This project currently will not
work on Windows 95 because Windows CE is mostly UNICODE, and this port assumes
that all Win32 calls to the operating system take UNICODE parameters.  I could
scatter a few dozen "#ifdef UNICODE" checks around and make it work on Windows
95, but I see no reason to complicate this port's code for that reason since
there is already a Windows 95 port of the Info-ZIP code.

_______________________________________________________________________________

   Building the Windows CE Port (known as "Pocket UnZip")
_______________________________________________________________________________

At the time this README was written, Microsoft just released Visual C++ for
Windows CE version 1.0.  This development kit uses the the standard Microsoft
Visual C++ version 5.0 or 6.0 development environment and project files
(DSP files). To build Windows CE binaries of Pocket UnZip, you will need
version 1.0 or later of Visual C++ for Windows CE.

This port's project file, punzip.dsp, contains the information for building all
the various binaries.  These include Windows NT native, Windows CE native for
Hitachi SH-3 processors, and Windows CE native for MIPS processors.  All
projects have Debug and Retail flavors as well.  The following table lists the
Windows CE devices and which binary they run:

     Manufacturer             CPU             Binary
     ---------------------    ------------    ------
     Philips Electronics      MIPS R3910      MIPS
     NEC Corp.                NEC VR4101      MIPS
     Casio Computer Co.       Hitachi SH-3    SH-3
     Compaq Computer Corp.    Hitachi SH-3    SH-3
     Hewlett-Packard Co.      Hitachi SH-3    SH-3
     Hitachi Ltd.             Hitachi SH-3    SH-3
     LG Electronics Inc.      Hitachi SH-3    SH-3

The revision of this port made for UnZip 5.51 does now also provide a project
file for use with Microsoft's free "Visual C++ embedded 3.0" development system
for Windows CE.

Pocket UnZip should build out of the box.  If you have just unzipped the
Info-ZIP's UnZip sources, you should have a root directory with the core
Info-ZIP files in it and several subdirectories under it for the various
ports, one of which is the WinCE directory.  The project files punzip.dsp
are located in the subdirectory vc5 resp. vc6 below the wince directory.
Open the punzip.dsp file from the subdirectory matching your Visual C++
base version.  The project file uses all the files in the WinCE
subdirectory as well as the following files in the Info-ZIP root:

     api.c        crypt.h      globals.c    process.c    unzip.h
     consts.h     ebcdic.h     globals.h    ttyio.c      unzpriv.h
     crc32.c      explode.c    inflate.c    ttyio.h      unzvers.h
     crc32.h      extract.c    inflate.h    unreduce.c   zip.h
     crypt.c      fileio.c     list.c       unshrink.c

_______________________________________________________________________________

   Contacting the Authors
_______________________________________________________________________________

The Info-ZIP group is made up of dozens of people, past and present, who
have devoted countless hours to providing the public with free and portable
compression software.  The author of the Windows CE port, Pocket UnZip, is
Steve P. Miller.

If you have questions, comments, suggestions, or bug reports concerning Pocket
UnZip itself, you can write Steve Miller at:

     stevemil@pobox.com

If you find a bug that appears to be more Info-ZIP related (i.e. the actual
decompression part of Pocket UnZip), you can send mail to:

     Zip-Bugs@lists.wku.edu

For all other general discussion type questions or comments, you can send mail
to (as well as join) the following mailing list:

     Info-Zip@lists.wku.edu

See the main UnZip README file for info on how to join the latter list.

_______________________________________________________________________________

Beginning with UnZip 5.51, the source distribution contains a second port for
WinCE, providing a "command line UnZip tool" for batch processing on Windows CE
systems.
This port was contributed in September 2002 by:
    Simon Roberts
    IBM Global Services, EMEA
    Phone: (INT 44- 2392 )(UK  02392 ) 563937: Tie-line(UK): 25-3937
    Notes: Simon Roberts/UK/IBM@IBMGB
    Internet: Simon_Roberts@uk.ibm.com

The tight integration of this contribution into the main UnZip distribution
code required some reorganization and was carried out by the UnZip maintenance
coordinator Christian Spieler.

The build of the Win CE command line program requires compiling
and linking together the following source modules:

    wince/wcemain.c             main entry point
    unzip.c                     unzip command line interface
    crc32.c                     CRC-32 calculation
    crypt.c                     decryption support
    extract.c                   general archive extraction handling
    fileio.c                    internal I/O helper routines
    globals.c                   global communication resources setup
    list.c                      archive listing
    match.c                     wildcard pattern matching
    process.c                   general archives processing code
    ttyio.c                     interactive console I/O
    explode.c                   decompression for "Imploded" data (LZ77)
    inflate.c                   decompression for "Deflate" methods
    unreduce.c                  decompression for "Reduced" data
    unshrink.c                  decompression for "Shrunk" data (LZW)
    wince/intrface.cpp          WinCE specific UnZip code
    wince/wince.cpp             WinCE specific C RTL lib replacements

These source modules depend on the following header files:

    zip.h                       wrapper for unzip.h used by some modules
    unzip.h                     main UnZip project header
    unzpriv.h                   extended defines for project internals
    globals.h                   global resource structures
    wince/wcecfg.h              Windows CE specific configuration
    wince/wince.h               WinCE C(++) library roundups

    consts.h                    global constant data
    crc32.h                     CRC-32 calculation interface
    crypt.h                     decryption interface
    ebcdic.h                    ASCII <--> EBCDIC translation
    ttyio.h                     console I/O interface
    unzvers.h                   version/release information
    wince/intrface.h            public entities in wince/intrface.cpp


========================================================================
* COPYING.OLD
========================================================================

__________________________________________________________________________

  This is the Info-ZIP file COPYING (for UnZip), last updated 17 Jul 2000.
__________________________________________________________________________

   FIRST NOTE:
   This file contains some details about the copyright history of
   contributions to the UnZip project.
   Additionally, it summarises some exceptions to the general BSD-like
   copyright found in LICENSE that covers our generic code and most of
   the system specific ports.
   Please read LICENSE first to find out what is allowed to do with
   Info-ZIP's UnZip code.

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

   There are currently two explicit copyrights on portions of UnZip
   code (at least, of which Info-ZIP is aware):
   Jim Luther's Mac OS File Manager interface code; and Christopher Evans'
   MacBinaryIII coding code (for the MacOS port)..  These copyrights
   are discussed in more detail below.

   All remaining code is now (starting with UnZip version 5.41) covered
   by the new Info-ZIP license. For details, please read the acompaning
   file LICENSE. The terms and conditions in this license supersede the
   copyright conditions of the contributions by Igor Mandrichenko
   (vms/vms.c), Greg Roelofs (zipinfo.c, new version of unshrink.c),
   Mike White (Windows DLL code in "windll/*"), Steve P. Miller (Pocket
   UnZip GUI "wince/*"), and Mark Adler (inflate/explode decompresseion
   core routines, previously put into the public domain). All these
   Info-ZIP contributors (or "primary" authors) have permitted us to
   replace their copyright notes by the Info-ZIP License.

   Frequently Asked Questions regarding (re)distribution of Zip and UnZip
   are near the end of this file.

   There are no known patents on any of the code in UnZip.  Unisys
   claims a patent on LZW encoding and on LZW decoding _in an apparatus
   that performs LZW encoding_, but the patent appears to exempt a stand-
   alone decoder (as in UnZip's unshrink.c).  Unisys has publicly claimed
   otherwise, but the issue has never been tested in court.  Since this
   point is unclear, unshrinking is not enabled by default.  It is the
   responsibility of the user to make his or her peace with Unisys and
   its licensing requirements.  (unshrink.c may be removed from future
   releases altogether.)
__________________________________________________________________________

   The original unzip source code has been extensively modified and
   almost entirely rewritten (changes include random zipfile access
   rather than sequential; replacement of unimplode() with explode();
   replacement of old unshrink() with new (unrelated) unshrink(); re-
   placement of output routines; addition of inflate(), wildcards,
   filename-mapping, text translation, ...; etc.).  As far as we can
   tell, only the core code of the unreduce method remained substantially
   similar to Mr. Smith's original source.  As of UnZip 5.42, the complete
   core code is now covered by the Info-ZIP Licence.  Therefore, support
   for the reduce method has been removed.
   The drop of the reduce method should only affect some test archives,
   reducing was never used in any publically distributed Zip program.
   For pathologic cases where support for reduced archive entries is
   needed, the unreduce code copyrighted by Samuel H. Smith is available
   as a separate distribution (the restricted copyright of this code is
   cited below in the "historical" section).

   The following copyright applies to the Mac OS File Manager interface code
   (macos/source/macstuff.[ch]), distributed with UnZip 5.4 and later:

     * MoreFiles
     *
     * A collection of File Manager and related routines
     *
     * by Jim Luther (Apple Macintosh Developer Technical Support Emeritus)
     * with significant code contributions by Nitin Ganatra
     * (Apple Macintosh Developer Technical Support Emeritus)
     * Copyright  1992-1998 Apple Computer, Inc.
     * Portions copyright  1995 Jim Luther
     * All rights reserved.
     * The Package "More Files" is distributed under the following
     * license terms:
     *
     *          "You may incorporate this sample code into your
     *           applications without restriction, though the
     *           sample code has been provided "AS IS" and the
     *           responsibility for its operation is 100% yours.
     *           However, what you are not permitted to do is to
     *           redistribute the source as "DSC Sample Code" after
     *           having made changes. If you're going to
     *           redistribute the source, we require that you make
     *           it clear in the source that the code was descended
     *           from Apple Sample Code, but that you've made
     *           changes."

   The usage terms of this copyright note are compatible with the
   Info-ZIP license, they do not add further restrictions.


   The following copyright applies to the Mac OS "macbin3" decoding code
   (extra field compatibility with ZipIt):

     *  MacBinaryIII.h
     *
     *  Copyright 1997 Christopher Evans (cevans@poppybank.com)
     *
     *  Basic encoding and decoding of Macintosh files to the
     *  MacBinary III spec.
     * ----------------------------------------------------------------------
     * This source is copyrighted by Christopher Evans (cevans@poppybank.com)
     * (available at ftp://ftp.lazerware.com/MacBinaryIII_src_C.sit
     * homepage of Leonard Rosenthol  leonardr@netcom.com)

  This copyright note does not contain any usage terms.  So, we assume
  that this code is freely reusable until we are proved wrong...

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

   The remaining copyright notes have been superseeded by the new
   Info-ZIP license, with explicit permission from the respective
   original authors.  They are cited here for historical reasons,
   only:

   The following copyright applies to the full-featured unreduce.c
   (now distributed separately):

     * Copyright 1989 Samuel H. Smith;  All rights reserved
     *
     * Do not distribute modified versions without my permission.
     * Do not remove or alter this notice or any other copyright notice.
     * If you use this in your own program you must distribute source code.
     * Do not use any of this in a commercial product.

   Regarding the first stipulation, Mr. Smith was tracked down in southern
   California some years back [Samuel H. Smith, The Tool Shop; as of mid-
   May 1994, (213) 851-9969 (voice), (213) 887-2127(?) (subscription BBS),
   71150.2731@compuserve.com]:

   "He says that he thought that whoever contacted him understood that
    he has no objection to the Info-ZIP group's inclusion of his code.
    His primary concern is that it remain freely distributable, he said."

   Despite the fact that our "normal" code has been entirely rewritten
   and by default no longer contains any of Mr. Smith's code, Info-ZIP
   remains indebted and grateful to him.  We hope he finds our contribu-
   tions as useful as we have his.

   Note that the third and fourth stipulations still apply to any com-
   pany that wishes to incorporate the unreduce code into its products;
   if you wish to do so, you must contact Mr. Smith directly regarding
   licensing.

  -----

   The following copyright applied to most of the VMS code in vms.c,
   distributed with UnZip version 4.2 and later:

     * Copyright (c) 1992-93 Igor Mandrichenko.
     * Permission is granted to any individual or institution to use, copy,
     * or redistribute this software so long as all of the original files
     * are included unmodified and that this copyright notice is retained.

  -----

   The following copyright applied to the new version of unshrink.c,
   distributed with UnZip version 5.2 and later:

     * Copyright (c) 1994 Greg Roelofs.
     * Permission is granted to any individual/institution/corporate
     * entity to use, copy, redistribute or modify this software for
     * any purpose whatsoever, subject to the conditions noted in the
     * Frequently Asked Questions section below, plus one additional
     * condition:  namely, that my name not be removed from the source
     * code.  (Other names may, of course, be added as modifications
     * are made.)  Corporate legal staff (like at IBM :-) ) who have
     * problems understanding this can contact me through Zip-Bugs...

  -----

   The following copyright applied to the Windows DLL code (windll/*),
   distributed with UnZip version 5.2 and later:

     * Copyright (c) 1996 Mike White.
     * Permission is granted to any individual or institution to use,
     * copy, or redistribute this software so long as all of the original
     * files are included, that it is not sold for profit, and that this
     * copyright notice is retained.

  -----

   The following copyright applied to the Windows CE GUI port, ``Pocket
   UnZip,'' distributed with UnZip version 5.3 and later:

     * All the source files for Pocket UnZip, except for components
     * written by the Info-ZIP group, are copyrighted 1997 by Steve P.
     * Miller.  The product "Pocket UnZip" itself is property of the
     * author and cannot be altered in any way without written consent
     * from Steve P. Miller.

  -----

   The remaining code was written by many people associated with the
   Info-ZIP group, with large contributions from (but not limited to):
   Greg Roelofs (overall program logic, ZipInfo, unshrink, filename
   mapping/portability, etc.), Mark Adler (inflate, explode, funzip),
   Kai Uwe Rommel (OS/2), John Bush and Paul Kienitz (Amiga), Antoine
   Verheijen (Macintosh), Hunter Goatley (more VMS), Mike White (Windows
   DLLs), Christian Spieler (overall logic, optimization, VMS, etc.) and
   others.  See the file CONTRIBS in the source distribution for a much
   more complete list of contributors.
   The decompression core code for the deflate method (inflate.[ch],
   explode.c) was originally written by Mark Adler who submitted it
   as public domain code.

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

========================================================================
* LICENSE
========================================================================

This is version 2009-Jan-02 of the Info-ZIP license.
The definitive version of this document should be available at
ftp://ftp.info-zip.org/pub/infozip/license.html indefinitely and
a copy at http://www.info-zip.org/pub/infozip/license.html.


Copyright (c) 1990-2009 Info-ZIP.  All rights reserved.

For the purposes of this copyright and license, "Info-ZIP" is defined as
the following set of individuals:

   Mark Adler, John Bush, Karl Davis, Harald Denker, Jean-Michel Dubois,
   Jean-loup Gailly, Hunter Goatley, Ed Gordon, Ian Gorman, Chris Herborth,
   Dirk Haase, Greg Hartwig, Robert Heath, Jonathan Hudson, Paul Kienitz,
   David Kirschbaum, Johnny Lee, Onno van der Linden, Igor Mandrichenko,
   Steve P. Miller, Sergio Monesi, Keith Owens, George Petrov, Greg Roelofs,
   Kai Uwe Rommel, Steve Salisbury, Dave Smith, Steven M. Schweda,
   Christian Spieler, Cosmin Truta, Antoine Verheijen, Paul von Behren,
   Rich Wales, Mike White.

This software is provided "as is," without warranty of any kind, express
or implied.  In no event shall Info-ZIP or its contributors be held liable
for any direct, indirect, incidental, special or consequential damages
arising out of the use of or inability to use this software.

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

    1. Redistributions of source code (in whole or in part) must retain
       the above copyright notice, definition, disclaimer, and this list
       of conditions.

    2. Redistributions in binary form (compiled executables and libraries)
       must reproduce the above copyright notice, definition, disclaimer,
       and this list of conditions in documentation and/or other materials
       provided with the distribution.  Additional documentation is not needed
       for executables where a command line license option provides these and
       a note regarding this option is in the executable's startup banner.  The
       sole exception to this condition is redistribution of a standard
       UnZipSFX binary (including SFXWiz) as part of a self-extracting archive;
       that is permitted without inclusion of this license, as long as the
       normal SFX banner has not been removed from the binary or disabled.

    3. Altered versions--including, but not limited to, ports to new operating
       systems, existing ports with new graphical interfaces, versions with
       modified or added functionality, and dynamic, shared, or static library
       versions not from Info-ZIP--must be plainly marked as such and must not
       be misrepresented as being the original source or, if binaries,
       compiled from the original source.  Such altered versions also must not
       be misrepresented as being Info-ZIP releases--including, but not
       limited to, labeling of the altered versions with the names "Info-ZIP"
       (or any variation thereof, including, but not limited to, different
       capitalizations), "Pocket UnZip," "WiZ" or "MacZip" without the
       explicit permission of Info-ZIP.  Such altered versions are further
       prohibited from misrepresentative use of the Zip-Bugs or Info-ZIP
       e-mail addresses or the Info-ZIP URL(s), such as to imply Info-ZIP
       will provide support for the altered versions.

    4. Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip,"
       "UnZipSFX," "WiZ," "Pocket UnZip," "Pocket Zip," and "MacZip" for its
       own source and binary releases.