======================================================================== * README ======================================================================== Zip 3.0 is the first Zip update adding large file support. For now Zip 2.3x remains available and supported, but users should switch to this new release. Testing for Zip 3.0 has focused mainly on Unix, VMS, Max OS X, and Win32, and some other ports may not be fully supported yet. If you find your favorite port is broke, send us the details or, better, send bug fixes. It's possible that support for some older ports may be dropped in the future. Copyright (c) 1990-2008 Info-ZIP. All rights reserved. See the accompanying file LICENSE (the contents of which are also included in unzip.h, zip.h and wiz.h) for terms of use. If, for some reason, all of these files are missing, the Info-ZIP license also may be found at: ftp://ftp.info-zip.org/pub/infozip/license.html and http://www.info-zip.org/pub/infozip/license.html. Zip 3.0 is a compression and file packaging utility. It is compatible with PKZIP 2.04g (Phil Katz ZIP) for MSDOS systems. There is a companion to zip called unzip (of course) which you should be able to find in the same place you got zip. See the file 'WHERE' for details on ftp sites and mail servers. So far zip has been ported to a wide array of Unix and other mainframes, minis, and micros including VMS, OS/2, Minix, MSDOS, Windows, Atari, Amiga, BeOS and VM/CMS. Although highly compatible with PKware's PKZIP and PKUNZIP utilities of MSDOS fame, our primary objective has been one of portability and other-than-MSDOS functionality. Features not found in the PKWare version include creation of zip files in a pipe or on a device; VMS, BeOS and OS/2 extended file attributes; conversion from Unix to MSDOS text file format; and, of course, the ability to run on most of your favorite operating systems. And it's free. See the file zip30.ann for a summary of new features in Zip 3.0 and WhatsNew for the detailed list of new features and changes since Zip 2.32. The file CHANGES details all day-to-day changes during development. Notes: Multi-volume support. This version does not support multi-volume spanned archives as in pkzip 2.04g, and there is no intention at this point to support spanned archives, but Zip 3.0 supports split archives. A split archive is an archive split into a set of files, each file a piece of the archive and each file using an extension, such as .z02 as in the file name archive.z02, that provides the order of the splits. In contrast, a spanned archive is the original multi-floppy archive supported by pkzip 2.0g where the split order is contained in the volume labels. The contents of split and spanned archives are mostly identical and there is a simple procedure to convert between the formats. Many current unzips now support split archives. Zip64 support. This version supports Zip64 archives as described in the PKWare AppNote. These archives use additional fields to support archives greater than 2 GB and files in archives over the 2 GB previous limit (4 GB on some ports). The Zip64 format also allows more than 64k entries in an archive. Support by the OS for files larger than 4 GB is needed for Zip to create and read large files and archives. On Unix, Win32, and some other ports, large file and Zip64 support is automatically checked for and compiled in if available. Use of Zip64 by Zip is automatic and to maximize backward compatibility the Zip64 fields will only be used if needed. A Zip64 archive requires a pkzip 4.5 compatible unzip, such as UnZip 6.0. Unicode support. This version has initial Unicode support. This allows paths and names of files in other character sets to be accurately recreated on OS that have sufficient character set support. On Win32, if wide character calls are supported (not Win 9x unless Unicode support has been added) all files (including paths with illegal characters in the current character set) should now be readable by zip. Unicode support is provided using a new set of UTF-8 path and comment extra fields and a new UTF-8 bit for flagging when the current character set is already UTF-8. Zip 3.0 maintains backward compatibility with older archives and is mostly compliant with the new Unicode additions in the latest PKWare AppNote. The exception is UTF-8 comments, which are not supported if UTF-8 is not the native character set, but should be fully implemented in Zip 3.1. 16-bit OS support. Though Zip 3.0 is designed to support the latest zip standards and modern OS, some effort has been made to maintain support for older and smaller systems. If you find Zip 3.0 does not fit on or otherwise does not work well on a particular OS, send in the details and we might be able to help. Compression methods. In addition to the standard store and deflate methods, Zip now can use the bzip2 compression format using the bzip2 library. Though bzip2 compression generally takes longer, in many cases using bzip2 results in much better compression. However, many unzips may not yet support bzip2 compressed entries in archives, so test your unzip first before using bzip2 compression. Installation. Please read the file INSTALL for information on how to compile and install zip, zipsplit, zipcloak, and zipnote and please read the manual pages ZIP.txt, ZIPSPLIT.txt, ZIPCLOAK.txt, and ZIPNOTE.txt for information on how to use them. Also, if you are using MSDOS or Windows, note that text files in the distribution are generally in Unix line end format (LF only) and Windows and DOS users will need to either convert the files as needed to DOS line ends (CR LF) or extract the distribution contents using unzip -a. Utilities. At this point zipsplit, zipcloak, and zipnote should work with large files, but they currently do not handle split archives. A work around is to use zip to convert a split archive to a single file archive and then use the utilities on that archive. Encryption. This version supports standard zip encryption. Until recently the encryption code was distributed separately because of the US export regulations but now is part of the main distribution. See crypt.c for details. Decryption can be made with unzip 5.0p1 or later, or with zipcloak. Bug reports. All bug reports or patches should go to zip-bugs via the web site contact form at http://www.info-zip.org/zip-bug.html (we have discontinued the old email address zip-bugs@lists.wku.edu because of too much spam lately) and suggestions for new features can be submitted there also (although we don't promise to use all of them). We also are on SourceForge at http://sourceforge.net/projects/infozip/ and now automatically get Bug Reports and Feature Requests submitted there. In addition, a new Info-ZIP discussion forum is available as well. See below. Though bug reports can be posted there, we don't have automatic monitoring of all postings set up yet so you may want to use the web form or SoureForge for a quicker response. A good approach may be to post the details on the forum so others can benefit from the posting, then use the web reply form to let us know you did that if you don't get a reply in a reasonable time. Ports. If you're considering a port, please check in with zip-bugs FIRST, since the code is constantly being updated behind the scenes. We'll arrange to give you access to the latest source. Discussion group. If you'd like to keep up to date with our Zip (and companion UnZip utility) development, join the ranks of BETA testers, add your own thoughts and contributions, etc., check out the new discussion forum. This is the latest offering, after the various Info-ZIP mailing-lists on mxserver@lists.wku.edu (courtesy of Hunter Goatley) were no longer available and the temporary QuickTopic discussion group for Info-ZIP issues at http://www.quicktopic.com/27/H/V6ZQZ54uKNL died a horrible death due to large amounts of spam. The new discussion forum is now available at http://www.info-zip.org/board/board.pl (thanks again to Hunter Goatley) and can be used to discuss issues, request features, and is one place new betas and releases are announced. It also is a place to post bug reports, and patches can be submitted as attachments. However, we don't yet get automatic notification of all postings there so try one of the other methods if you don't get a response. You can also post Bug Reports and Feature Requests at Source Forge. However, the web site contact form remains available if you would rather not post on the public forums. Frequently asked questions on zip and unzip: Q. When unzipping I get an error message about "compression method 8". A. This is standard deflate, which has been around for awhile. Please get a current version of unzip. See the file 'WHERE' for details. Q. How about "compression method 12"? A. Compression method 12 is bzip2 and requires a relatively modern unzip. Please get the latest version of unzip. Q. I can't extract this zip file that I just downloaded. I get "zipfile is part of multi-disk archive" or some other message. A. Please make sure that you made the transfer in binary mode. Check in particular that your copy has exactly the same size as the original. Note that the above message also may actually mean you have only part of a multi-part archive. Also note that UnZip 5.x does not and UnZip 6.0 probably won't have multi-disk (split) archive support. A work around is to use Zip 3.0 to convert the split archive to a single-file archive then use UnZip on that archive. As a last result, if there's something readable in what you have, zip -FF should be able to recover it. Q. When running unzip, I get a message about "End-of-central-directory signature not found". A. This usually means that your zip archive is damaged, or that you have an uncompressed file with the same name in the same directory. In the first case, it makes more sense to contact the person you obtained the zip file from rather than the Info-ZIP software developers, and to make sure that your copy is strictly identical to the original. In the second case, use "unzip zipfile.zip" instead of "unzip zipfile", to let unzip know which file is the zip archive you want to extract. Q. Why doesn't zip do just like PKZIP does? A. Zip is not a PKZIP clone and is not intended to be one. In some cases we feel PKZIP does not do the right thing (e.g., not including pathnames by default); in some cases the operating system itself is responsible (e.g., under Unix it is the shell which expands wildcards, not zip). Info-ZIP's and PKWARE's zipfiles are interchangeable, not the programs. For example, if you are used to the following PKZIP command: pkzip -rP foo *.c you must use instead on Unix: zip -R foo "*.c" (the quotes are needed to let the shell know that it should not expand the *.c argument but instead pass it on to the program, but are not needed on ports that do not expand file paths like MSDOS) Q. Can I distribute zip and unzip sources and/or executables? A. You may redistribute the latest official distributions without any modification, without even asking us for permission. You can charge for the cost of the media (CDROM, diskettes, etc...) and a small copying fee. If you want to distribute modified versions please contact us at www.Info-ZIP.org first. You must not distribute beta versions. The latest official distributions are always on ftp.Info-ZIP.org in directory /pub/infozip and subdirectories and at SourceForge. Q. Can I use the executables of zip and unzip to distribute my software? A. Yes, so long as it is made clear in the product documentation that zip or unzip are not being sold, that the source code is freely available, and that there are no extra or hidden charges resulting from its use by or inclusion with the commercial product. See the Info-ZIP license for more. Here is an example of a suitable notice: NOTE: is packaged on this CD using Info-ZIP's compression utility. The installation program uses UnZip to read zip files from the CD. Info-ZIP's software (Zip, UnZip and related utilities) is freely distributed under the Info-ZIP license and can be obtained as source code or executables from various anonymous-ftp sites, including ftp://ftp.info-zip.org/pub/infozip. Q. Can I use the source code of zip and unzip in my commercial application? A. Yes, as long as the conditions in the Info-ZIP license are met. We recommend you include in your product documentation an acknowledgment and note that the original compression sources are available at www.Info-ZIP.org. If you have special requirements contact us. ======================================================================== * 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 wild card ! (see Footnotes: 1 wild card, 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. wild card: The '*' is a wild card and means 'all files' Just in case you don't know wild cards: '*' 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 ========== ======================================================================== * LICENSE ======================================================================== This is version 2007-Mar-4 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-2007 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. 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.