|
From: Luchezar G. <lu...@co...> - 2004-08-13 06:19:01
|
Hello Michael, > 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. I tried "int 0x21 ah=0x34" in both MS-DOS 7.10 and FreeDOS. In both, the returned offset in BX is 321h although the segment in ES is slightly lower in MS-DOS than in FreeDOS (C9h vs D2h). But in both cases, the memory location pointed to by ES:BX was 0. So, that pointer seems valid to me. I also tried to catch the real pointer value when called by 32RTM with STEPDOS. It didn't came to calling DOS function 34h at all! The latest DOS function I saw before it showed the "Unhandled exception" message was 2Fh (get DTA). The returned value by function 2Fh in ES:BX was 1376:80h. > 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. You may be right that it's a bad pointer in the context of the real call. Could you catch what pointer it returns when called by 32RTM? The returned value in ES:BX when I test it by "int" is D2:321h. > 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. Alas, this seems so, indeed... If you can see the pointer DOS function 34h returns (or even the byte pointed to by it) when called by 32RTM, this may help. Thanks, Lucho |