Mail Archives: djgpp/2001/10/04/17:34:19
> 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.
- Raw text -