home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / archives / msdos / announce / 401 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  10.1 KB
  1. Xref: sparky comp.archives.msdos.announce:401 comp.compression:4839
  2. Newsgroups: comp.archives.msdos.announce,comp.compression
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!news.funet.fi!uwasa.fi!chyde.uwasa.fi!ts
  4. From: ts@chyde.uwasa.fi (Timo Salmi)
  5. Subject: pkz204e.exe - pkzip/unzip 2.04e uploaded to garbo
  6. Message-ID: <ts9301271411.1266@chyde.uwasa.fi>
  7. Followup-To: comp.compression
  8. Sender: ts@uwasa.fi (Timo Salmi)
  9. Organization: University of Vaasa
  10. Date: Wed, 27 Jan 1993 14:11:47 GMT
  11. Approved: ts@chyde.uwasa.fi
  12. Lines: 209
  13.  
  14. -Subject: Re: pkz204e.exe - pkzip/unzip 2.04e uploaded to garbo
  15. -To: kko@sfu.ca
  16. -Date: Wed, 27 Jan 1993 16:11:02 +0200 (EET)
  17. -From: ts
  18.  
  19. > Hi, I've just got pkz204e.exe from PKWARE BBS and uploaded it to
  20. > /pc/incoming at garbo ...
  21.  
  22. Thank you for your contribution Samuel.  This upload is now
  23. available as
  24.  196424 Jan 25 02:04 garbo.uwasa.fi:/pc/arcers/pkz204e.exe
  25.  
  26. > >From the file v204e.new ...
  27. >
  28. > The following changes have been made in version 2.04e of
  29. > PKZIP/PKUNZIP from version 2.04c.
  30. >
  31. > 1) DPMI.
  32. >
  33. >      The DPMI support in PKZIP/PKUNZIP has been changed to work
  34. >      around bugs and anomolies with the following DPMI drivers or
  35. >      environments.  PKWARE would like to thank Quarterdeck Office
  36. >      Systems and Qualitas, Inc. for their technical assistance
  37. >      regarding DPMI.
  38. >
  39. >     a) PC-KWIK
  40. >
  41. >       According to PC-KWIK corporation's document, 'PC-KWIK
  42. >       Technical Issues "Summer '92"':
  43. >
  44. >     PC-KWIK is unable to recognize memory requests from programs
  45. >     using VCPI or DPMI protocols ... For programs [that use VCPI
  46. >     or DPMI] it is necessary to reduce the size of the cache and
  47. >     disable lending.
  48. >
  49. >       PC-KWIK has a lending feature that allows memory to loaned
  50. >       from the cache memory to applications.  However, PC-KWIK is
  51. >       not aware of any memory allocated or used by DPMI, and will
  52. >       loan this memory as well, possibly causing corruption of the
  53. >       DPMI driver and usually resulting in a system crash or reboot.
  54. >
  55. >       This problem seems to present in most versions of SUPERPCK,
  56. >       through version 5.01.
  57. >
  58. >       In other words, when using PC-KWIK with any program that uses DPMI,
  59. >       including PKZIP and PKUNZIP, you should either make sure that you
  60. >       have enough memory in your computer so that lending will not occur,
  61. >       reduce the size of your cache, or disable PC-KWIK's lending.
  62. >
  63. >       Therefore, PKZIP/PKUNZIP detect for the presence of PC-KWIK
  64. >       and default DPMI to DISABLE when PC-KWIK is installed.  This
  65. >       can be overidden by specifying -)+ on the PKZIP or PKUNZIP
  66. >       command line, or by placing DPMI=ENABLE in your PKZIP.CFG for
  67. >       PKZIP or setting the environment variable PKUNZIP=-)+ for PKUNZIP.
  68. >
  69. >   b) QDPMI 1.00
  70. >
  71. >       If a program tries to use DPMI and EMS memory with QDPMI 1.00,
  72. >       QDPMI would become unstable or crash.  PKZIP/PKUNZIP now
  73. >       check for the presence of QDPMI 1.00 and if PKZIP/PKUNZIP
  74. >       are using EMS memory, they do not attempt to use DPMI at all.
  75. >
  76. >   c) QDPMI 1.01
  77. >
  78. >       When a program switches to protected mode, QDPMI does not
  79. >       'synchronize' the EMS page frame.  The result is that programs
  80. >       can not correctly read or write any data in the EMS page frame
  81. >       while in proteced mode.  PKZIP/PKUNZIP now check for the presence
  82. >       of QDPMI 1.01 and will use slower real-mode code for any
  83. >       manipulation of data in the EMS page frame rather than faster
  84. >       protected mode code.
  85. >
  86. >   d) OS/2 2.0 DOS BOX
  87. >
  88. >       The OS/2 2.0 DOS box does not allow programs to allocate the
  89. >       'DPMI private data area' in an UMB.  Doing so causes a system
  90. >       violation error.  PKZIP/PKUNZIP now check to see if they are
  91. >       running in the OS/2 2.0 DOS box and will not allocate the DPMI
  92. >       private data area in an UMB.  (This is actually kind of a shame,
  93. >       as the OS/2 DOS box (unlike the Windows DOS box) provides UMB
  94. >       memory to DOS applications.  It should be able to allow programs
  95. >       to store the DPMI data area in these UMB's.)
  96. >
  97. >   e) Windows 3.0 DOS BOX
  98. >
  99. >       The DPMI support in the Windows 3.0 DOS box does not always
  100. >       seem to work correctly.  Therefore, PKZIP/PKUNZIP detect if
  101. >       they are running in the Windows 3.0 DOS box and will not support
  102. >       DPMI in this environment.
  103. >
  104. >   f) Windows 3.1 DOS BOX
  105. >
  106. >       The way PKZIP/PKUNZIP allocates the DPMI save/restore state
  107. >       buffer has been changed to be more compatible with Windows 3.1.
  108. >
  109. > 2)  The Norton AntiVirus program FALSELY reported that PKZIPFIX and
  110. >     PKUNZIP contained the Maltese Ameoba virus.  The software DID
  111. >     NOT contain this virus.  All files in this release have been
  112. >     modified so as to not trigger any FALSE virus reports by the
  113. >     Norton AntiVirus program.
  114. >
  115. > 3)  QEMM versions 5.1x would corrupt the high word of the 32-bit
  116. >     registers on an 80386 or 80486 CPU.  PKZIP/PKUNZIP check for
  117. >     this condition, and will not use 32-bit instructions if QEMM
  118. >     version 5.1x is present.
  119. >
  120. > 4)  Apparently some peer-to-peer networks such as Novell Netware Lite
  121. >     and others do not support canonical or fully specified filename.
  122. >     PKZIP now uses noncanonical filenames when specifying temporary
  123. >     filenames on a network drive to avoid this problem.
  124. >
  125. > 5)  PKZIP would erroneously report "E28 Destination is same as temp
  126. >     directory" when creating a new .zip file on drive A:.  This has
  127. >     been fixed.
  128. >
  129. > 6)  The keywords on/enable and off/disable are now synonymous when
  130. >     used in the PKZIP configuration file.
  131. >
  132. > 7)  Using EMS= options in the PKZIP configuration file would enable
  133. >     or disable both EMS and XMS usage.  The XMS= option had no effect.
  134. >     This has been corrected.
  135. >
  136. > 8)  The Quick format option in PKZIP would zero out the existing FAT
  137. >     on the disk (by design).  However, if the disk had any bad
  138. >     sectors on it (in which case, it isn't a good idea to use that
  139. >     disk as a backup disk anyway...) they would now be marked as
  140. >     good.  By popular demand, PKZIP now reads the existing FAT and
  141. >     leaves any bad sectors marked as bad.  This however, makes the
  142. >     'Quick' format function about twice as slow as it was (although
  143. >     still much faster than an unconditional format).  In most cases
  144. >     however, unless there are several subdirectories on the diskette,
  145. >     the -&w (wipe) option is faster than the -&f (format) option when
  146. >     backing up to pre-formatted diskettes.
  147. >
  148. > 9)  Under some cirumstances, PKZIP could possibly store the last
  149. >     file in a multi-disk backup set incorrectly.  This has been
  150. >     corrected.
  151. >
  152. > 10) The volume label option in PKZIP would not work.  This has been
  153. >     fixed.
  154. >
  155. > 11) PKZIP/PKUNZIP now searches for a PKNOFASTCHAR variable in the
  156. >     DOS environment.  If this variable is present, PKZIP/PKUNZIP
  157. >     will use the slower DOS 1.x/2.x character output functions
  158. >     rather than the 'DOS Fast Character Output' function.  This is
  159. >     provided for compatability with some TSR's, BBS Doors and mail
  160. >     readers etc., that redirect or capture the output of programs and
  161. >     do not support the DOS Fast Character Output function.
  162. >
  163. > 12) PKZIP will now accept either MAXIMUM or MAXIMAL in the
  164. >     configuration file.
  165. >
  166. > 13) Some people have requested that the -& backup option support the
  167. >     DOS verify function.  Specifying -&v on the PKZIP command line
  168. >     or BACKUP=VERIFY in the PKZIP.CFG file will turn on the DOS
  169. >     verify flag when writing to the backup disk(s).  This makes
  170. >     PKZIP run slower, but ensures better integrity of each diskette.
  171. >
  172. > 14) Using the -m option with -rp in PKZIP will delete any empty
  173. >     subdirectories that have been saved in the .ZIP file after all
  174. >     the files have been moved into the .ZIP file.  Some people have
  175. >     requested a way to have PKZIP leave these empty subdirectories
  176. >     behind.  This can be accomplished by using -m- on the PKZIP
  177. >     command line.
  178. >
  179. > 15) It appears that some versions of NoGate's PAK program would
  180. >     place incorrect information in the .ZIP file directories that it
  181. >     created.  Specifically, the disk number information for where
  182. >     files, the central directory, and the central end directory
  183. >     started is inconsistent, causing PKUNZIP to think it was
  184. >     extracting a multi-disk .ZIP file when it really wasn't.
  185. >     PKUNZIP now checks for this condition, and ignores this
  186. >     erroneous information.
  187. >
  188. > 16) PKZIP now ignores any ZIPDATE= or -o or -k options when creating
  189. >     multi-disk .ZIP files, rather than displaying the help screens.
  190. >
  191. > 17) On some 80386 machines running PKZIP could leave allocated UMB's
  192. >     behind.  This has been corrected.
  193. >
  194. > 18) In some circumstances, running PKZIP with EMS memory and very low
  195. >     free conventional memory could cause corruption of the .ZIP file.
  196. >     This has been corrected.
  197. >
  198. > 19) When PKZIP prompts for an encryption password, it will now ask the
  199. >     user to enter the password twice for verification.
  200. >
  201. > 20) PKZIP/PKUNZIP would not work under DOS 2.x.  This is because
  202. >     DOS 2.x crashes on many int 2Fh installation check calls for
  203. >     EMS/XMS drivers etc.  These calls work properly under DOS 3.0
  204. >     or above.  Therefore, PKZIP/PKUNZIP detect for the presence
  205. >     of DOS 2.x, and will not support any of the advanced features
  206. >     including 32-bit instructions, EMS memory, XMS memory, DPMI
  207. >     support and Netware usage.
  208. >
  209. > 21) PKSFX could in some instances erroneously report failed AV's or
  210. >     garble any AVEXTRA text present.  This has been fixed.
  211. >
  212. > 22) Using PKZIP with the -o option or ZIPDATE=LATEST in the configuration
  213. >     file would set the date of the .ZIP file to the latest dated file
  214. >     or directory.  Directory dates are now ignored in this version.
  215.  
  216.    All the best, Timo
  217.  
  218. ..................................................................
  219. Prof. Timo Salmi      Co-moderator of comp.archives.msdos.announce
  220. Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
  221. Faculty of Accounting & Industrial Management; University of Vaasa
  222. Internet: ts@uwasa.fi Bitnet: salmi@finfun   ; SF-65101, Finland
  223.