1Notes 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. The medium memory model is the default for now, but 16 it may be necessary in some cases to use the large model. 17 18 - Older Borland compilers do not understand source files with Unix 19 line-endings (LF rather than CR/LF). Use "flip" or a similar utility 20 to convert the line endings before compiling. 21 22 - The Borland 5.00 compiler is simply too buggy to use on WizUnZip, both 23 16-bit and 32-bit versions, and we recommend avoiding it for now even 24 on the commmand-line version of UnZip. 25 26 - Microsoft C 5.1 large-model code is more than an order of magnitude 27 slower than the identical code compiled with MSC 6 or 7 (a factor of 28 15 in our tests, actually). This may be due to a lousy optimizer or 29 lousy libraries; regardless, since UnZip is hovering at the doorstep 30 of the large memory model, we recommend upgrading to a later version 31 of the compiler. 32 33For these reasons, Info-ZIP's distributed versions of the 16-bit MS-DOS 34executables are compiled with MSC 6 or 7. 35 36 - djgpp 2.x (currently 2.03) is no longer distributed with the go32 extender. 37 Instead, a 2K stub bound into the executable searches for a DPMI server; 38 if none is found, it loads the default DPMI server while executing UnZip. 39 Both djgpp 1.x and 2.x are capable of substituting a list of files in an 40 ASCII file (say, `foo') on the command line; for example, "unzip archive 41 @foo" will extract from `archive' all of the files listed in `foo'. Note, 42 however, that djgpp 2.x is considerably slower than 1.x at file extraction 43 (roughly twice as slow, in fact); see proginfo/perform.dos in the UnZip 5.3 44 source distribution for details. 45 46 - djgpp 2.0's long-filename support is somewhat flaky; users should upgrade 47 to version 2.01 instead. 48 49 - The default wildcard ("globbing") behavior of djgpp 1.x/go32 is disabled 50 by default in UnZip, but this can be overridden if the GO32 environment 51 variable is set to "glob". This will cause UnZip to fail with various 52 odd errors about "filename not matched" and the like; to avoid this, set 53 the GO32 variable to "noglob" or unset it altogether. (The documented 54 method of avoiding this by quoting wildcards with single quotes was 55 buggy in djgpp 1.11 but is reported fixed in 1.12; not tested.) 56 57 - djgpp 1.x's handling of timezones, necessary for the correct conversion of 58 MS-DOS file times to those used in the Unix-like C library, is completely 59 broken in djgpp 1.12 and probably earlier versions as well. It is fixed 60 (or very close to it) in the 1.12m4 patch release and reportedly in the 61 2.x series, so be sure to use one of those when compiling. Otherwise 62 UnZip's -f and -u (freshen/update) functions will not work correctly. 63 It is reportedly necessary to set the TZDIR environment variable correctly 64 with 1.12m4; for example, add `set TZDIR=c:/djgpp/zoneinfo' or similar to 65 autoexec.bat. 66 67 - djgpp 1.x/go32 executables, when run in a DOS box under OS/2 *and* extrac- 68 ting to an HPFS disk *and* overwriting existing files (intentionally, that 69 is), do not set the files' timestamps correctly. Instead, the timestamps 70 remain set to whatever the original files' stamps were. This is a pretty 71 obscure bug, but it does *not* occur in the 16-bit version so it seems 72 to be go32's fault somehow. 73 74 - According to notes found in another package, there was a known conflict 75 between djgpp 1.x's go32 extender and QEMM's DPMI; this was apparently 76 fixed in QEMM 7.04/QDPMI 1.05, but if you still have an older version 77 (1.03 or 1.01), add "set GO32=nodpmi" to your autoexec.bat to avoid the 78 conflict.) 79 80 - [For Zip only, the djgpp/go32 extender goes nuts with the copying and/or 81 deletion of some sort of a temporary file (swap file?) after compression 82 is finished; this can take 30 seconds or more and really hurts perfor- 83 mance. It doesn't affect UnZip, apparently.] 84 85 - [Also apparently for Zip only, djgpp/go32 is reported to have problems 86 when EMM386 is set to NOEMS; it sometimes gives the error message, "CPU 87 must be in REAL mode (not V86 mode) to run this program without VCPI. 88 (If you are using an EMS emulator, make sure that EMS isn't disabled)" 89 Sometimes Zip works correctly, however, possibly due to other software 90 having been run previously.] 91 92 - emx+gcc's DOS extender does not understand DPMI, and while there is an 93 alternative extender called RSX available (found in dpmigcc4.zip as of 94 August 1994), its setup is somewhat kludgy when the local memory manager 95 supports both DPMI and VCPI (or something else). It's also not yet as 96 widely known or available as djgpp. 97 98 - The free PMODE/W extender, used in conjunction with executables compiled 99 with Watcom C 10.x and run in an OS/2 DOS box, appears to use up some 100 critical DPMI resource and will fail to run after a few dozen executions 101 ("PMODE/W: DPMI error" and/or SYS 3176). Some newer versions of PMODE/W, 102 in combination with "unzip -v" on certain zipfiles (e.g., APMTST.ZIP from 103 IBM/EWS), fail immediately (SYS 3176). And on some OS/2 systems, *any* 104 use of the PMODE/W executables causes the machine to lock up. 105 106 - PMODE/W is also reported to lock up pure DOS systems if QEMM is running. 107 108 - At least older versions of PMODE/W, used in conjunction with Microsoft's 109 EMM386, cause UnZip to start up extremely slowly. (This problem does not 110 occur with QEMM.) 111 112For these reasons Info-ZIP's distributed 32-bit MS-DOS executables will 113be compiled with djgpp 2.03, mainly because of its nice long-filename 114support when running in a Win32 DOS box. The cwsdpmi DPMI server will be 115bundled if necessary. 116 117SPC 2000-04-16 118