Subj : Re: An order or linking bug
To   : borland.public.cpp.borlandcpp
From : David Morris
Date : Fri Dec 10 2004 09:54 am

Hi Bob.

"Bob Gonder" <notbg@notmindspring.invalid> wrote:
> You could use far pointers so that your ISR knows for sure it has the
> correct segment. Also, might want to also fix ES == DS as stosb and
> others use ES. (I don't recall your code.)

I am using TASM.  I am pushing the DS, and reloading loading it (to be sure, to
be sure), so I am pretty sure that the ISR has the correct segment.  The ES
register is not used by the ISR as far as I can tell (unless its use is masked
by IDEAL mode?).

> Fixing problems by moving the data around usually means
> over\underwrites by surrounding data.  In this case, maybe the buffer
> fell across a 64k boundary, and moving it to the front brought it
> within bounds?

The buffer is only 8K.  I placed some maker characters around the pointers
(both behind and ahead), and they were never touched.   I thought the whole
DGROUP can only be 64k in the large memory model.   Do the hardware 64k
boundaries count?

> >The DOS executable is 340K and includes (my own) overlay code for a PABX
driver
> >module.
>
> Overlays can be tricky.
>

Yes.  And in this case a tad scary because I have forgotten a lot of what I
once knew!  I used the DOS load executable call, rewrote a c0l.obj module to
handle just the things I needed, and then copied the existing start up
information to the loaded EXE, and then with some pointer manipulation was able
to do calls into a jump table in the loaded module.  It works rather well.   I
have kept revisiting this as a possible cause, but I can't see how it could
affect just two pointers.  I would have thought any problem was going to be a
lot more catastrophic.

regards DM

.