It is probably a little late in the day to again address the issue of EMS memory availability on the NTVDM sub-system of the Microsoft WinNT/2K/XP operating systems, but here goes anyway...
Conventional wisdom states that many PC workstations which run the Microsoft WinNT/2K/XP operating systems cannot alway reliably provide EMS memory for applications executing under the NTVDM DOS emulation sub-system. Since some individuals still use the NTVDM sub-system to execute older DOS applications and games which require LIM 3.2 or 4.0 EMS memory to function, they are surprised to find out that EMS memory availability is apparently a hit-or-miss probability under the NTVDM sub-system. Or so they were informed for years by either experience or well meaning, incorrect advice...
Now I should not speak ill of the departed, however here is an Internet example from a former (now deceased) Microsoft MVP who unfortunately spread misinformation about the Internet about the WinNT/2K/XP NTVDM EMS memory 'problem' for years. I am sure he was just repeating what Microsoft told him. Mr. Alex Nichol (MVP) of the UK always had this to say about EMS memory under the NTVDM environment:
From: Alex Nichol - view profile
Date: Sat, Nov 30 2002 4:00 pm
Email: Alex Nichol <alexn.mvp...@ntlworld.delete.com>
Gr […]
Show full quote
From: Alex Nichol - view profile
Date: Sat, Nov 30 2002 4:00 pm
Email: Alex Nichol <alexn.mvp...@ntlworld.delete.com>
Groups: microsoft.public.windowsxp.help_and_support
D. Kramer wrote:
>I'm trying to run a DOS based POS program in WinXP which I have
>successfully ran under all versions of Win9x. I have read all the
>posts I can find about configuring memory for DOS programs in XP. I
>have tried all the suggestions with no luck. No matter what I do or
>how I format the command, the EMM parameter in the config.nt file
>always generates an error that it doesn't like the syntax.
It is *very* tricky to get right.
In config.nt have (apart from the large number of REM lines) just
EMM = B=4000 RAM
(note the exact spaces - either side of the first = and before RAM,
none next to the second =) and
dos=high, umb
device=%SystemRoot%\system32\himem.sys
files=40
(or higher files= if needed)
In any shortcut to a DOS executable, r-click , Properties and on the
Memory page you can set an explicit value - rather than Auto - for any
EMM or XMS memory it may need, and for initial environment space
--
Alex Nichol MVP (Windows - File Systems)
Bournemouth, U.K. A...@mvps.org
Ooooh, so lack of available EMS memory in the NTVDM environment because of the 'EMS page-frame issue' is really just due to how tricky it is to get the CONFIG.NT "EMM=" statement typed correctly. See, it's all in the spaces and the 'equal' sign placement. A Microsoft Internet support type said so...
The CONFIG.NT file statement: "EMM=RAM" has nothing to do with the ability WinNT/2K/XP to provide EMS memory in the NTVDM. What that CONFIG statement DOES do is to allow the use of UMBs (not used to allocate the EMS page-frame) by other programs (typically TSRs) when an EMS LIM 4.0 64kb page-frame IS successfully allocated by the NTVDM sub-system. If that "EMM=RAM" statement is MISSING from the CONFIG.NT file, then when EMS memory (and the page-frame) is present then no other programs will be able to "Load High" in the NTVDM, even though it appears that there are 'free' unused UMBs.
Now on this fine forum the EMS page frame problem was usually blamed on motherboard resources, BIOS updates, PCI adapter ROMs, RAID controller ROMs, SCSI adapter ROMs, USB 2.0 BIOS support, etc. The NTVDM problem was first referred in this Deep Thought thread Cannot enable EMS under Win2K... back in 2002. Of course, the 'EMS issue' has existed since the WinNT4 NTVDM first appeared back in 1996. Due to PC workstation configurations of the day, it just did not rear its ugly head that often.
The WinNT/2K/XP EMS 'problem' of the NTVDM sub-system has NEVER been due to the 'motherboard' design of a particular system. It is a purposefully implemented software design with the NTVDM sub-system code - a carry-forward from the Win NT 3.x days when certain adapters which performed MMIO could not re-map (or dual-map) their MMIO registers out of the first megabyte of x86 address space. The adapters which caused problems were typically ISA/EISA or Microchannel. The EMS page-frame problem is one of the NTVDM deficiencies which stayed with the WinNT code base even until today. Microsoft was 'conservative' and used the results of a certain BIOS call made when NTDETECT.COM executes to implement the NTVDM virtual memory map.
Lack of thought caused all this nonsensical advice about disabling motherboard resources. All that was accomplished was to gut some of the necessary hardware sub-systems in modern PC workstations to get around a problem caused by a purely Microsoft software design implementation. If one thinks about the problem, this is a "Virtual Dos Machine". Why the hell should this VDM and its virtual memory map be impacted by the real PC workstation upper memory map configuration on boot? News Flash - it is not. No motherboard made in the last seven years will have a problem with configuring EMS memory in the NTVDM sub-system using one of two possible software workarounds.
Now down to actual real-world examples. First example, my PC workstation. This is an Intel Desktop Board model D925XECV2 with a Pentium 4 model 640 CPU (3.2GHz HT) with 2GB RAM operating under WinXP (SP2). The Video adapter is a Leadtek Nvidia 6600GT. Just an average system today with lots of extras included on the motherboard - HD Audio codecs, USB 2.0 support, RAID, SATA, PS/2 Mouse and keyboard ports, Firewire, Adaptec AHA-2940U2W Ultra2 SCSI PCI controller, etc. Lots of devices to take up 'valuable' memory locations.
Now let's look at some NTVDM memory maps that results from this particular hardware configuration. The attached file to this message, "NTVDM_EMSmemory_MSD_compare.gif" is a print-screen capture of my WinXP (SP2) desktop with two NTVDM console windows. The DOS-based Microsoft Diagnostics Programs v2.11 (MSD.EXE) was used to generate the NTVDM memory map reports.
First case: The window to the upper left is the default NTVDM PIF configured with 640kb base RAM, 16MB XMS memory, 8MB EMS memory and 16MB DPMI memory. What, no EMS page frame or EMS memory is present!?! It looks as if the conventional wisdom is correct! Visible in this MSD memory report is the Video Adapter RAM addresses from address A0000 to C0000. Next the Nvidia adapter BIOS from C0000 to CF800. The Adaptec AHA-2940U2W adapter BIOS occupies CF800 to D4C00. Now finally some free UMBs starting at D5000 to E0000. Darn, the E0000-F0000 address space seem to be occupied by a shadow of the expanded Intel BIOS and the F0000-100000 address seems occupied by the conventional PC/AT 64kB BIOS.
Second case: The window to the lower right is another NTVDM PIF configured with 640kb base RAM, 16MB XMS memory, 8MB EMS memory and 16MB DPMI memory. Here is actually appears that 8 megabytes of EMS memory is available! The very same PC, hmmm..., it looks as if the conventional wisdom is WRONG after all! Visible in this MSD memory report is the Video Adapter RAM addresses from address A0000 to C0000. Next the Nvidia adapter BIOS from C0000 to CF800. However, the 'virtual' Adaptec AHA-2940 adapter BIOS previously located at addresses CF800 to D4C00 has disappeared... Seems that the 'virtual' shadow expanded Intel BIOS area previously located at E0000-F0000 has also been vacated and is now conveniently available for a 64kB LIM 4.0 EMS page-frame. Golly gee, thar' be 8 megabytes of LIM 4.0 EMS memory in that NTVDM. Who'da thunk it?
There is one real BIOS ROM which IS legitimately mapped into the NTVDM virtual address space. This is the Video adapter BIOS ROM typically located at address 0xC0000 (~32kB in length). It is only used when the NTVDM console goes FULLSCREEN and no longer uses the NTVDM emulated Video BIOS, but rather the actual Video adapter BIOS mapped to the same NTVDM memory address as it occupies in the 1st MB physical address space. Without access to the actual video adapter BIOS ROM all DOS VGA graphics and VESA applications would not function.
OK. How does one know that the second visible NTVDM console window was not photoshopped or faked? I should have to prove it can be duplicated on another PC workstation by someone else, right? OK, let's do that.
All right, listen up! I need two knowledgeable, dependable and impartial volunteers. Please take two steps forward. Ah, I see two of our forum favorites - DosFreak and MiniMax. If these two fine gentlemen will PM me I will be glad to give them all the information necessary to duplicate the EMS NTVDM test on any WinNT/2K/XP PC they desire. (I hope they volunteer) My only condition is that they agree not to release the non-programmatic change method without my prior assent. They of course can show the NTVDM memory map results to prove me correct (or crazy...) The second programmatic method has been incorporated in my NTVDM extension software project ".Penultimate"
Since the life of the Windows NTVDM sub-system is drawing to a close with the rise of both 64-bit Vista and DosBox v0.65, it might be time to make sure that those that need the NTVDM to function properly can happily ride off into the operating system sunset...
What's that? How long have I known?
Since 1997...
Hope this interests,
dvwjr
