Hi Michael,
> Or a sweet-talking
> diplomatic type might convince the original FDXMS developer to make the
> changes/fixes. Or bribes. Money, flattery, chocolate, cheese, beer,
> liquor, young female, choice World of Warcraft items,...
Which of those would it take to make you write some nice exception
handling add-ons for EMM386? ;-)
I am suggesting something like:
...
CMP ESP,V86_TOS-36H
JZ @@V86_ABORT ; v86 caused exception with error code
CMP ESP,V86_TOS-32H
JZ @@REENTRY ; simple v86 event, to be reflected back
JA "other protected mode task caused an exception"
; now, assume that ESP is below V86_TOS-32H
JMP @@PROTECTED ; something in EMM386 itself caused an
; exception, while it was processing V86_ABORT, REENTRY or
; EMM_ENTRY (int 67)...
...
So there are two changes: Explicitly check for V86_TOS-32H, to detect
exceptions caused by other protected mode tasks (i.e. stack contains
less than a v86-int-without-error-code stack frame), and a change in
The @@PROTECTED code... On to that second one:
...
Current implementation of @@PROTECTED is:
[ESP+24] (14 bytes) = [ESP+12], then add 12 to ESP
This only works if the protected mode part of EMM386 itself causes
an exception without error code in some specific situation. A more
generic approach can contain:
- remember WHAT you are handling (reentry, v86_abort or emm_entry)
because different stack contents are involved
- or just show the whole protected mode stack, force (!) ESP to the
V86_TOS-36H value, save EAX/EBX/ECX and a dummy error code to the
appropriate places, and jump to V86_ABORT.
The important difference here is that the current version makes
assumptions about what got pushed to the stack between "something
from v86 mode activated emm386" (V86_TOS-32H ... V86_TOS has the
same meaning for all those "something" cases) and "something in
emm386 itself caused an exception". The assumptions SEEM to work
if the exception has no error code and emm386 itself has pushed
exactly 3 values to the stack, but they are far from generic. In
particular, if emm386 itself causes a page fault, the stack starts
to melt.
It is safer to show an error message, rewind the stack to the last
thing which you know for sure (that v86 called emm386 before things
went wrong in emm386 itself) and then act like in v86_abort: Blame
the calling DOS program and throw an int 6 and/or int 21.4c at it,
which we know to work well for cases where it is really the DOS
program which does evil things ;-).
Thanks a lot :-)).
PS: I do not play Warcraft, am no beer/liquor expert, and prefer to
keep young females myself. I could, however, send cheese, chocolate
or money to you, most impressing and clever EMM386 VCPI programming
god over there =8-).
Eric
PPS: You may have noticed that I made no suggestions how "exceptions
caused by other protected mode programs" should be handled. This is
because I have no idea how to handle them :-P. For exceptions 8 and 9,
you always have to halt the system, as they save no useful "return to
there pointer" (double fault, FPU seg overrun). For exceptions 0 (div.
by zero, div overrun), 1 (in some cases, depends on DR6), 5 (bound),
6 (ill. opcode), 7 (FPU emulation), 10 (invalid TSS), 11 (seg not
present), 12 (stack fault), 13 (general protection), 14 (page fault)
and 16 (FPU error), returning to the protected mode task which caused
them would just cause a loop, as all those are faults (as opposed to
traps like into, int3 and int nn) which record the causer-address, not
the next-instruction address.
If emm386 itself causes a fault, it can at least return to the DOS
program which called it, simply aborting the fault-triggering activity,
but if another protected mode task causes a fault and fails to handle
it itself, emm386 can probably do nothing except halting the system,
as I have no idea where you could return to in such a situation.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
