Mail Archives: opendos/2000/11/10/14:54:42
Hi,
> * PKZIP will use 32-bit protected mode compression code if
> DPMI is present, allowing for significantly faster and
> somewhat better compression.
Yesterday I made a slight mistake when I wrote about PKWARE.INI
file directives. According to the manual it should say
DPMI=displayed
instead of DPMI=disable (which works too, though).
Another way to disable DPMI support is to define the PKZIP=-) and
PKUNZIP=-) environment variables. The manual is somewhat inconsistent
in regard which environment variables and PKWARE.INI directives
are supported by which tool...
While PKZIP 2.50 DPMI crashes under DR-DOS EMM386, PKZIP 2.04g DPMI
didn't crash for me. I encountered three problems with PKZIP 2.04g,
though:
1. When launching it from within batchjobs as a background task,
the system often crashed with an EMM386 protection fault.
2. When compressing extremly large files (16 Mb or so), my test
systems at these times (an ASUS T2P4 with Pentium 100 Classic and
a Phoenix 386sx16, both with Novell DOS 7 update 15.2 & DR-DOS
7.02) crashed when PKZIP had finished the compression and
started to write the .ZIP file out to disk.
Both problems were independent of PKZIP's various DPMI, XMS, EMS,
386, or cache configuration switches. However, when I tried to
reproduce these faults yesterday on my current setup (the ASUS T2P4
board now with AMD K6-III/450, and using DR-DOS 7.03) both effects
were gone and it worked smooth with PKZIP 2.04g and 2.50. But, of
course, too many hardware, firmware, and software changes since than
- I just cannot recreate the original test environment any more...
3. PKZIP 2.50 for DOS eventually fixes the "wipe option bug" we
discussed in great detail back in May 1997. The only changes
listed in WHATSNEW.TXT coming close to describing this problem are:
> * PKZIP allows you to format (using the -&fh or -&uh options) high
> density diskettes in extra high density diskette drives when
> spanning archive files.
Formatting and wiping code when spanning archive files probably lies
cheek to cheek in their sources...
> * Improved PKZIP compatibility with NetWare 4.0.
Could have something to do with attribute use via FCBs. Just a
vage guess...
> * PKZIP/PKUNZIP/PKSFX supports Windows 95/98 (DOS 7) long
> filenames.
This implies that they might have made some changes to support DOS
7.10 (FAT32) as well and thereby had to fade out FCB functions.
Well anyway, not very obvious. It seems they don't actually know that
they thereby fixed another problem, or they just don't list any bug
fixes...
For those interested in the technical background, I have condensed
that old thread a little:
----------------------------------------------------------------------
>From: "Michael E. Webb" <mwebb AT mail DOT enterprise1701 DOT com>
>To: caldera-opendos AT caldera DOT com
>Date: Tue, 20 May 1997 10:15:11 -0400
>Subject: OPENDOS and PKZIP
>
>[...]
>
>3) Now I'm having problems using PKZIP under OpenDOS; I regularly do
> a differential backup using the -&w (wipe disk) switch. Has
> always worked fine under the versions of MS-DOS and PC-DOS. Now
> it doesn't. It SAYS it does (DELWATCH no longer in use, BTW), but
> when it starts to write the new file, there's no room and the old
> ZIP entry is still there. The new ZIP entry appears as a 0 byte
> file. I'm now having to pre-wipe the disks (using a quick-format
> utility) before doing my backup.
> [...]
----------------------------------------------------------------------
>Date: Thu, 22 May 1997 16:33:49 +0100
>From: Matthias Paul <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
>Subject: Re: OPENDOS and PKZIP
>To: Caldera-OpenDOS AT caldera DOT com, opendos-developer AT delorie DOT com
>
>On Tue, 20 May 1997, Mike Webb wrote:
>
>> [...]
>> That one's another matter. In the PKZIP circumstance, I tested
>> several scenarios. Before any of them, I'd ran DELPURGE *.* /S /A
>> (wildcard purge of all Pending Deleted files, recurse into
>> subdirectories, purge without prompting) on my C: and D: drives.
>> DELWATCH was not operational on my A: drive. In fact, some of the
>> diskettes I tried had not been previously used on the PC under
>> OpenDOS with or without DELWATCH loaded. In each case, PKZIP's
>> "wipe disk" function failed to remove the existing files from the
>> diskette so that the backup could proceed. I suspect that the
>> problem's in the I/O routines of OpenDOS, which are not supporting
>> what PKZIP is trying to do.
>
>Yes, your're right. I have tested on this behaviour at home
>and could reproduce it with Novell DOS 7 + Update 15/2, using
>PKZIP 2.04g (first time, I used its -&w option...).
>
>However, the problem has absolutely nothing to do with DELWATCH etc.,
>instead I tracked this down to a call to INT21h/13h "Delete via FCB",
>where PKZIP uses an *extended* FCB filled-in with:
>
> Mask (D:=drive letter): D:????????.???
> Attributes: 0Fh
>
>This specific call is not handled correctly by the kernel, since it
>results with AL=FFh, indicating
>
> "No files to delete, or files have been Read-Only or locked".
>
>In fact, the kernel had not deleted any of the files from D:,
>although it should have deleted all of them. I have not yet
>looked this up in the sources to provide a fix. Assuming MS-DOS'
>behaviour as correct, it should have returned with all the files
>matching attribute=0Fh deleted, and AL=00h (or AL=FFh, if there
>were no files). This is, why PKZIP does not care about the AL
>result.
>
>I'm not sure, if we really can call this a bug in the kernel, since
>PKZIP's usage of INT21h/13h is at least unusual. Normally, this call
>is used only with standard FCBs (without an attribute), not with
>extended FCBs (providing attributes). I have not yet found any
>difficulties when calling INT21h/13h with standard FCBs.
>E.g., COMMAND.COM does use the call only for commands like DEL *.*.
>If giving DEL *.* /S (include system files with our COMMAND.COM), it
>uses "Erase File" calls instead. Apparently, 4DOS does not use
>INT21h/13h at all.
>While MS-DOS allows INT21h/13h to be called with extended FCBs having
>a read-only attribute set, neither NetWare, DR DOS, NWDOS, nor
>OpenDOS does.
>Note, that there has been a serious bug in MS-DOS (DOS 1.2-5.0 at
>least, maybe it's still there), when handling the call with extended
>FCBs: Giving an attribute=1Fh, the kernel does delete all the files
>including the entries for the subdirectories, but does *NOT* delete
>the files *IN* these subdirectories, causing the FAT system to be
>corrupted on that medium (run CHKDSK to see this). This might be the
>cause, why the DR DOS family does discard attempts to use extended
>FCBs here (I have not checked other attributes, yet).
>
>Further, using an attribute=0Fh, PKZIP could not wipe out the medium
>completely (only if there were no subdirectories). So, this might
>also be called a bug in PKZIP, since it also could (and better
should)
>use modern API-functions like "Erase File" instead.
>
>Since PKZIP 2.04g has been the latest DOS-version for years now,
>we might fail to get a fixed version from PKWare. (However, if
>PKZIP will be fixed, it should also be enhanced to support DR DOS
>style passwords, at least their syntax - easy, and maybe use some
>more precautions with DPMI under the TASKMGR.)
>
>On the other hand, we may try to extend OpenDOS' support of
>INT21h/13h using extended FCBs. To avoid the MS-DOS bug, maybe we
>should mask out special attributes beyond 0Fh. We have to check the
>sources, now...
>
>Bye,
>
> Matthias
>
>[...]
----------------------------------------------------------------------
>Date: Fri, 23 May 1997 20:46:42 +0100
>From: Matthias Paul <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
>Subject: Re: OPENDOS and PKZIP
>To: caldera-opendos AT caldera DOT com
>
>On Thu, 22 May 1997, William Tanksley wrote:
>
>> >E.g., COMMAND.COM does use the call only for commands like DEL
>> >*.*. If giving DEL *.* /S (include system files with our
>> >COMMAND.COM), it uses "Erase File" calls instead. Apparently,
>> >4DOS does not use INT21h/13h at all.
>>
>> Are you sure about this? 4DOS does use FCBs if you have at least
>> one whenever you issue the /t or /q switch with the del command,
>> last I read.
>>
>> Of course, I don't KNOW any of this; I've never used one of those
>> DOSwatchers on it.
>
>I'm not absolutely sure, since I don't know their source code... ;-)
>
>However, this was what I found lastly when tracking down this PKZIP
>-&w problem. Using DEL *.* (no options), 4DOS 5.52a does NOT use
>INT21h/13h. I cannot say anything about other options, but IMHO it
>wouldn't make that much sense, here (though - technically spoken -
>it was possible).
>
>For those interested in the problem, OpenDOS discards these
>attributes as used by PKZIP in the IBMDOS.COM code, see file
>FUNCS.FDO at "unlink_attribs:", called from FCBS.A86. If not
>taking the PKZIP problem and MS-DOS' behaviour into account, the
>code *does* make sense to me as it is (at least it avoids to copy
>the bug in MS-DOS)...
>
>We could provide a fix to let this special bit combination 0Fh
>come through, perhaps only when being called from the FCB entry
>(special fix for PKZIP, but could make the kernels behaviour somewhat
>inconsistent yet stable in other scenarios), or we could generally
>relax some of OpenDOS' precautions, here.
>
>Both options are very easy to be done. Any comments?
>(Possibly better in OpenDOS-developer AT delorie DOT com...)
>
>Bye,
>
> Matthias
----------------------------------------------------------------------
I am preparing a new report for PKWARE. If you know of any
other problems with PKZIP 2.04 or 2.50 or have suggestions,
please let me know... (or write to PKWARE yourself - I have
more than enough other work to do... ;-)
Matthias
-------------------------------------------------------------------
Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------
- Raw text -