Post by michae » Sun, 29 Jun 2003 19:30:30

Hello !

I realize that this question seems very vague, but
perhaps anybody has seen something similar.
I have one program that works with ASPI devices, recently I replaced
PMODSTUB v1.3 with CWSDSTUB v5 and already received many reports
about strange behavior when working with bad ZIP discs. I was able to
recreate one typical situation: IOMEGA ZIP with native
drivers (any version from 3 to 6), if ZIP drive is corrupt (scratched
with a razor), then instead of reporting read error system hangs,
gives GPF or just prints garbage on the screen. It happens only
if I use CWSDPMI (not only stub), the same COFF with
attached PMODSTUB works fine. Obviously it not "NULL pointer assignment"
or something what CWSDPMI intercepts unlike PMODE. What can it be -
difference in PIC programming, ring 0, limited stack size ? It is highly
interesting because "CWSDMPI conflicts withIOMEGA ZIP drivers"
cannot be satisfactory explanation.

Thanks in advance,



Post by Eli Zarets » Mon, 30 Jun 2003 12:15:38

> Date: Sat, 28 Jun 2003 17:30:30 +0700 (NOVST)

Can you explain why you are so confident it's not a NULL pointer

Anyway, if you can reproduce the situation where it GPFaults, please
post here the full text of the message it prints when it crashes,
complete with the registers dump and traceback (after SYMIFY). That
information can help us point you to the possible causes for the



Post by Charles Sa » Tue, 01 Jul 2003 01:31:06

> I have one program that works with ASPI devices, recently I replaced

This sounds like a problem with an interrupt taking too much stack
space. Recently BIOS and driver writers have provided very poor
code for DOS, quite often taking huge amount of stack space. The
DPMI spec says (page 53, under translation services):

"If the real mode procedure/interrupt routine uses more than 30 words
of stack space then you should provide your own real mode stack."

CWSDPMI relaxes this restriction - allowing you to use 128 words - but
some badly written code overruns this with a single interrupt. PMODE
provides a bigger internal stack, but even it has had problems with
some recent video BIOS providers.

To test this you can try providing a real mode stack to see if the
problem goes away, or someplace on clio there is a test executable
which prints the largest amount of stack used (and it expands the
size a lot so it can see the overflows).

The above is a guess - it could be something else - but real mode
stack - especially in the rare case of an error - is a likely

I suspect if an expanded real mode stack is provided it would work. I'm
considering increasing the default stack size for future releases since
the quantity of bad 16-bit real mode code seems to be increasing - but
this will substantially decrease the number of nested tasks you could
have and increase the real mode memory footprint.