Date: Wed, 08 Jan 1997 10:24:49 +0000 From: Bill Currie Subject: Re: Debuggers and mouse hooking (or maybe dpmi memory allocatio To: Robert Hoehne Cc: "Salvador Eduardo Tropea (SET)" , 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 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: 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.