From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Crash: CWSDSTUB vs PMODSTUB Date: Sun, 29 Jun 2003 16:31:06 CDT Organization: Rice University, Houston, TX Lines: 37 Message-ID: <3eff5a9a.sandmann@clio.rice.edu> References: NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1056923373 26974 128.42.105.3 (29 Jun 2003 21:49:33 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: Sun, 29 Jun 2003 21:49:33 +0000 (UTC) X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > 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.