DPMI: Interrupt vector overwritten
Hello.
Quoted 1 line · John Elliott
They cause dosemu to abort if DPMI function
0x300is used to call interrupt0xE0or higher;
What exactly interrupt from this range do you want to execute?
Quoted 1 line
is this correct,
Of course it is not. If your program installs the realmode handler for that ints, it will just crash dosemu with that code.
It was even worse when this was done not only for 0x300, but also for 0x301 and 0x302, so it crashed dosemu *randomly* because bx is meaningless for those.
I moved it under "if (inumber == 0x300)" rather than remove, because it was a hard times and it was nearly impossible to get included something more than an absolutely trivial patch. Removal patch would just have been ignored most likely, so the compromiss was to put it under "if". Now, as the devel branch is in progress, the things are much better.
Quoted 1 line
and if so, why is it doing it?
For no reasons, feel free to remove it if it hurts you, which is still strange. Why do you need that vectors?
Quoted 11 lines · Stas Sergeev
Quoted 3 lines · John Elliott
They cause
dosemu to abort if DPMI function0x300is used to call interrupt0xE0or higher;What exactly interrupt from this range do you want to execute?
Quoted 1 line
is this correct,
Of course it is not. If your program installs the realmode handler for that ints, it will just crash dosemu with that code.
if ((_LO(bx) >= 0xe0) && (REG(cs) < 0xf000)) { /* avoid hardreboot!! */I should add that this test is more bogus than it used to be because these high vectors are initialized to 0 in development versions of DOSEMU and no longer point to the DOSEMU BIOS interrupt trampoline.
It looks a lot like something that was added to do some custom sanity checking while debugging some DOS program, but the person forgot to remove it later.
The comment is puzzling: hardreboot of what? Linux?
Bart