EMM386 not installed - protected mode software already running.

EMM386 not installed - protected mode software already running.

[Steve Cohen]

More on the "Hoo Boy this is going to be interesting" front:

I've made a little progress with the previous problems, now realizing 
that the system needs to be initialized.

I have (I think) copied the files necessary for system initialization to 
a directory under ~/.dosemu and switched my dosemu.conf to point to this 
directory for boot.  I know this configuration is correct because it 
behaves differently than when it is not present - namely the system does 
not successfully load.  This directory, unlike the stock one, is set up 
for MS-DOS, not for FreeDOS.

The symptom manifests itself as an error message eventually leading to a 
non-load of the system.  Typing F8 during config.sys initialization 
shows me the following as it steps through my config.sys

BREAK=OFF[Y,N]?Y
FILES=30[Y,N]?Y
BUFFERS=30[Y,N]?Y
STACKS=9,256[Y,N]?Y
DOS=HIGH,UMB[Y,N]?Y
LASTDRIVE=V[Y,N]?Y
SHELL=c:\dos\command.com c:\dos\ /E:1024 /P[Y,N]?Y
DEVICE=C:\DOS\HIMEM.SYS[Y,N]?Y
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?

Please forgive my noob questions but it's almost 20 years since I worked 
with DOS or had to think about HIMEM.SYS, EMM386.EXE and the like.

Steve Cohen

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

[Steve Cohen]

To put my question a little more succinctly:

Is there a way to achieve the same results as the command

DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF

through dosemu.conf entries without loading the EMM386 driver?  I don't 
know why these particular switches are necessary, but the previous 
system is my starting point here.

If there is a better way to handle these issues, I'm willing to hear them.



On 10/19/2010 08:49 AM, Steve Cohen wrote:
> More on the "Hoo Boy this is going to be interesting" front:
>
> I've made a little progress with the previous problems, now realizing
> that the system needs to be initialized.
>
> I have (I think) copied the files necessary for system initialization to
> a directory under ~/.dosemu and switched my dosemu.conf to point to this
> directory for boot. I know this configuration is correct because it
> behaves differently than when it is not present - namely the system does
> not successfully load. This directory, unlike the stock one, is set up
> for MS-DOS, not for FreeDOS.
>
> The symptom manifests itself as an error message eventually leading to a
> non-load of the system. Typing F8 during config.sys initialization shows
> me the following as it steps through my config.sys
>
> BREAK=OFF[Y,N]?Y
> FILES=30[Y,N]?Y
> BUFFERS=30[Y,N]?Y
> STACKS=9,256[Y,N]?Y
> DOS=HIGH,UMB[Y,N]?Y
> LASTDRIVE=V[Y,N]?Y
> SHELL=c:\dos\command.com c:\dos\ /E:1024 /P[Y,N]?Y
> DEVICE=C:\DOS\HIMEM.SYS[Y,N]?Y
> 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?
>
> Please forgive my noob questions but it's almost 20 years since I worked
> with DOS or had to think about HIMEM.SYS, EMM386.EXE and the like.
>
> Steve Cohen
> --
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

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

[Frank Cox]

On Tue, 2010-10-19 at 09:28 -0500, Steve Cohen wrote:
> Is there a way to achieve the same results as the command
> 
> DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF
> 
> through dosemu.conf entries without loading the EMM386 driver?  I
> don't 
> know why these particular switches are necessary, but the previous 
> system is my starting point here.

emm.sys comes with dosemu.  the x= parts of your command are just
excluding certain memory areas from being managed by the emm driver.
Depending on why those areas are being excluded, it may not be necessary
to do that in your dosemu install.

Try loading emm.sys instead of emm386.exe and see if anything
interesting happens.
-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

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

[Frank Cox]

On Tue, 2010-10-19 at 10:09 -0600, Frank Cox wrote:
> Try loading emm.sys instead of emm386.exe and see if anything
> interesting happens.

ems.sys, that is.

Man, expanded memory and extended memory... and I still can't get it
right after how many years?

Note also the section regarding memory layout, which is described here:

http://www.dosemu.org/docs/README/1.4/config.html

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

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

[Steve Cohen]

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:

