Xref:	news-dnh.mv.net comp.os.msdos.djgpp:1246
Path:	news-dnh.mv.net!mv!news.sprintlink.net!news.texas.net!news.kei.com!news.mathworks.com!gatech!swrinde!news.uh.edu!uuneo.neosoft.com!news!sandmann
From:	Charles Sandmann <sandmann AT praline DOT no DOT NeoSoft DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: [Q] Are there are stub version of CWSDPMI?
Date:	Sun, 30 Jul 1995 11:17:50 CDT
Organization:	NeoSoft Internet Services +1 713 968 5800
Lines:	17
References:	<su37mapRCna6078yn AT werple DOT mira DOT net DOT au>
Reply-To:	sandmann AT clio DOT rice DOT edu
Nntp-Posting-Host:	praline.no.neosoft.com
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

> I think it would be really great if a 'auto loader' program was written that
> loaded cwsdpmi if there was no other dpmi host present, then ran your
> djgpp binary.

This is what the V2 stub already does!  The V2 stub (a whopping 2Kbytes)
checks for DPMI, if there isn't one searchs for and loads CWSDPMI.EXE to 
provide the DPMI services.  The V2 image then runs using those services.
If you have a nested image call (GCC/MAKE/etc) it uses the same DPMI which
was loaded by the first task (it already sees DPMI present).  On exit, if
the first image loaded CWSDPMI, it is removed from memory.

All of this is just as transparent as loading GO32 in V1.x - but if you
have DPMI loaded is a step that can be skipped.   If you load CWSDPMI as
a TSR you get to skip the search/load step, but give up 50K of memory.

The search process includes the directory your djgpp image is in (even if
it is not in your path) which makes image distribution easy.

- Raw text -