From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: DOS extenders... Date: Thu, 4 Oct 2001 15:53:32 Organization: Aspen Technology, Inc. Lines: 49 Message-ID: <3bbc85fc.sandmann@clio.rice.edu> References: NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 1002230595 14884 10.32.115.107 (4 Oct 2001 21:23:15 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 4 Oct 2001 21:23:15 GMT X-NewsEditor: ED-1.5.8 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > Is it fair to call > Cwsdpmi.exe simply a "Dos extender" ? It's actually just an implementation of the documented DPMI 0.9 standard. That implies that there is no extension which takes place. The code isn't used at all in a Windows environment, for example. You can also replace CWSDPMI with PMODE or MWDPMI. I have built copies with an internal extender (to support applications which expect an extender with their DPMI) but have never released them. (They always had bugs, and I had no plans to maintain it so didn't want the requests to fix it). > working with DJGPP, cwsdpmi is VERY EFFICIENT. I would think > that a lot of effort went into making it so. DJ wrote the original GO32 (which is the heart of the mode switch code and module layout). I modified it with the help of many other contributors. For everything it does it is efficient, but for pure mode switch speed and size PMODE is even more efficient. The beauty here is these are standards, so if someone writes a better DPMI provider which provides the best of all worlds, you can use it without needing to touch your DJGPP image. > And is it not true that in order to gain the most out of such an > approach, the DPMI server should be as closely tuned in to a given > Compiler as possible...? (code-generation, startup-code, linking > specifics, etc.) We have taken the exact opposite approach in DJGPP - treating the mode switch/memory management layer as a standard, replaceable black box. If you are willing to limit compatibility and functionality you can improve speed even more than what is in the current available library. > I was just wondering if anyone here, in DJGPP newsgroup, might want > to share any comments as to why / how, and what more can be done > to see 32-bit applications made happy without Windows 3.1x/9x being > used... If the extender is sufficiently optimized, you should be able to achieve close to Windows speed if you are using a disk cache also.