Date:	Wed, 08 Jan 1997 10:24:49 +0000
From:	Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject:	Re: Debuggers and mouse hooking (or maybe dpmi memory allocatio
To:	Robert Hoehne <robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de>
Cc:	"Salvador Eduardo Tropea (SET)" <salvador AT natacha DOT inti DOT edu DOT ar>,
	djgpp-workers AT delorie DOT com
Reply-to:	billc AT blackmagic DOT tait DOT co DOT nz
Message-id:	<32D375F1.39F7@blackmagic.tait.co.nz>
Organization:	Tait Electronics NZ
MIME-version:	1.0
References:
	<Pine DOT HPP DOT 3 DOT 95 DOT 970107104058 DOT 22360A-100000 AT newton DOT mathematik DOT tu-chemnitz DOT de>

Robert Hoehne wrote:
> 
> I think here is a misunderstanding of you (or me). The code in dbgcom.c
> restores
> (as you said correct) all and exactly the flags, which are returned by
> the original int 0x31. I don't know why this should be a problem. If there
> is a problem (in your program), then you will get it also when not running
> under a debugger, because in that case you get exactly these flags.

The dpmi spec states that int 31 preserves ALL unspecified registers AND
flags.
This means that the caller (the application) shlould only see the carry
flag 
change; ALL of the others must be as they were BEFORE the int 31 was
invoced.

> > There was aslo some other problems with register preservation with some
> > of the
> > intercepted functions, so I fixed those whils I was at it.
> Really?? Please explain it more exactly, because I found nothing.

[buggy patch and good test code snipped]
> And now I found, why fsdb failed. Exactly because of the same like I wanted
> to show with the example. The startup code calls at first DPMI function
> 0x0507 (set page attributes) which is a DPMI 1.0 function and
> not supported when running under W95 (I'm running it there). So that
> call returns a CF=1 and the next call to int 0x31 returns then also
> CF=1 but the call was successfull.

Yes, this was a stupid mistake of mine.  I forgot to test fsdb under
windows (my 
testing was done under dos as that was where the original problem was
occurring).
The fix is simply to put a 'andb $~1,12(%esp)' before the 'or'
instruction.  I 
sent a diff for it yesterday (after testing!!), but it may have been
lost in the 
mail.


> Why this?? You are saving the contents of eax but it is not used because
> the success of the DPMI call is returned by CF=0 and in that case no return
> value in eax is expected.
> OH!! An now I see that there is also a bug. What is if _change_handle
> set CF=1?? In that case the DPMI call would return an error, but it
> is not an error. (It can set CF=1 if it is the 256th or higher handle, which
> is probably never true, but nobody knows)

Not only that, but for some of the functions, the error code was getting
lost 
(or the successfull result in ax, maybe both, can't remember)

> OK, may be I see all that from a wrong point, but I think, you should
> think again a little bit about your patch (You can believe me that I
> thought many many days about my changes, because it is very hard to
> debug that code)

Oh yes, I agree with you that it is hard to debug this code.  Your mods
looked well
thought out, just a few bugs snuck in when you turned your back ;) (like
mine with the
carry flag, I just completely forgot that I had to clear the bit first)

Bill
-- 
Leave others their otherness.

- Raw text -