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 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: 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.