winedos / Speed up RM software interrupt handling

[Ove Kaaven]

ons, 2003-03-12 kl. 05:42 skrev Jukka Heinonen:
> > I think it would be cleaner to make __wine_enter_vm86 simply return in
> > that case and let winedos deal with that. We don't want the signal
> > handling to have to know about winedos if possible.
> 
> Well, that was actually one of the possibilities I did consider.
> Would it be acceptable, if __wine_enter_vm86 returns an integer
> between 0x00 and 0xff if software interrupt is to be emulated
> and -1 if hardware interrupt (or callback) is pending? Not
> a pretty interface, I'm afraid, but it would be independent of
> vm86 syscall details. It is unfortunate that vm86 stuff needs
> to be inside ntdll, but that probably cannot be helped.
> 
> Anyway, __wine_enter_vm86 is not that interesting and I don't think
> I'm going to post patches against it right now. More interesting
> is that DOS emulation needs to be able to hook to SIGUSR2/SIGALRM
> even in protected mode so some kind of callback to winedos is
> needed in set_vm86_pend. How to handle TEB.vm86_pending flag
> in this case is something I don't know. There are lots of messy
> ways but doing it in a sane way is not easy.

What I might have done if we sticked to exceptions would be to have the
whole DOS VM thread (that runs the code) be protected by a
__TRY/__EXCEPT block, not just DOSVM_Enter, and then have a flag (maybe
in the TEB) that the DPMI could set whenever executing in app protected
mode, and either set_vm86_pend or the exception handler could check; the
point being that exceptions would still be thrown in protected mode,
which the thread-wide exception handler could then catch and handle
appropriately. If you really don't want to use exceptions, then I
suppose you'll have to do a whole lot of stack frame mangling (change
the context so the code resumes at some custom winedos handler, which
would then dispatch to the right stuff) instead, which could get ugly.

Why not rather address the root cause of why you don't like to use
exceptions, that they're slow? I don't see any fundamental reason they
have to be, since as I understand, after the frame is set up, they
basically just need to look up some memory addresses and jump to the
appropriate code. There isn't an obvious reason a direct call should be
that much faster. I'm pretty sure Windows does it reasonably fast, why
can't Wine? I think that'd be worth looking into.