From:	"John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: v2 dpmi double-trouble
Date:	Tue, 10 Dec 1996 19:19:57 -0800
Organization:	Three pounds of chaos and a pinch of salt
Lines:	46
Message-ID:	<32AE285D.7B0C@cs.com>
References:	<5F41B004AA AT fs2 DOT mt DOT umist DOT ac DOT uk>
Reply-To:	fighteer AT cs DOT com
NNTP-Posting-Host:	ppp105.cs.com
Mime-Version:	1.0
To:	"A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

A.Appleyard wrote:
> 
>   I found that with the A.OUT stubified by the compiler to make A.EXE, it will
> run OK under DOS and with Windows, but when I go to transfer the .EXE to a PC
> that hasn't got its own DPMI, there is the nuisance of taking a separate copy
> of CWSDPMI.EXE along with it and wondering where to put it.

There isn't any reason not to include CWSDPMI with your distributed
programs.  A lot of commercial software includes a DOS extender called
DOS4GW with it, and users don't complain.  Just make sure CWSDPMI gets
put in the same directory as your program, and it'll run fine.  As with
DOS4GW, there's no problem with having multiple copies of CWSDPMI on the
same computer; it's only 20K compared with DOS4GW's nearly 250K.

BTW, there's no need to stumble around with 'a.out' and 'a.exe' - why
don't you just use the '-o' option to create an executable of your
choice?  For example:

   gcc -o myprog.exe myprog.c  <-- creates 'myprog.exe'
   gcc -o myprog myprog.c      <-- creates 'myprog' and 'myprog.exe'

C'mon now; this is simple stuff.

>   So I tried PMODE/DJ, prefixing PMODSTUB.EXE to A.OUT to make an independent
> EXE . This ran OK under DOS, but under Windows it jammed tight on entry. I
> suspect that, as Windows is a DPMI, and PMODSTUB.EXE is a DPMI, (calling my
> program by clicking it in File-Manager in Windows) tried to install a DPMI on
> top of another DPMI, and thus caused a ghastly jam-up. Does PMODSTUB.EXE check
> if there is a DPMI there already before it tries to install its own?

The PMODE/DJ docs specify a great number of caveats to using PMODE under
different operating systems.  There are several things that PMODE just
doesn't support - unlike CWSDPMI it is NOT fully DPMI 0.9 compliant. 
But if the stub detects preexisting DPMI, it should not attempt to load
itself on top of it; this is a significant indication of a bug
somewhere.  Hmm... I just browsed through the PMODE docs and it does
give control to any resident DPMI.  It seems to be a bug in your program
that occurs only under Windows... but I could be wrong.

-- 
---------------------------------------------------------------------
| John M. Aldrich, aka Fighteer I  |        fighteer AT cs DOT com         |
| "Starting flamewars since 1993"  |   http://www.cs.com/fighteer   |
|  *** NOTICE ***  This .signature is generated randomly.           |
|                  If you don't like it, sue my computer.           |
---------------------------------------------------------------------

- Raw text -