Mail Archives: djgpp/2003/06/29/18:00:34
> 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.
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).
> What can it be -
> difference in PIC programming, ring 0, limited stack size ?
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
candidate.
> It is highly interesting because "CWSDMPI conflicts with IOMEGA
> ZIP drivers" cannot be satisfactory explanation.
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.
- Raw text -