mfinegan@uceng.UC.EDU (michael k finegan) (02/02/90)
grieggs@jpl-devvax.JPL.NASA.GOV (John T. Grieggs) writes: >I am writing TSR which, among other things, needs to intercept and modify >a couple of the INT 21h calls. The problem is, I can't even seem to chain >INT 21h without horrible side effects! Look at "Advanced MS-DOS Expert Techiniques fo Programmers", Carl Townsend. I don't use turboC (rather MSC), but he uses both. Lots of TSR examples, discussion, etc. Some of the information is 'borrowed' from other sources, (i.e. Computer Language article), but valid. Think about your INT21 vector 'hooking' a little. What register is never used by any INT21 call ? How are you going to save the current state (including flag) ? What registers are used for return values ? I suggest you look at the assembler output (I assume turboC has such an option). In trapping vectors using MSC system calls - I noticed (as others have partially documented) that what I thought (and manual claimed) was happening, was not! Also realize that some registers may be restored, that should pass a value. Result: wrong value passed. mfinegan@uceng.UC.EDU
pt@geovision.uucp (Paul Tomblin) (02/08/90)
In article <3516@uceng.UC.EDU> mfinegan@uceng.UC.EDU (michael k finegan) writes: >grieggs@jpl-devvax.JPL.NASA.GOV (John T. Grieggs) writes: > >>I am writing TSR which, among other things, needs to intercept and modify >>a couple of the INT 21h calls. The problem is, I can't even seem to chain >>INT 21h without horrible side effects! > >I suggest you look at the assembler output (I assume turboC has such an option). >In trapping vectors using MSC system calls - I noticed (as others have partially >documented) that what I thought (and manual claimed) was happening, was not! >Also realize that some registers may be restored, that should pass a value. >Result: wrong value passed. I've done some looking at the assembler output of TurboC, and I must say I am suprised that Turbo has such a good reputation as being a good (well, decent, anyway) optimizer. What I found was lines like xor ax,ax jne @l1 or ax,ax jeq @l2 I also found that the following code: asm int 0x33; *p_x = _CX; *p_y = _DX; *button = _BX; yielded the wrong results because bx was being used as a holder variable before the assignment using _BX, even in small model. The moral of the story: check the assembler output when using psuedo register variables like _BX, and check it in ALL memory models you are going to be using. -- Paul Tomblin nrcaer!cognos!geovision!pt or uunet!geovision!pt Life: Loath it or ignore it, you can't like it. (Marvin) (My employer may not agree with my opinions, especially my .signature)
demon@ibmpcug.co.uk (Cliff Stanford) (02/15/90)
In article <778@geovision.UUCP> pt@geovision.UUCP (Paul Tomblin) writes: > I also found that the following code: > > asm int 0x33; > *p_x = _CX; > *p_y = _DX; > *button = _BX; > > yielded the wrong results because bx was being used as a holder variable > before the assignment using _BX, even in small model. In TurboC you *must* get values in and out of the pseudos (_AX etc) from local, simple, unsigned ints. This works, in my experience, in all cases even in the Huge model (which seems to be the worst case). I define unsigned ax, bx, cx, dx and use them at the last moment as, _AX = ax etc. Regards Cliff. -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group. -- Cliff Stanford demon@ibmpcug.co.UK Demon Systems Limited demon@cix.UUCP 42 Hendon Lane cliffs@bix London N3 1TT - England