home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 9 Archive
/
09-Archive.zip
/
unzip511.zip
/
msdos
/
README
< prev
Wrap
Text File
|
1994-07-24
|
4KB
|
91 lines
Notes about MS-DOS executables and compilers:
- Borland start-up code is reported to switch the screen mode auto-
matically if it's not 80 columns (or possibly 40) and either 25, 43
or 50 lines. In particular, extended modes such as 100x40 are not
retained.
- Borland start-up code also uses interrupt 1Ah, causing incorrect
behavior (including lock-ups) on some Japanese MS-DOS machines such
as the Fujitsu FMR series, which lack this interrupt.
- Some(?) Borland compilers are apparently incapable of putting static
data into far memory; this means all of UnZip's strings are in near
memory, and there is not enough room to enable ZipInfo in the small
memory model. Even if strings are in far memory, the *code* segment
produced by Borland compilers is now too big for one segment. The
large memory model is therefore the default for Borland compilers, but
it may be possible to compile in the medium model as well (not tested).
- Older Borland compilers do not understand source files with Unix
line-endings (LF rather than CR/LF). Use "flip" or a similar utility
to convert the line endings before compiling, or take a look at the
Borland.fix file in the UnZip source distribution.
- Microsoft C 5.1 large-model code is more than an order of magnitude
slower than the identical code compiled with MSC 6 or 7 (a factor of
15 in our tests, actually). This may be due to a lousy optimizer or
lousy libraries; regardless, since UnZip is hovering at the doorstep
of the large memory model, we recommend upgrading to a later version
of the compiler.
For these reasons, Info-ZIP's distributed versions of the 16-bit MS-DOS
executables are compiled with MSC 6 or 7.
- The default wildcard ("globbing") behavior of djgpp/go32 is disabled
by default in UnZip, but this can be overridden if the GO32 environment
variable is set to "glob". This will cause UnZip to fail with various
odd errors about "filename not matched" and the like; to avoid this, set
the GO32 variable to "noglob" or unset it altogether. (The documented
method of avoiding this by quoting wildcards with single quotes is buggy.)
Info-ZIP's distributed 32-bit MS-DOS executables are compiled with djgpp
1.11.m5. These are stand-alone programs; the "go32" DOS extender is in-
cluded inside the executables. They generally run up to twice as fast
as the 16-bit versions, but they only work on 386's and above. In some
cases they're actually slower. If this is the case for you, first try
running under plain DOS, after removing any memory manager in your
config.sys and rebooting, to check if the slowdown is due to your memory
manager. (According to notes found in another package, there is a known
conflict between the go32 extender and QEMM's DPMI; add "set GO32=nodpmi"
to your autoexec.bat to avoid this.) There may also be a problem with
the time spent by the djgpp runtime creating and deleting a swap file.
If you use SMARTDRV or another disk cache, make sure that writes are also
cached.
If you already have djgpp 1.11 or later (or, more specifically, go32.exe
1.11 or later somewhere in your PATH), you can remove go32.exe from
unzip386.exe to get a smaller executable:
exe2coff unzip386.exe
coff2exe unzip386
del unzip386
As noted above, go32/djgpp has its own wildcard-expansion routines which
are disabled in UnZip by default because of incompatibilities with UnZip's
own wildcards. Stripping the go32 extender may cause go32's wildcards to
be re-enabled; in this case you must set GO32 as follows for UnZip to work
correctly:
set GO32=noglob
With this setting unzip386.exe behaves just like unzip.exe.
You may also need to set the TZ environment variable to get correct time-
stamps on extracted files when using unzip386.exe. Adding the line
set TZ=MET0
to autoexec.bat works for our French contingent; a Californian user might
need "set TZ=PST8PDT" instead. The 16-bit version always uses local time
for extracted timestamps but may still need TZ to be set in order for the
-f and -u options to work correctly (see unzip.doc).
For other problems related to DJGPP, read the documentation provided
in oak.oakland.edu:/pub/msdos/djgpp/djdev111.zip. If a problem occurs
with unzip386.exe, check first if it also occurs with unzip.exe before
reporting it.
GRR 940711