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

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


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

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:  

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

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:  
"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: Bryan J Smith <b.j.smith@xxxxxxxx>
Cc: Mike McCarty <Mike.McCarty@xxxxxxxxxxxxx>; linux-msdos@xxxxxxxxxxxxxxx
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, 
> 0 gobbling VCPI.
> Again, an additional test is to try it on 32-bit NT (4-6) and its NTVDM.  If 
> doesn't work (try several), then it's not DPMI compatible and taking issue 
> something else holding Ring 0.  DPMI really addresses all of the shortcomings 
> VCPI, and allows multi-tasking (really task sharing, to a point, long story) 
> DOS.  As such, real, 32-bit Virtual86/Protected386 operating systems 
> Linux/DOSEmu, etc...) can then offer DPMI with the same capabilities.
> I also mentioned DOSBox.  DOSBox can actually emulate Ring 0, including for 
> 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.
> 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 
> 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 
> 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 
> 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@xxxxxxxxxxx>
> 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

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