|
From: Michael D. <Fre...@de...> - 2004-08-11 00:55:02
|
At 06:44 PM 8/10/2004 -0500, I wrote: >At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote: >>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. Problem is definitely the INT 31h simulate real mode interrupt Get InDOS function. If I patch out the function to simply put a zero in the returned ES:BX pointer, 32RTM goes resident without kicking out an exception. Of course, it no longer uses the InDOS flag properly, assuming it ever does use it. Anyway, that's as far as I can go with what I see. It's a problem with INT 21h DOS function 34h when called from pmode through the Borland DPMI server via INT 31h. Hopefully a kernel person can either fix it or call shenanigans on Borland. |