BREAK=OFF
FILES=30
BUFFERS=30
STACKS=9,256
DOS=HIGH,UMB
LASTDRIVE=V
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF
  DEVICEHIGH=C:\DOS\SETVER.EXE
  SHELL=c:\command.com c:\dos\ /E:1024 /P
  DEVICEHIGH=C:\NFS\PCNFS.SYS
DEVICE=C:\NFS\SOCKDRV.SYS
DEVICE=C:\LANMAN\PROTMAN.SYS /I:C:\LANMAN
  REM INTEL ETHERPRO16
DEVICEHIGH=C:\LANMAN\EXP16.DOS
DEVICE=C:\LANMAN\NFS-NDIS.SYS

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

[Bryan J Smith]

Most of the 386, and all of the 286, PharLap Extenders required not just EMS 
and/or XMS, but pre-date DPMI (DOS Protected Mode Interface) APIs.  They would 
use an earlier approach called VCPI (Virtual Control Program Interface).

The main difference between DPMI and VCPI is that DPMI programs have a governing 
Ring 0 manager they are serviced by.  In DOS, this is HIMEM/EMM386.  In NT, this 
is the NTVDM.  In Linux, this is the DOSEmu system.  This allows multiple 
programs to utilize memory extensions.

VCPI is where one program and only one program can take control of Ring 0 for 
its own uses.  And that makes it not only incompatible with DOSEmu, but also 
NTVDM (i.e., won't run under Windows NT, 2000, XP, Vista, 7, etc...).  DPMI 
addressed the shortcomings with VCPI.

Only latter PharLap extenders supported DPMI, and all of them were 386 IIRC.  My 
knowledge is a bit aged, but I believe this information is correct.  Attempting 
to run the program under any 32-bit NT 4/5/6 release would also verify the same.

DOSBox _may_ be an option, as I've seen VCPI programs sometimes execute under 
it.

-- 
Bryan J  Smith             Professional, Technical Annoyance 
Linked Profile:           http://www.linkedin.com/in/bjsmith 
------------------------------------------------------------ 
"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@comcast.net>
To: Mike McCarty <Mike.McCarty@sbcglobal.net>; linux-msdos@vger.kernel.org
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:

BREAK=OFF
FILES=30
BUFFERS=30
STACKS=9,256
DOS=HIGH,UMB
LASTDRIVE=V
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF
DEVICEHIGH=C:\DOS\SETVER.EXE
SHELL=c:\command.com c:\dos\ /E:1024 /P
DEVICEHIGH=C:\NFS\PCNFS.SYS
DEVICE=C:\NFS\SOCKDRV.SYS
DEVICE=C:\LANMAN\PROTMAN.SYS /I:C:\LANMAN
REM INTEL ETHERPRO16
DEVICEHIGH=C:\LANMAN\EXP16.DOS
DEVICE=C:\LANMAN\NFS-NDIS.SYS

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Bryan J Smith]

Refresh yourself:  
- http://en.wikipedia.org/wiki/Upper_Memory_Block (UMB)
- http://en.wikipedia.org/wiki/Expanded_memory (EMS)
- http://en.wikipedia.org/wiki/EXtended_Memory_Specification (XMS)
- http://en.wikipedia.org/wiki/VCPI
- http://en.wikipedia.org/wiki/DPMI

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 
systems.

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 
usage
- 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 
VCPI.

-- 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:           http://www.linkedin.com/in/bjsmith 
------------------------------------------------------------ 
"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@comcast.net>
To: Mike McCarty <Mike.McCarty@sbcglobal.net>; linux-msdos@vger.kernel.org
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:

BREAK=OFF
FILES=30
BUFFERS=30
STACKS=9,256
DOS=HIGH,UMB
LASTDRIVE=V
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE frame=none x=C000-C7FF x=E000-E7FF
DEVICEHIGH=C:\DOS\SETVER.EXE
SHELL=c:\command.com c:\dos\ /E:1024 /P
DEVICEHIGH=C:\NFS\PCNFS.SYS
DEVICE=C:\NFS\SOCKDRV.SYS
DEVICE=C:\LANMAN\PROTMAN.SYS /I:C:\LANMAN
REM INTEL ETHERPRO16
DEVICEHIGH=C:\LANMAN\EXP16.DOS
DEVICE=C:\LANMAN\NFS-NDIS.SYS

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A826849D-9CF0-6C1F-CD7C-8D85ADCB8FD9
1.03.01

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

