Date:	Thu, 23 Oct 1997 16:27:03 +0530 (IST)
From:	"Mahadevan R." <mdevan AT md2 DOT vsnl DOT net DOT in>
Reply-To:	"Mahadevan R." <mdevan AT md2 DOT vsnl DOT net DOT in>
To:	Kris Heidenstrom <kheidens AT actrix DOT gen DOT nz>
Cc:	djgpp AT delorie DOT com
Subject:	Re: Some comments and questions
In-Reply-To:	<199710230703.UAA23329@atlantis.actrix.gen.nz>
Message-Id:	<Pine.OSF.3.95.971023160124.16073A-100000@md2.vsnl.net.in>
Mime-Version:	1.0

On Thu, 23 Oct 1997, Kris Heidenstrom wrote:

> Well, yes and no.  Obviously CWSDPMI is designed to be able to be loaded
> as a TSR as well as automagically, because it does install itself if
> invoked from the command line, so what it does is still not good
> behaviour.  But as I said, it's a minor point.  I shouldn't have even
> mentioned it, it makes me look so ungrateful!

AFAIK, CWSDPMI can behave as "normally" as any other TSR.  If you define
"normality" as being able to detect its own presence and unload if
required, then have a look at this:

[This is from the documentation cwsdpmi.doc]

-8<------
1) "cwsdpmi" alone with no parameters will terminate and stay resident
   FOR A SINGLE DPMI PROCESS.  This means it unloads itself when your
   DPMI application exits.  This mode is useful in software which needs
   DPMI services, since CWSDPMI can be exec'ed and then will unload on
   exit.

2) "cwsdpmi -p" will terminate and stay resident until you remove it.
   It can be loaded into UMBs with LH.  "cwsdpmi -u" will unload the TSR.
-8<------

Furthermore, even if CWSDPMI was not loaded with the "-p" switch, it can
be unloaded with the "-u" switch.

HTH,
Mahesh (Mahadevan R.), <mdevan AT iname DOT com>

- Raw text -