Microsoft Corporation
16011 NE 36th Way
Box 97017
Redmond, WA 98073 9717


Date: Fri, 9 Mar 2001 08:03:50 -0800


Mr. Rod Welch
rowelch@attglobal.net
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
415 781 5700

Subject:   Email for Case SRX010207601263


******* The following is an email for an incident from Microsoft Corp.
******* So that your reply is added to the case, please forward your
******* response to email address COMPMAIL@MICROSOFT.COM
******* and place your text after the keyword MESSAGE: below.
******* Please delete all other text above & below the keywords
******* CASE_ID_NUM: SRnnn & MESSAGE: .
******* Thank you.

CASE_ID_NUM: SRX010207601263
MESSAGE:

Hello Rod,

Here is some test information:

Below is a snapshot from a machine that exhibts the same behavior as your machine causing DOSX to load one of the stubbs low. Notice that the mouse starts loading at 0D0000. 


  0D0000      IO           003100     System Data
                MOUSE      0030F0      System Program
  0D3110      MSDOS        000360     -- Free --
  0D3480      MSCDEXNT     0001D0     Program
  0D3660      REDIR        000A70     Program
  0D40E0      DOSX         000080     Data
  0D4170      MSDOS        00BE80     -- Free --

In the above case it does not matter if the REDIR and MSCDEXNT is loaded high or not. One of the DOSX stubbs is still loaded low. This is probably because DOSX requires more memory to load into than is available when it is initializing.

This is a snapshot from an older machine from a different manufacturer and notice that the mouse starts loading a 0C9000. In this cases both DOSX stubbs load high and one of the DOSX stubbs starts loading at 0CDAD0. 


  0C9000      IO           003100     System Data
                MOUSE      0030F0      System Program
  0CC110      MSDOS        000370     -- Free --
  0CC490      MSCDEXNT     0001D0     Program
  0CC670      REDIR        000A70     Program
  0CD0F0      NW16         0009D0     Program
  0CDAD0      DOSX         0087A0     Program
  0D6280      DOSX         000080     Data
  0D6310      MSDOS        009CE0     -- Free --

On the machine that does not load anything in the 0C0000 range, that I have run test on, if you boot from a dos diskette and attempt to make c800-cfff available to MS-DOS, as we use to in the days of Windows 3.0 and Windows 3.1, the machine locks and will not even get to an A: prompt.

Since we are running in a DOS virtual machine, there are limitations to MS-DOS applications. If you require DPMI memory and require more than 600K to be available to run MS-DOS applications, there is some hardware this application will not have enough conventional memory to run.

I have not discovered a way to alter this behavior. Microsoft attempts to retain backward compatiblity as practically possible but there are limits. I believe we have discovered one. Also, keep in mind that in the NT world we do not guarantee compatibility with MS-DOS applications. In future operating systesm, there may be even less memory available to an application running in a NTVDM.

[Joe's letter includes following attachment..... ]

winmail.dat

[...there is no explanation, nor expression on the purpose and disposition of this attachment.]

Sincerely,

Windows 2000 Support
Applications and Performance


Joe Griffin
joegr@microsoft.com
DOS Engineer
Microsoft Platforms Support