[comp.binaries.ibm.pc.d] Phil Katz's PKZIP/PKUNZIP v1.02 for MSDOS and OS2

w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) (10/10/89)

I have uploaded the following files to SIMTEL20, obtained directly
from Phil Katz:

pd1:<msdos.zip>
PKZ102.EXE      Phil Katz's ZIP archive package version 1.02

pd1:<msdos.os2>
PKZ102-2.EXE    Phil Katz's ZIP v1.02 archive package for OS2

From the WHATSNEW file, which is included inside these self-extracting
archives:

Version 1.02 is a minor bug fix for version 1.01 of PKZIP,
PKUNZIP, and ZIP2EXE for the MS-DOS software; and PKSFX and
ZIP2EXE for the OS/2 software.  No new features have been added
to the software in this release.

Those who have registered version 1.0x and are due a free
upgrade will receive PKZIP/PKUNZIP/PKSFX(R) etc. version 1.1,
with manual, when it becomes avaliable.


MS-DOS
======

New files:  PKZIP.EXE, PKUNZIP.EXE, ZIP2EXE.EXE, BIOSFIX.COM
            REZIP.ZIP, MAKESFX.COM

All other files are the same as for version 1.01.

Description of changes
----------------------

  o An updated version of Thomas Atkinson's REZIP is included
    with this version, that properly handles paths stored
    within a .ZIP file.

  o Several people have reported problems with PKZIP/PKUNZIP
    1.01 on 80386 computers, especially with disk caching
    programs using EXTended memory, such as Super PC-Kwik.
    This is due to the fact that Super PC-Kwik will access
    '80286 extended memory' during the timer interrupt via
    the BIOS interrupt 15H.  However, this corrupts the 32-bit
    accumulator (EAX) in the 80386 CPU, and neither many BIOS's
    nor PC-Kwik bother to preserve the EAX register.  If you have
    an 80386 CPU and have had problems with PKZIP/PKUNZIP 1.01,
    try these work-arounds, in the following order:

    - Run BIOSFIX.COM supplied with version 1.02.  BIOSFIX
      is a small (288 bytes resident) TSR program that preserves
      the entire 80386 register set during any mode switches via
      INT 15H.  This has been tested with Super PC-Kwik, and
      should work with other programs that may be performing
      asynchronouos CPU mode switching.

    - Use an 80386 memory manager such as QEMM or 386^MAX which
      will control and preserve the 80386 machine state.  Also,
      use exPANded memory with your application instead of
      exTENded memory, if possible.

    - If you are using Super PC-Kwik, place /H- /D- on the
      SUPERPCK command line.

    - SET the environment variable PKNO386=xxxx where "xxxx"
      is any string you want.  If the string PKNO386 is present
      in the environment, then PKZIP/PKUNZIP 1.02 will not use
      80386 instructions or registers.  Note however that
      disabling the 80386 usage will make PKZIP run up to 20%
      slower and PKUNZIP up to 40% slower than if the 80386
      instructions are used.

  o Using the "-c" option with PKZIP 1.01 could, in very rare
    instances, cause random corruption of the .ZIP file.  This
    was due to an anomoly in the MSC _ffree() function when
    passed a canonical pointer.  This has been corrected in
    PKZIP 1.02.

  o There is bug in MS-DOS 3.3 and 4.x when SHARE is loaded and
    I/O redirection is used, that sometimes prevents a file or
    device, once redirected to, from ever being opened in a
    sharing mode.  This would cause PKUNZIP to display the message 
    "can't open: NUL" when using the "-t" test option.  PKUNZIP 1.02
    first tries to open NUL in share-deny-none mode, and if that
    fails, it will open the NUL device in compatibility mode,
    bypassing SHARE.

  o ZIP2EXE 1.01 could, on occasion, erroneously report that the
    .ZIP file it was converting contained Reduced files.  This has
    been corrected in this release.

  o When PKZIP 1.01 would be unable to open a file that it was
    trying to compress (it is locked by another program on a
    network, for example) PKZIP would display a message that
    the file could not be added.  However, when PKZIP terminated
    it would exit with an exit code of 0 in this circumstance.
    Several people have requested a way of determining this
    condition when run from a program or batch file, so PKZIP 1.02
    will exit with an errorlevel of 18 when it is unable to open
    one or more files that were specified.  It should be noted that
    this is a 'warning' condition only, and that otherwise PKZIP
    was able to construct the .ZIP file without any errors.


OS/2
====

New files:  PKSFX2.PRG, PKSFXF.PRG, ZIP2EXE.EXE

All other files are the same as for version 1.01.

Description of changes
----------------------

  o The same condition reported above for ZIP2EXE could also
    occur with the OS/2 version of ZIP2EXE.

  o The PKSFX2 and PKSFXF programs would fail if the self-
    extracting file contained more than approximately 50 files.
    This was due to an anomoly between memory allocation under
    MS-DOS vs OS/2, and has been corrected in this release.


Some Common Questions & Answers
-------------------------------

o Where is my copy of PKSFX??  I ran PKZ102.EXE, but I don't have 
  the third program, PKSFX.
  
  - You have to run the program MAKESFX to create the file PKSFX.PRG.

o Why is the new version of PKZIP so much slower than my earlier version?

  - PKZIP version 0.90 or 0.92 defaulted to its fastest compression
    method, called Shrinking.  PKZIP 1.0 defaults to its best
    compressing, albeit slower method called Imploding.  Imploding
    typically compresses much better than Shrinking.  However, you can
    still tell PKZIP 1.02 to perform Shrinking if you want by specifying
    "-es" on the PKZIP command line, or by placing COMPRESS=SPEED in
    your PKZIP.CFG file.  See MANUAL.DOC for more information about
    specifying what compression method is to be used with PKZIP.

o Do I have to convert the .ZIP files I made with earlier version of PKZIP?

  - No, PKZIP and PKUNZIP 1.02 can read and extract .ZIP files created
    by any version of the software.  However, converting .ZIP files
    created by PKZIP 0.92 with the new software can result in additional
    compression.

---end of whatnew---

SIMTEL20 has made some changes in its network software.  If you have
given up on us because of slow throughput or hung connections with
FTP, please try again.  Don't forget to use tenex mode when getting
binary files.  Comments and complaints about ftp should be sent to
Action@WSMR-SIMTEL20.Army.Mil.

Some users have complained about not being able to send mail to my
SIMTEL20 address because of gateway problems.  I have included some
alternatives in my signature below.

--Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@smoke.brl.mil, w8sdz@sadis01.af.mil
w8sdz@tacom-emh1.army.mil, w8sdz@eddie.mit.edu, w8sdz@unix.secs.oakland.edu
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz