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@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, 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@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 > 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 http://vger.kernel.org/majordomo-info.html