[Bryan J Smith]

Just a clarification ...

I believe EMS.SYS (please correct my ignorance) actually provides EMS memory 
services, including UMB (640-1MiB backfill option) correct?  It's the DOS Real86 
handler for EMS requests to the XMS memory and DPMI service facilities, which 
are provided by DOSEmu.

I didn't mean to say EMS.SYS provides DPMI.  There are always interrupt and 
other service tie-ins that sometimes have to be <1MiB, hence the existence of 
EMS.SYS.




----- Original Message ----
From: Bryan J Smith <b.j.smith@ieee.org>

Refresh yourself:  
- http://en.wikipedia.org/wiki/Upper_Memory_Block (UMB)
- http://en.wikipedia.org/wiki/Expanded_memory (EMS)
- http://en.wikipedia.org/wiki/EXtended_Memory_Specification (XMS)
- http://en.wikipedia.org/wiki/VCPI
- http://en.wikipedia.org/wiki/DPMI

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 
systems.

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 
usage
- 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 

VCPI.

-- 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:           http://www.linkedin.com/in/bjsmith 
------------------------------------------------------------ 
"Now if you own an automatic ... sell it!
You are totally missing out on the coolest part of driving"
-- Johnny O'Connell



A826849D-9CF0-6C1F-CD7C-8D85ADCB8FD9
1.03.01

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

[Steve Cohen]

Thanks for this information, Bryan.  Unfortunately, it, together with 
further investigations into our source code base, convinces me that our 
application does indeed depend on the VCPI-based early versions of 
PharLap (I didn't know where to look previously) and will ultimately 
prove to be incompatible with DOSEmu.  Some of the PharLap links are 
pretty loose and could possibly be converted to work differently, but 
some of the third party stuff like Greenleaf Comms is pretty tightly 
linked with PharLap286 and I don't think we want to be changing that.

But that's okay, this little walk down "memory lane" (pun intended) 
didn't waste too much time and has given me some other ideas besides 
rewrite that may ultimately prove more fruitful.

I'd like to thank all you guys here for your support,  Viva Open Source.

Steve

On 10/19/2010 02:34 PM, Bryan J Smith wrote:
> Refresh yourself:
> - http://en.wikipedia.org/wiki/Upper_Memory_Block (UMB)
> - http://en.wikipedia.org/wiki/Expanded_memory (EMS)
> - http://en.wikipedia.org/wiki/EXtended_Memory_Specification (XMS)
> - http://en.wikipedia.org/wiki/VCPI
> - http://en.wikipedia.org/wiki/DPMI
>
> 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
> systems.
>
> 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
> usage
> - 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
> VCPI.
>
> -- 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).
>

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

[Bryan J Smith]

If it's PharLap286, I want to almost say -- for certain -- it's first-gen, Ring 
0 gobbling VCPI.

Again, an additional test is to try it on 32-bit NT (4-6) and its NTVDM.  If it 
doesn't work (try several), then it's not DPMI compatible and taking issue with 
something else holding Ring 0.  DPMI really addresses all of the shortcomings of 
VCPI, and allows multi-tasking (really task sharing, to a point, long story) in 
DOS.  As such, real, 32-bit Virtual86/Protected386 operating systems (NT/NTVDM, 
Linux/DOSEmu, etc...) can then offer DPMI with the same capabilities.

I also mentioned DOSBox.  DOSBox can actually emulate Ring 0, including for some 
VCPI programs.  According to the status page, it seems to be limited to Origin 
games, don't know what extender they used.  Could be unrelated to PharLap and 
most early, VCPI-based implementations.  But it's worth a shot.
  http://www.dosbox.com/status.php?show_status=1  

DOSBox isn't a full DOS in the traditional sense, but a DOS emulator that 
doesn't require DOS itself.  DOSEmu is more like a virtualized DPMI environment, 
and then you run DOS under it -- like NTVDM in NT/Windows, although Microsoft 
bundles the required DOS support (DOS kernel, COMMAND.COM instead of NT's native 
CMD.EXE, etc...).

