Can one prevent emm386 from using VM86 mode ?
colin manning
If you are only using emm386 in order to make upper memory blocks available,
which do not need paging or any other facilities of protected mode in order to
be accessible, is it possible to prevent it moving the 386 to virtual 8086
mode ? I.e have emm386 make UMB's available, but leave the 386 in real mode.
There are two reasons for wanting this:
1. Virtual 8086 mode is slower for certain operations.
2. You cant run software that likes to switch in and out of protected
mode itself.
--
- Colin Manning, c...@jet.uk
- Disclaimer: Please note that the above is a personal view and should not
be construed as an official comment from the JET project.
Holger Veit
Apparently, the existing version of emm386 has not such a switch. Is is
possible to write an emm386 driver with the requested features? I think, no.
The iAPX386 data sheet doesn't say it exactly, but the paging feature of the 386
which is used in the ems driver is working in protected mode and V86 mode only.
The paging unit is necessary to map memory from >1MB into the declared EMS
page frame. There may be other possible solutions for that, e.g. mapping
existing memory into the EMS page by means of special features of the 386-AT
chipset and then using the INT15 copy each time there is an EMS page fault,
but this is much more slow. And what happens with INT15 when the processor is
already in protected mode...
I'm not quite sure, but heard, that the main part of the DPMI software is
located in the EMM driver, so a software which uses this standard should
coexist with EMM386 (most commercial DOS-extenders already do or will do
in the next release; does of course not help with existing software).
Holger Veit
--
| | / Holger Veit | INTERNET: ve...@du9ds3.uni-duisburg.de
|__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
| | / Fac. of Electr. Eng. | UUCP: ...!uunet!unido!unidui!hl351ge
| |/ Dept. f. Dataprocessing |
Adam Mirowski
%% When you run emm386, it always seems to run DOS in virtual 8086 mode.
%%
%% If you are only using emm386 in order to make upper memory blocks available,
%% which do not need paging or any other facilities of protected mode in order to
%% be accessible, is it possible to prevent it moving the 386 to virtual 8086
%% mode ? I.e have emm386 make UMB's available, but leave the 386 in real mode.
%%
%% There are two reasons for wanting this:
%%
%% 1. Virtual 8086 mode is slower for certain operations.
%% 2. You cant run software that likes to switch in and out of protected
%% mode itself.
No, it is impossible.
First, Intel 386 manuals tell so. :-)
Second, even if you would like to use the method already signaled in
a recent Dr. Dobbs article to access extended memory as an array in
real mode by not flushing a cache (the segment cache) when retuning
from protected mode, it is not possible because the cache for pages
(TLB) has only 32 entries, which is not enough to map the entire real
mode memory. Very quickly a cache miss would occur and would have to
access the page directory and the page tables, which precisely aren't
in its address space anymore...
Anyway, I believe this cache is automatically flushed and disabled when
386 returns to real mode, so I stop these divagations just here. :-)
--
Adam Mirowski, m...@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74
Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX
Jimmy Liberato
>In <1991Jun28.1...@jet.uk> c...@jet.uk (colin manning) writes:
>
>>When you run emm386, it always seems to run DOS in virtual 8086 mode.
>
>>... is it possible to prevent it moving the 386 to virtual 8086
>>mode ? I.e., have emm386 make UMBs available, but leave the 386 in real mode.
>
>>There are two reasons for wanting this:
>
>>1. Virtual 8086 mode is slower for certain operations.
>>2. You cant run software that likes to switch in and out of protected
>> mode itself.
>
>...
>I'm not quite sure, but heard, that the main part of the DPMI software is
>located in the EMM driver, so a software which uses this standard should
>coexist with EMM386 (most commercial DOS-extenders already do or will do
>in the next release; does of course not help with existing software).
Granted that DPMI will become the new standard, isn't EMM386 also VCPI (Virtual
Control Program Interface) compliant? And aren't all current programs that
use DOS extenders also VCPI compliant? If this is so, what would be the
problem here?
--
Jimmy Liberato libe...@dri.com
...uunet!drivax!liberato
Holger Veit
[...]
>Granted that DPMI will become the new standard, isn't EMM386 also VCPI (Virtual
>Control Program Interface) compliant? And aren't all current programs that
>use DOS extenders also VCPI compliant? If this is so, what would be the
>problem here?
>--
>Jimmy Liberato libe...@dri.com
> ...uunet!drivax!liberato
VCPI is more a memory management standard than a protected mode manager, as
DMPI is. VCPI was invented to solve the conflict with two different
extended memory allocation strategies (allocating from the bottom resp. from
the top of memory). DMPI allows in addition the switching from/to protected
mode, real and V86 mode, including management of GDT/LDT and paging.
The latter tasks are usually done by DOS extenders, which assume to be the
only PM managers on the machine. DMPI is intended to allow the coexistance of
different PM programs (this is *no-preemptive* multitasking, there is no
scheduler, the tasks have to behave *nice* and give away the control of the
processor if they have to wait).
(Nearly) all DOS extenders support VCPI, because this standard was there first.
EMM386 (at least the uSoft brand) does not support VCPI. uSoft instead wants
/ /
to push DPMI as the coming standard. In this situation, this makes sense,
since DPMI has a better functionality than VCPI (although they may have thought
to sell more Windows software, which is, in the moment, the only software, which
really uses DPMI).
Holger
Bob Gettys
From a talk I attended at the Boston Computer Society on the eve of the
Dos 5 release, Bill Gates himself said that you could not support both DPMI and
VCPI at the same time. It was said that they had incompatible requirements which
could not be met so one had to be chosen. Of course MS chose DPMI.
/s/ Bob Gettys
Jimmy Liberato
>In <913...@dri.com> libe...@dri.com (Jimmy Liberato) writes:
>
>[...]
>
>>Granted that DPMI will become the new standard, isn't EMM386 also VCPI
>>(Virtual Control Program Interface) compliant? And aren't all current
>>programs that use DOS extenders also VCPI compliant? If this is so, what
>>would be the problem here?
>
>
>[explanation of diferences between VCPI and DPMI]
>...
>(Nearly) all DOS extenders support VCPI, because this standard was there first.
>EMM386 (at least the uSoft brand) does not support VCPI. uSoft instead wants
>to push DPMI as the coming standard. In this situation, this makes sense,
>since DPMI has a better functionality than VCPI (although they may have thought
>to sell more Windows software, which is, in the moment, the only software,
>which really uses DPMI).
>
Does this mean I cannot run programs like Paradox 386 or Lotus 123 3.0 if
EMM386 is installed? QEMM is both VCPI and DPMI compliant so why wouldn't
EMM386 be. I haven't tried MSDOS 5.0 yet so I don't have first hand knowledge.
Would I just use separate config.sys files depending upon which program I
wanted to run?
Holger Veit
>ve...@du9ds3.uni-duisburg.de (Holger Veit) writes:
>>In <913...@dri.com> libe...@dri.com (Jimmy Liberato) writes:
>>
>>[...]
>>
>>>Granted that DPMI will become the new standard, isn't EMM386 also VCPI
>>>(Virtual Control Program Interface) compliant? And aren't all current
>>>programs that use DOS extenders also VCPI compliant? If this is so, what
>>>would be the problem here?
>>
>>
>>[explanation of diferences between VCPI and DPMI]
>>...
>>(Nearly) all DOS extenders support VCPI, because this standard was there first.
>>EMM386 (at least the uSoft brand) does not support VCPI. uSoft instead wants
>>to push DPMI as the coming standard. In this situation, this makes sense,
>>since DPMI has a better functionality than VCPI (although they may have thought
>>to sell more Windows software, which is, in the moment, the only software,
>>which really uses DPMI).
>>
I have to admit that I am wrong with my notice that EMM386 doesn't support
VCPI. I have looked a little bit around with debug and into my literature:
It's surprising but EMM386 (at least the version packed with WINDOWS 3.0)
tells that it supports VCPI, but only after at least one EMS page is
requested. I do not know whether the MSDOS5.0 version is different here
(does anyone know this?).
>Does this mean I cannot run programs like Paradox 386 or Lotus 123 3.0 if
>EMM386 is installed? QEMM is both VCPI and DPMI compliant so why wouldn't
>EMM386 be. I haven't tried MSDOS 5.0 yet so I don't have first hand knowledge.
>Would I just use separate config.sys files depending upon which program I
>wanted to run?
>--
>Jimmy Liberato libe...@dri.com
> ...uunet!drivax!liberato
There is probably a difference between being compliant and really containing
the VCPI or DPMI code. The main terms here are client and server. As stated
above EMM386 reacts on INT 67 function DE00 (This is the check code for VCPI),
thus it contains code to handle VCPI. EMM is the VCPI server. DOS extenders
and other programs are clients and query this function after looking if there
is an EMS driver at all (if no VCPI server is there, the EMS driver returns invalid
function). I assume that QEMM is a VCPI server and a DPMI client, i.e. if
it detects DPMI it uses DPMI to emuluate VCPI, otherwise it assumes to be the
Protected Mode "Boss" in the system. I have not verified whether EMM386 does
the same thing, too, but I assume its the only way it can be done. DPMI is
obviously contained in WIN386, which owns the INT 31 (the DPMI interrupt)
in Windows 3.0 mode.
To answer your last question: I have really used and am using different
config.sys files for different purposes. This is uncomfortable but probably the
only solution if there are more drivers which want to own the machine themselves
(such as programs built with the PD MSDOS (DJ-)GCC, which does not support
any of these standards).
I have neither Paradox nor Lotus, but they seem to be programs with a
commercial DOS extender which behaves usually as a VCPI client (if VCPI is
there at all). Just check whether it works or not; this is the only thing
that I can recommend here. Hope that the above explanations give at least a
hint why something does not work if it fails.