Re: EMM386 not installed - protected mode software already running.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Refresh yourself:  
- (UMB)
- (EMS)
- (XMS)

EMS boards were created for 286/386 systems so they could address more than 
640KiB.  EMS could also be used to backfill memory below 1MiB, not used for 
other things (BIOS, ROM, video mappings, etc...), that DOS could address in 
Real86 mode.  These areas were known as UMB.  The devicehigh/loadhigh commands 
loads programs into UMB areas.

XMS was designed to take advantage of Protected286 and Protected386 memory above 
1MiB.  One of the first hacks found for Real86 was that the A20 line that 
allowed a "final segment" of an extra 64KiB that was actually at 1MiB + 64KiB to 
be utilized (segment FFFFh + offset 0000-FFFFh = memory 10000-1FFFF0h), for a 
single COM (64KiB) object.  Typically this was utilized for DOS itself on i386 

Additionally, on the i386, one could emulate XMS as EMS (and a very few,  
select, specially designed 286 systems allowed this as well).  This was  done 
with DOS 6/7 via EMM386.SYS, designed for the new 386Enhanced mode of the new 
Windows 3.0, which also introduced DPMI (latter discussion follows).  With the 
i386 and software-emulated EMS, UMB usage became commonplace for systems.

VCPI, Pioneered by PharLap, was one of the first DOS extender approaches to 
allow normally Real86 programs to use and execute beyond 640KiB/1MiB.  It took 
control of Ring 0, meaning nothing else could utilize it.  It was not designed 
for sharing, although some environments would use VCPI to run multiple Real86 
programs, or specially designed programs for their environment.

DPMI was introduced by Microsoft to support its new 386Enhanced mode in Windows 
3.0 (386-only).  It shunted the processor between Real86-Protected86, and took 
advantage of Virtual86 mode in the 386.  DPMI differed from VCPI in the fact 
that the DPMI manager (EMM386.SYS) controlled Ring 0 and serviced requests from 
other programs via DPMI.  This approach continued with Windows 3.x, 95/98/Me 
(yes, 386Enhanced -- MS-DOS 7.x was just bundled in 95/98/Me).

The NT Virtual DOS Machine (NTVDM) provides DPMI (and EMS/XMS) in 32-bit 
NT-based Windows (4.0, 5.x aka 2000/XP/2003, 6.x aka Vista/2008/7) and controls 
Ring 0.  DOSEmu provides DPMI (and EMS/XMS) via EMS.SYS, and DOSEmu controls 
Ring 0.  Anything that already controls Ring 0 is inherently _incompatible_ with 
VCPI programs.

This means VCPI programs are incompatible with:  
- The NTVDM in any NT-based Windows system
- The EMS.SYS in any DOSEmu-based system
- Any other 32-bit** operating system that provides DPMI and controls Ring 0
- Any Real86 DOS w/EMM386.SYS system that is already providing DPMI to at least 
one program

In the case of the last, that means VCPI is incompatible with:  
- Real86 mode DOS that has at least one DPMI program running
- Windows 3.x in 386Enhanced mode (or 95/98/Me by default) which uses DPMI

The only way to get a VCPI program (most early-to-mid release PharLap extenders) 
is to run:  

- DR-DOS/MS-DOS 5/6/7 with EMM386.SYS and _no_ DPMI programs or other Ring 0 
- This includes not running any DR-DOS DOS Protected Mode Services (DPMS)

DPMS uses DPMI so select drivers can load above 1MiB, beyond what HIMEM/UMB can 
do.  DPMS, because it uses DPMI, is incompatible with any program that requires 
Ring 0 access, like VCPI.  If you're using PharLap, there is a good chance it is 

-- Bryan

**NOTE:  64-bit x86-64 processors in Long Mode (48-bit flat addressing,  52-bit 
processor address extensions) doesn't even support Virtual86, and  requires a 
completely new DPMI framework (with emulation of prior  registers no longer 
supported in this mode).

Bryan J  Smith             Professional, Technical Annoyance 
Linked Profile:  
"Now if you own an automatic ... sell it!
You are totally missing out on the coolest part of driving"
-- Johnny O'Connell

----- Original Message ----
From: Steve Cohen <stevecoh1@xxxxxxxxxxx>
To: Mike McCarty <Mike.McCarty@xxxxxxxxxxxxx>; linux-msdos@xxxxxxxxxxxxxxx
Sent: Tue, October 19, 2010 12:54:33 PM
Subject: Re: EMM386 not installed - protected mode software already running.

On 10/19/2010 10:55 AM, Mike McCarty wrote:
> Steve Cohen wrote:
>> More on the "Hoo Boy this is going to be interesting" front:
> [...]
>> DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF [Y,N]?Y
>> EMM386 not installed - protected mode software already running.
>> What does this mean? What protected mode software is already running?
> None. The environment of DOSEMU provides a DPMI w/o having to
> load a driver, so it has the same effect as though a driver
> were loaded, however.
> Mike

OK, trying to wrap my head around this though the 20-year fog.  EMS, XMS, UMB, 
DPMI.  Yecch.

I've tried commenting out the
    DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF
line.  This gives me the "No UMBs" error on the first devicehigh= call

As can be seen from my earlier posts, this application, as designed, made use of 
HIMEM.SYS, EMM386.EXE, etc.  This does not appear to be compatible with DOSEMU 
as configured out of the box.

Looking for opinions here.  Would you think I am best off trying start from 
Freedos and tweak memory as needed or from MS-DOS?  If I use MS-DOS under DOSEMU 
what is the solution to add UMBs?  Or, am I best advised to avoid all this UMB 
and devicehigh stuff and just try to load them "normally"?

Here is the config.sys I am trying to load:

DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF
SHELL=c:\ c:\dos\ /E:1024 /P

To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux Console]     [Linux Audio]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Camping]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Samba]     [Linux Media]     [Fedora Users]

  Powered by Linux