-- Bryan

P.S.  For several years Concurrent (among others) was marketing itself as a 
networked/remote terminal, multiuser DOS solution.  Understand these solutions 
are based on DR-DOS and DPMI-based DPMS, and will also be incompatible with VCPI 
if those services load.  Only Real86 DOS without anything using DPMI or an 
emulated DOS under another OS, with Ring 0 available (emulated) will work, for 
most of those early extenders.


----- Original Message ----
From: Steve Cohen <stevecoh1@comcast.net>

Thanks for this information, Bryan.  Unfortunately, it, together with 
further investigations into our source code base, convinces me that our 
application does indeed depend on the VCPI-based early versions of 
PharLap (I didn't know where to look previously) and will ultimately 
prove to be incompatible with DOSEmu.  Some of the PharLap links are 
pretty loose and could possibly be converted to work differently, but 
some of the third party stuff like Greenleaf Comms is pretty tightly 
linked with PharLap286 and I don't think we want to be changing that.

But that's okay, this little walk down "memory lane" (pun intended) 
didn't waste too much time and has given me some other ideas besides 
rewrite that may ultimately prove more fruitful.

I'd like to thank all you guys here for your support,  Viva Open Source.



A826849D-9CF0-6C1F-CD7C-8D85ADCB8FD9
1.03.01

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

[Steve Cohen]

I originally dismissed DosBox for its game-oriented disclaimers.  In 
particular, our application needs LAN access, and they explicitly said 
that was not well supported.

Our efforts are now going in a different direction - bringing the 
application on more modern hardware in real, not emulated DOS and 
figuring out why it fails there.  This effort was made in the past and 
abandoned, perhaps too soon.


On 10/20/2010 10:19 AM, Bryan J Smith wrote:
> If it's PharLap286, I want to almost say -- for certain -- it's first-gen, Ring
> 0 gobbling VCPI.
>
> Again, an additional test is to try it on 32-bit NT (4-6) and its NTVDM.  If it
> doesn't work (try several), then it's not DPMI compatible and taking issue with
> something else holding Ring 0.  DPMI really addresses all of the shortcomings of
> VCPI, and allows multi-tasking (really task sharing, to a point, long story) in
> DOS.  As such, real, 32-bit Virtual86/Protected386 operating systems (NT/NTVDM,
> Linux/DOSEmu, etc...) can then offer DPMI with the same capabilities.
>
> I also mentioned DOSBox.  DOSBox can actually emulate Ring 0, including for some
> VCPI programs.  According to the status page, it seems to be limited to Origin
> games, don't know what extender they used.  Could be unrelated to PharLap and
> most early, VCPI-based implementations.  But it's worth a shot.
>    http://www.dosbox.com/status.php?show_status=1
>
> DOSBox isn't a full DOS in the traditional sense, but a DOS emulator that
> doesn't require DOS itself.  DOSEmu is more like a virtualized DPMI environment,
> and then you run DOS under it -- like NTVDM in NT/Windows, although Microsoft
> bundles the required DOS support (DOS kernel, COMMAND.COM instead of NT's native
> CMD.EXE, etc...).
>
> -- Bryan
>
> P.S.  For several years Concurrent (among others) was marketing itself as a
> networked/remote terminal, multiuser DOS solution.  Understand these solutions
> are based on DR-DOS and DPMI-based DPMS, and will also be incompatible with VCPI
> if those services load.  Only Real86 DOS without anything using DPMI or an
> emulated DOS under another OS, with Ring 0 available (emulated) will work, for
> most of those early extenders.
>
>
> ----- Original Message ----
> From: Steve Cohen<stevecoh1@comcast.net>
>
> Thanks for this information, Bryan.  Unfortunately, it, together with
> further investigations into our source code base, convinces me that our
> application does indeed depend on the VCPI-based early versions of
> PharLap (I didn't know where to look previously) and will ultimately
> prove to be incompatible with DOSEmu.  Some of the PharLap links are
> pretty loose and could possibly be converted to work differently, but
> some of the third party stuff like Greenleaf Comms is pretty tightly
> linked with PharLap286 and I don't think we want to be changing that.
>
> But that's okay, this little walk down "memory lane" (pun intended)
> didn't waste too much time and has given me some other ideas besides
> rewrite that may ultimately prove more fruitful.
>
> I'd like to thank all you guys here for your support,  Viva Open Source.
>
>
>
> A826849D-9CF0-6C1F-CD7C-8D85ADCB8FD9
> 1.03.01
>

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

[Bryan J Smith]

Networking would not be a DOSEmu, DOSBox issue, etc... but a Real86 DOS issue 
itself.

Real86 MS-DOS has very, very primitive networking clients, and ones that eat an 
enormous amount of Real86 (<1MiB) memory at that.  The Microsoft Networking 
Client (MSNC) for TCP/IP works very poorly on real MS-DOS itself, with all sorts 
NDIS2/3 drivers lacking.  And then that would still leave a great amount of 
"client" programs lacking after that.

DR-DOS 7 and its licensed variants that use DPMS (DPMI services) to off-load the 
massive footprint of the network client above Real86 (>1MiB) would be 
incompatible with VCPI programs and similar extenders that don't use DMPI.  So 
that's not an option either.

In fact, what protocol/access do you need for networking?

Or are you trying to use network drive shares?  The latter is a real can-o-worms 
with Real86 DOS.  But that's where "mapping" Linux mounts in your host into 
DOSEmu or DOSBox take over.  DOS sees them as local hard drives.  Now understand 
Linux, or even NT/Windows for that matter, can_not_ solve the problem of DOS 
programs and DOS' legacy of virtually non-existent locking.  If the program 
isn't designed for even basic SHARE.EXE type primitive locking, then no solution 
is going to help you much.

DOSBox does, however, do a decent job of converting old IPX into TCP/IP, if your 
old program does IPX.  This is especially nice for old programs that want to 
communicate IPX for message passing between nodes, and can use a TCP/IP 
network.  There are just a couple of setup details.  IPX is more 
notification-type broadcast whereas TCP/IP is more lookup/point-access.  But it 
can work.

Again, what do you need networking for?  If for shares, then use the underlying 
Linux host, if DOSBox works.  Map real Linux mounts in as drive letters.  
However, be warned about file locking issues, especially if the program was 
_not_ designed for multiple systems to read the same, shared files.  Again, if 
it wasn't designed for at least use with SHARE.EXE, then forget it.  You're 
going to corrupt things.

But if it's for IPX communication just between nodes, message passing, etc..., 
then DOSBox may work.  I'd have to read up on your program, and how DOSBox could 
be configured.  And that's assuming its primitive Ring 0 support works for 
PharLap 286.  In fact, this DOSEmu document suggests that Origin was using the 
PharLap 286 extender early on:  

  http://www.dosemu.org/docs/EMUfailure/t1.html#AEN20  

That means DOSBox might work with your program, as it provides the proprietary 
extensions to support PharLap 286's use of EMS and Ring 0.  It also mentions 
JEMM (based on FreeDOS' EMM386) as an additional option to try with DOSEmu 
itself, to provide the same (never tried it myself).
  http://www.japheth.de/Jemm.html  
  http://www.japheth.de/Jemm/README.html  

In fact, this looks really promising (from the docs) ...


"5. Emulation of privileged Opcodes   To provide Expanded Memory an EMM Emulator 
like Jemm runs the cpu in  so-called v86-mode. This mode does not allow to run 
privileged opcodes.  Some of these opcodes which might be useful for application 
programs  are emulated by Jemm, however. These are:    - mov <special_reg>, 
<reg>   ;special_reg = CRn, DRn, TRn  - mov <reg>, <special_reg>   ;reg = eax, 
ebx, ecx, edx, esi, edi, ebp  - WBINVD  - INVD  - WRMSR  - RDMSR  - RDTSC"

The way DOS/Win works is using Virtual86 (V86) of the i386+, and that's  how 
most DPMI solutions work once they start providing the services to  programs.  
V86 doesn't allow some opcodes of the Protected286/386 modes  to work, most 
definitely for PharLap 286 which uses Protected286.  JEMM  seems to emulate 
these calls, solving the problem (or at least trying).
It's worth a shot.  Anyone use JEMM under DOSEmu before?   Does one use it in 
place of EMS.SYS?  Or after EMS.SYS?
WARNING:  I have no idea of its current state, capabilities or
compatibility with DOSEMu.

-- 
Bryan J  Smith             Professional, Technical Annoyance 
Linked Profile:           http://www.linkedin.com/in/bjsmith 
------------------------------------------------------------ 
"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@comcast.net>
To: Bryan J Smith <b.j.smith@ieee.org>
Cc: Mike McCarty <Mike.McCarty@sbcglobal.net>; linux-msdos@vger.kernel.org
Sent: Wed, October 20, 2010 12:14:47 PM
Subject: Re: EMM386 not installed - protected mode software already running.

I originally dismissed DosBox for its game-oriented disclaimers.  In 
particular, our application needs LAN access, and they explicitly said 
that was not well supported.

Our efforts are now going in a different direction - bringing the 
application on more modern hardware in real, not emulated DOS and 
figuring out why it fails there.  This effort was made in the past and 
abandoned, perhaps too soon.


On 10/20/2010 10:19 AM, Bryan J Smith wrote:
> If it's PharLap286, I want to almost say -- for certain -- it's first-gen, 
Ring
> 0 gobbling VCPI.
>
> Again, an additional test is to try it on 32-bit NT (4-6) and its NTVDM.  If 
it
> doesn't work (try several), then it's not DPMI compatible and taking issue 
with
> something else holding Ring 0.  DPMI really addresses all of the shortcomings 
>of
> VCPI, and allows multi-tasking (really task sharing, to a point, long story) 
in
> DOS.  As such, real, 32-bit Virtual86/Protected386 operating systems 
(NT/NTVDM,
> Linux/DOSEmu, etc...) can then offer DPMI with the same capabilities.
>
> I also mentioned DOSBox.  DOSBox can actually emulate Ring 0, including for 
>some
> VCPI programs.  According to the status page, it seems to be limited to Origin
> games, don't know what extender they used.  Could be unrelated to PharLap and
> most early, VCPI-based implementations.  But it's worth a shot.
>    http://www.dosbox.com/status.php?show_status=1
>
> DOSBox isn't a full DOS in the traditional sense, but a DOS emulator that
> doesn't require DOS itself.  DOSEmu is more like a virtualized DPMI 
>environment,
> and then you run DOS under it -- like NTVDM in NT/Windows, although Microsoft
> bundles the required DOS support (DOS kernel, COMMAND.COM instead of NT's 
>native
> CMD.EXE, etc...).
>
> -- Bryan
>
> P.S.  For several years Concurrent (among others) was marketing itself as a
> networked/remote terminal, multiuser DOS solution.  Understand these solutions
> are based on DR-DOS and DPMI-based DPMS, and will also be incompatible with 
>VCPI
> if those services load.  Only Real86 DOS without anything using DPMI or an
> emulated DOS under another OS, with Ring 0 available (emulated) will work, for
> most of those early extenders.
>
>
> ----- Original Message ----
> From: Steve Cohen<stevecoh1@comcast.net>
>
> Thanks for this information, Bryan.  Unfortunately, it, together with
> further investigations into our source code base, convinces me that our
> application does indeed depend on the VCPI-based early versions of
> PharLap (I didn't know where to look previously) and will ultimately
> prove to be incompatible with DOSEmu.  Some of the PharLap links are
> pretty loose and could possibly be converted to work differently, but
> some of the third party stuff like Greenleaf Comms is pretty tightly
> linked with PharLap286 and I don't think we want to be changing that.
>
> But that's okay, this little walk down "memory lane" (pun intended)
> didn't waste too much time and has given me some other ideas besides
> rewrite that may ultimately prove more fruitful.
>
> I'd like to thank all you guys here for your support,  Viva Open Source.
>
>
>
> A826849D-9CF0-6C1F-CD7C-8D85ADCB8FD9
> 1.03.01
>


A826849D-9CF0-6C1F-CD7C-8D85ADCB8FD9
1.03.01

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

[Mike McCarty]

Bryan J Smith wrote:
> If it's PharLap286, I want to almost say -- for certain -- it's first-gen, Ring 
> 0 gobbling VCPI.
> 
> Again, an additional test is to try it on 32-bit NT (4-6) and its NTVDM.  If it 
> doesn't work (try several), then it's not DPMI compatible and taking issue with 

[...]

> I also mentioned DOSBox.  DOSBox can actually emulate Ring 0, including for some 
> VCPI programs.  According to the status page, it seems to be limited to Origin 

[...]

> doesn't require DOS itself.  DOSEmu is more like a virtualized DPMI environment, 
> and then you run DOS under it -- like NTVDM in NT/Windows, although Microsoft 

[...]

> P.S.  For several years Concurrent (among others) was marketing itself as a 
> networked/remote terminal, multiuser DOS solution.  Understand these solutions 
> are based on DR-DOS and DPMI-based DPMS, and will also be incompatible with VCPI 
> if those services load.  Only Real86 DOS without anything using DPMI or an 
> emulated DOS under another OS, with Ring 0 available (emulated) will work, for 
> most of those early extenders.

Another possibility is to run something like QEMU or BOCHS. I've had
good success with QEMU and the kernel extension. It runs at nearly
native speed for most functions. One would have to have a legal
version of MSDOS, or possibly FreeDOS would work.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!

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

[Frank Cox]

On Wed, 2010-10-20 at 13:22 -0500, Mike McCarty wrote:
> One would have to have a legal
> version of MSDOS, or possibly FreeDOS would work.

I think there was a freely downloadable version of DRDOS that was
available at one time, too.
-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

EMM386 not installed - protected mode software already running.

[solarflow99]

On Wed, Oct 20, 2010 at 1:11 PM, Frank Cox <theatre@sasktel.net> wrote:
>
> On Wed, 2010-10-20 at 13:22 -0500, Mike McCarty wrote:
>> One would have to have a legal
>> version of MSDOS, or possibly FreeDOS would work.
>
> I think there was a freely downloadable version of DRDOS that was
> available at one time, too.

And if not, just copy it.  As if someone is going to care about
copying 20 year old DOS.  I pir8 it.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mike McCarty]

solarflow99 wrote:
> And if not, just copy it.  As if someone is going to care about
> copying 20 year old DOS.  I pir8 it.

This was not the best post you've ever made, I trow. You may
not be aware of it, but Microsoft does care, and aggressively
pursues such kinds of piracy. Disney also does so, and has
sued several school districts for showing their movies as
treats for kids.

Beyond that, I don't want to live in a lawless society.

So, could we get back to discussing legal means to achieve his goals?

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!

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

[solarflow99]

On Wed, Oct 20, 2010 at 2:06 PM, Mike McCarty
<Mike.McCarty@sbcglobal.net> wrote:
> solarflow99 wrote:
>>
>> And if not, just copy it.  As if someone is going to care about
>> copying 20 year old DOS.  I pir8 it.
>
> This was not the best post you've ever made,

hehe, ok.  I take back my last message, wait for the license to expire
then copy it.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Paul Crawford]

On 20/10/10 22:06, Mike McCarty wrote:
> This was not the best post you've ever made, I trow. You may
> not be aware of it, but Microsoft does care, and aggressively
> pursues such kinds of piracy. Disney also does so, and has
> sued several school districts for showing their movies as
> treats for kids.
>
> Beyond that, I don't want to live in a lawless society.
>
> So, could we get back to discussing legal means to achieve his goals?

It would, however, be amusing to see MS pursue legal action for software 
they are no longer willing to supply!

Or are they still willing to sell you a copy/license?

Realistically, you could find a set of old DOS disks on eBay or similar 
if you are worried. It is not as if they have any serial number or 
odious "activation" process to interfere with such a transfer.

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

[Steve Cohen]

On 10/20/2010 04:06 PM, Mike McCarty wrote:
> This was not the best post you've ever made, I trow.

trow?

Never heard that word before, though it's easy enough to guess its 
meaning from context.  Wiktionary calls it "obsolete" though I guess not.

http://en.wiktionary.org/wiki/trow