From: "John M. Aldrich" 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "A.Appleyard" 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. | ---------------------------------------------------------------------