Path: utzoo!attcan!uunet!mitel!sce!cognos!geovision!pt
From: pt@geovision.uucp (Paul Tomblin)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Help this poor, brain-damaged TSR!
Summary: DONT USE PSUEDO REGISTERS WITHOUT DUE CARE!!
Keywords: INT 21h TSR
Message-ID: <778@geovision.UUCP>
Date: 8 Feb 90 13:27:02 GMT
References: <6952@jpl-devvax.JPL.NASA.GOV> <3516@uceng.UC.EDU>
Reply-To: pt@geovision.UUCP (Paul Tomblin)
Organization: GeoVision Corp, Ottawa, Canada
Lines: 39

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)