Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!ucsd!pacbell.com!att!emory!wa4mei!holos0!lbr
From: lbr@holos0.uucp (Len Reed)
Newsgroups: comp.os.msdos.programmer
Subject: Re: stealing an interrupt
Message-ID: <1990Dec19.174402.5882@holos0.uucp>
Date: 19 Dec 90 17:44:02 GMT
References: <90351.150210TOMIII@MTUS5.BITNET> <18633@neptune.inf.ethz.ch>
Organization: Holos Software, Inc., Atlanta, GA
Lines: 66

In article <18633@neptune.inf.ethz.ch> brandis@inf.ethz.ch (Marc Brandis) writes:
>In article <90351.150210TOMIII@MTUS5.BITNET> TOMIII@MTUS5.BITNET (Thomas Dwyer III) writes:
>>Hi there.  Would some kind soul please tell me why my machine hangs when
>>I run this TSR?  What am I doing wrong?
>
>[some stuff deleted]
>>        assume  cs:code,ds:code,es:code
>....
>>        mov     word ptr [old_int+2],es         ; Save old vector
>>        mov     word ptr [old_int],bx
>
>Here, there is a rather unsafe assumption that ds points to the code segment
>after DOS has been called. You should better set ds explicitly to code (e.g.
>by push cs, pop ds) or use an segment prefix for cs.
>in this place that ds points to code, it is just unsafe.

Nonsense.  What's unsafe about this?  This is obviously a ".com" TSR: COMs
start with CS=DS=ES=SS.  The assume notes this (although SS is not
listed), and the DOS calls used preserve the DS register, so the DS
register does in fact point to the code.

Why use overrides or pushes and pops when the DS: points where you want
it to?  (And if it doesn't point where you want it to then the assumes
should tell the assembler this.  This is where the bug lies.)

There's no problem, potential or otherwise, here.

>....
>>old_int dd      ?
>>        jmp     [old_int]                       ; Jump to old int routine
>
>Here lies the real problem. As this code is called inside an interrupt, the
>assumption that ds points to code is wrong (!). You can either add a correct
>assume statement in front of this code, which would be
>
>		assume cs:code, ds:nothing, es:nothing, ss:nothing
>
>or you can make it explicit that you want a segment prefix for this instruction
>and that you want a far call, which is actually what I would suggest. It is
>much better to make it explicit what is going on than to rely on the context
>given by the assume statements. So try the following statement (the ultra safe
>version)
>
>	jmp	dword ptr cs:[old_int]

Well, maybe explicit is better, but if you're really trying to code something
well your assumes should be correct.  Put the assume statement in.
What I'm saying is that it's fine to give the assembler more information
than it needs, but you shouldn't give it wrong information (i.e., not
changing the assume) and then override that wrong information with a
segment prefix.

Eventually this code will get expanded to do something useful.  Having
the assumes wrong is a recipe for future bugs and is confusing to
anyone who might later read this code.

I assume that your explicit adding of "dword ptr" in the above jump is
intended to document that this is a far jump.  (The assembler knows that
old_int is a doubleword so "dword ptr" is unecessary.)  Some assembler
won't take the format you used; you have to say
	jmp	cs: dword ptr [old_int]
-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr