On Tue, 10 Aug 2004, Michael Devore wrote:
> Some way or another, it looks 32RTM is unhappy with what is going on with > the stack on the call to function 34h. I don't think the InDOS pointer > itself is what causes the failure because the exception can occur during or > immediately after return from the Get InDOS simulate call.
>From your story it sounds that the int21 entry code uses too much space on the user stack.
Before someone invest too much of their life, I suppose the location could be an artefact of the debugger interacting with InDOS, but it doesn't look like it. After RTM goes into (16-bit) protected mode and installs a DPMI server, any breakpoints I place with 386SWAT wind up at an IRET (apparently because of the dual nature of what IRET does and confused real mode/pmode issues with the debugger). If I breakpoint right before the INT 31h simulate real call function, I get the expected IRET. Placing a breakpoint immediately after gets the exception and termination feedback. Can't see how it would be other than that INT 31h function which is the problem.
I tracked down the actual exception location reported. It's on a REP MOVSW, as is very typical. Possibly occurs in the DPMI interface which copies values to/from low memory. Not much help, that.
And for all I know, this could be a bug in RTM which is masked in MS-DOS because of a larger or differently structured stack, or other internal image difference.
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
