> The InDOS flag value itself?
with lr.BX = FP_OFF(&InDOS); it would be correct. But that's what it does in my source so...
> Stack usage during the call?
that's what I suspected. Eric suggested (in a private email) to make int21/ah=34 reentrant like we did for 25 and 35. However than it would completely execute on the user stack and that stack seemed to have been the problem (only 30 words?).
I don't want to suggest basic things you've probably already thought of, but want to point out that the actual exception due to REP MOVSW in protected mode is significant. It's not a crash within FreeDOS or failure within the real mode INT 21h handler. Looks like a bad pointer to me.
Of course, that bad pointer could have come about due to stack corruption real or pmode, stack overflow back into Borland's data storage, memory corruption, or changing an unexpected register, but RTM lives long enough to get back to the RTM code itself, presumably in the DPMI dispatch/return area. I don't think the actual ES:BX return value is the problem, because it's not had a chance to be used at the exception point.
I tried manually shoehorning my own GDT entry in the RTM GDTand overwriting RTM's IDT for exception 0DH so I could catch the exception without any luck other than a change in exception message, but I could try again if nobody has any idea why it's failing.
------------------------------------------------------- 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
