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