From: <SANDMANN AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: dpmi_int - any caveats?
Date: Sat,  8 Mar 1997 23:48:59
Organization: Rice University, Houston, Texas
Lines: 22
Message-ID: <3321faeb.SANDMANN@clio.rice.edu>
References: <199703031317 DOT OAA11566 AT gil DOT physik DOT rwth-aachen DOT de>
Reply-To: SANDMANN AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> had it working but the combo of my program and the driver
> seems to be very unstable. I cannot invoke the program twice.

It sounds like an interrupt not being unhooked or some other badness.
You should capture the interrupt table before and after running the
image to see if there are any changes.

> BTW, why is __tb>>4 anded with 0xffff? Since it is an address below 1MB
> supplied by go32 the by 4 shifted value can never have any bits set
> that would be masked off by 0xffff.

It shouldn't matter, you are correct.  And since the tb is always paragraph
aligned, the offset is always zero too.

> Does it matter whether cwsdpmi is loaded once in autoexec (cwsdpmi -p)
> or having it just in the path?

When doing things like this, it is definitely better to let it auto load (and 
unload) from the path than staying resident.  If things aren't cleaned up quite
right the CWSDPMI auto unload will sometimes save you from having problems
(since anything internally scrogged gets freed and reloaded instead of
staying there to bite you the next execution).