🚀 go-pugleaf

stever@Octopus.COM (Steve Resnick ) writes:

>>>[some stuff deleted]
>>>>        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. However, it is correct
>>>in this place that ds points to code, it is just unsafe.
>>
>>Oh, come on.  You can surely assume two things:
>>
>>	1) DS = CS on entry to a COM program
>>	2) No DOS call is gonna change DS (unless explicitly stated in
>>	the documentation; I can't imagine that any do as of this
>>	writing)

>Oh come on. I can surely assume one of two things: 

>	1) You do not understand interrupts.	(I do too)
>	2) You didn't read what the message said.	(I did too)(

>This code is for an interrupt handler. In an interrupt handler the ONLY
>segment address that is known upon entry is the CS register. 
>Sorry for the flame, but, please read the posters question(s) before 
>responding to them incorrectly. 

>Steve


Yes, this is turning into a flame war and should probably be moved to
talk.msdos (or some such)

Nevertheless, I am well aware of the need for a CS: override in the
interrupt handler itself (unless & until you set DS = CS)

I have written several TSRs and several device drivers, so I ain't no newbie.

However, you seemed to be saying that you thought it was a good idea to
(repetitively) set DS to CS *IN THE MAIN "BOOSTER"* (i.e., non-resident)
part of the program.  In fact, the two lines of code quoted above follow
immediately a INT 21, fn 35 call, which sets ES:BX equal to the current
interrupt value.  Surely that call is going to leave DS alone.
(It would be unwise [because of re-entrancy considerations], not to
mention pointless, to call INT 21, fn 35 inside the resident part of the TSR)

Gottit?  Good.