home *** CD-ROM | disk | FTP | other *** search
/ PC World 2000 February / PCWorld_2000-02_cd.bin / tools / unz512x3.exe / README.DOS < prev    next >
Text File  |  1994-08-28  |  5KB  |  96 lines
  1. Notes about MS-DOS executables and compilers:
  2.  
  3.  - Borland start-up code is reported to switch the screen mode auto-
  4.    matically if it's not 80 columns (or possibly 40) and either 25, 43 
  5.    or 50 lines.  In particular, extended modes such as 100x40 are not
  6.    retained.
  7.  
  8.  - Borland start-up code also uses interrupt 1Ah, causing incorrect
  9.    behavior (including lock-ups) on some Japanese MS-DOS machines such
  10.    as the Fujitsu FMR series, which lack this interrupt.
  11.  
  12.  - Some(?) Borland compilers are apparently incapable of putting static
  13.    data into far memory; this means all of UnZip's strings are in near
  14.    memory, and there is not enough room to enable ZipInfo in the small
  15.    memory model.  Even if strings are in far memory, the *code* segment
  16.    produced by Borland compilers is now too big for one segment.  The
  17.    large memory model is therefore the default for Borland compilers, but
  18.    it may be possible to compile in the medium model as well (not tested).
  19.  
  20.  - Older Borland compilers do not understand source files with Unix
  21.    line-endings (LF rather than CR/LF).  Use "flip" or a similar utility
  22.    to convert the line endings before compiling, or take a look at the
  23.    Borland.fix file in the UnZip source distribution.
  24.  
  25.  - Microsoft C 5.1 large-model code is more than an order of magnitude
  26.    slower than the identical code compiled with MSC 6 or 7 (a factor of
  27.    15 in our tests, actually).  This may be due to a lousy optimizer or
  28.    lousy libraries; regardless, since UnZip is hovering at the doorstep
  29.    of the large memory model, we recommend upgrading to a later version
  30.    of the compiler.
  31.  
  32. For these reasons, Info-ZIP's distributed versions of the 16-bit MS-DOS 
  33. executables are compiled with MSC 6 or 7.
  34.  
  35.  - The default wildcard ("globbing") behavior of djgpp/go32 is disabled
  36.    by default in UnZip, but this can be overridden if the GO32 environment
  37.    variable is set to "glob".  This will cause UnZip to fail with various
  38.    odd errors about "filename not matched" and the like; to avoid this, set
  39.    the GO32 variable to "noglob" or unset it altogether.  (The documented
  40.    method of avoiding this by quoting wildcards with single quotes was 
  41.    buggy in djgpp 1.11 but is reported fixed in 1.12; not tested.)
  42.  
  43.  - djgpp's handling of timezones, necessary for the correct conversion of
  44.    MS-DOS filetimes to those used in the Unix-like C library, is completely
  45.    broken in djgpp 1.12 and probably earlier versions as well.  It is fixed
  46.    (or very close to it) in the most recent 1.12m1 beta, so be sure to up-
  47.    grade to 1.12m1 before compiling.  Otherwise UnZip's -f and -u (freshen/
  48.    update) functions will not work correctly.
  49.  
  50.  - emx+gcc's DOS extender does not understand DPMI, and while there is an
  51.    alternative extender called RSX available (found in dpmigcc4.zip as of
  52.    August 1994), its setup is somewhat kludgy when the local memory manager
  53.    supports both DPMI and VCPI (or something else).  It's also not yet as
  54.    widely known or available as djgpp.
  55.  
  56. For these reasons Info-ZIP's distributed 32-bit MS-DOS executables are com-
  57. piled with djgpp 1.12m1.  These are stand-alone programs; the "go32" DOS 
  58. extender is included inside the executables.  They generally run up to twice
  59. as fast as the 16-bit versions, but they only work on 386's and above.  In 
  60. some cases they're actually slower.  If this is the case for you, first try 
  61. running under plain DOS, after removing any memory manager in your config.sys
  62. and rebooting, to check if the slowdown is due to your memory manager.  (Ac-
  63. cording to notes found in another package, there was a known conflict between 
  64. the go32 extender and QEMM's DPMI; this was apparently just fixed in QEMM 
  65. 7.04/QDPMI 1.05, but if you still have an older version (1.03 or 1.01), add 
  66. "set GO32=nodpmi" to your autoexec.bat to avoid the conflict.)  There may 
  67. also be a problem with the time spent by the djgpp runtime creating and de-
  68. leting a swap file.  If you use SMARTDRV or another disk cache, make sure 
  69. that writes are also cached.
  70.  
  71. If you already have djgpp 1.12m1 or later (or, more specifically, go32.exe
  72. 1.12m1 or later somewhere in your PATH), you can remove go32.exe from
  73. unzip386.exe to get a smaller executable:
  74.  
  75.     exe2coff unzip386.exe
  76.     coff2exe unzip386
  77.     del unzip386
  78.  
  79. As noted above, go32/djgpp has its own wildcard-expansion routines which
  80. are disabled in UnZip by default because of incompatibilities with UnZip's
  81. own wildcards.  Stripping the go32 extender may cause go32's wildcards to
  82. be re-enabled; in this case you must set GO32 as follows for UnZip to work
  83. correctly:
  84.  
  85.     set GO32=noglob
  86.  
  87. With this setting unzip386.exe behaves just like unzip.exe.
  88.  
  89. For other problems related to DJGPP, read the documentation provided in
  90. oak.oakland.edu:/pub/msdos/djgpp/djdev112.zip.  If a problem occurs with 
  91. unzip386.exe, check first if it also occurs with unzip.exe before reporting 
  92. it.
  93.  
  94.  
  95. GRR 940828
  96.