Mail Archives: djgpp/1999/03/03/01:43:51
On Tue, 2 Mar 1999, John S. Fine wrote:
> If you run
> CWSDPMI without EMM386, then CWSDPMI is responsible for things that
> otherwise EMM386 would handle.
Only a small part of them, actually. CWSDPMI is not a replacement for
memory manager. For example, when no memory manager is present,
CWSDPMI grabs all the extended memory to itself, even if the client
doesn't ned that much.
> I think you are saying that CWSDPMI,
> then uses true real mode for DOS calls, rather than using V86 mode.
Yes.
> I think using true real mode is a bad design for many reasons
You didn't expect a 20K program written by an engineer on his free
time to include a memory manager and a V86 monitor, did you?
Real mode may be ``bad design'' (I don't think so, personally), but it
has significant advantages: it is simple, well-documented, and it
works on any machine. In contrast, the list of conflicts for any
memory manager, even the best ones, goes for many pages.
> If CWSDPMI really uses real mode that way, and I was seting up a
> system to service 20Hz interrupts in djgpp, I think I would make
> sure QEMM or EMM386 or something was loaded first.
Not necessary a good idea, I'm afraid. Certain versions of EMM386,
for example, are known to slow down interrupt processing significantly
(see section 18.11 of the FAQ).
> One of my projects runs mainly in V86 mode on a 50Mhz 486. All
> interrupts are in pmode and it often sevices interrupts well over
> 20Khz for sustained periods.
Interesting.
What system configuration was that? Did you use MS-DOS and standard
memory managers to get to V86, or some custom software as well?
- Raw text -