CONTACTS 
0201 - Microsoft Corporation
020101 - Mr. Joe Griffin; DOS Engineer =704 582 8692
020102 - joegr@microsoft.com
020103 - Windows 2000 Support  =800 936 4900
020104 - Applications and Performance

SUBJECTS
SDS and Medit
Performance Slower for SDS Reports than C11
Config.nt in 00 02 System32, 010202
Autoexec.nt in 00 02 System32, 010202
Performance Slower on Faster Machine
Microsoft Case SRX010207601263 W2K Crashed Installation Support Corre
Microsoft Does Not Support EMM386 Test Requested on 010228

2109 -    ..
2110 - Summary/Objective
2111 -
211101 - Follow up ref SDS 41 0000, ref SDS 40 0000.
211102 -
211103 - Received ref DRT 1 0001 from Joe Griffith.
211104 -
211105 -       [On 010313 letter to Microsoft on progress solving problems
211106 -       reported on 010207 under this case. ref SDS 42 0001
211107 -
211108 - Joe does not mention in his letter today.....
211109 -
211110 -     Letter to Joe, ref DIP 4 0001 submitted on 010228, asking for
211111 -     assistance conducting the EMM386 test, as a supplemental response,
211112 -     ref SDS 41 0001, to Joe's letter, ref DRP 4 0001, on 010227, that
211113 -     requested c13 be tested running emm386. ref SDS 40 QP8O  Joe does
211114 -     not provide assistance on conducting the test he requested,
211115 -     possibly because he seems to have concluded it is not necessary.
211116 -     ref DRT 1 00GP
211117 -
211118 -     Letter to Joe, ref DIP 3 0001, submitted on 010227 asking
211119 -     Microsoft to call, ref SDS 40 RR4F, and clarify information in
211120 -     Joe's letter earlier on 010227 about conducting a test on c13
211121 -     using EMM386. ref SDS 40 QP8O
211122 -
211123 -         Does this mean Joe feels this test is not necessary now?
211124 -
211125 -     Letter to Joe, ref DIP 3 XF6L, submitted on 010227 that explains
211126 -     need for feedback in communications that adds value to Knowledge
211127 -     Management. ref SDS 40 4161
211128 -
211129 -     Letter to Joe, ref DIP 3 00FR, submitted on 010227 asking for
211130 -     follow up procedure to resolve a case, where initial engineer
211131 -     confirms problem, as Joe does again today. ref SDS 40 4M4L
211132 -
211133 -  ..
211134 - Joe says today....
211135 -
211136 -     Below is a snapshot from a machine that exhibts the same behavior
211137 -     as your machine causing DOSX to load one of the stubbs low. Notice
211138 -     that the mouse starts loading at 0D0000. ref DRT 1 008H
211139 -
211140 -
211141 -          0D0000      IO           003100     System Data
211142 -                        MOUSE      0030F0      System Program
211143 -          0D3110      MSDOS        000360     -- Free --
211144 -          0D3480      MSCDEXNT     0001D0     Program
211145 -          0D3660      REDIR        000A70     Program
211146 -          0D40E0      DOSX         000080     Data
211147 -          0D4170      MSDOS        00BE80     -- Free --
211148 -
211149 -     ..
211150 -     In the above case it does not matter if the REDIR and
211151 -     MSCDEXNT is loaded high or not.   One of the DOSX stubbs is still
211152 -     loaded low.  This is probably because DOSX requires more memory to
211153 -     load into than is available when it is initializing. ref DRT 1
211154 -     004M
211155 -
211156 -         Joe's report today confirms the defect encountered in the w2k
211157 -         program installed on c13, as stated in our letter, ref DIP 3
211158 -         004O, submitted on 010227, ref SDS 40 1R4I, and originally
211159 -         submitted to Microsoft on 010207. ref SDS 24 YX7N and which
211160 -         Microsoft confirmed at that time. ref SDS 24 OE3J
211161 -
211162 -
211163 - Joe continues....
211164 -
211165 -     This is a snapshot from an older machine from a different
211166 -     manufacturer and notice that the mouse starts loading a 0C9000. In
211167 -     this cases both DOSX stubbs load high and one of the DOSX stubbs
211168 -     starts loading at 0CDAD0. ref DRT 1 AP9F
211169 -
211170 -          0C9000      IO           003100     System Data
211171 -                        MOUSE      0030F0      System Program
211172 -          0CC110      MSDOS        000370     -- Free --
211173 -          0CC490      MSCDEXNT     0001D0     Program
211174 -          0CC670      REDIR        000A70     Program
211175 -          0CD0F0      NW16         0009D0     Program
211176 -          0CDAD0      DOSX         0087A0     Program
211177 -          0D6280      DOSX         000080     Data
211178 -          0D6310      MSDOS        009CE0     -- Free --
211179 -     ..
211180 -     On the machine that does not load anything in the 0C0000
211181 -     range, that I have run test on, if you boot from a dos diskette
211182 -     and attempt to make c800-cfff available to MS-DOS, as we use to in
211183 -     the days of Windows 3.0 and Windows 3.1, the machine locks and
211184 -     will not even get to an A: prompt. ref DRT 1 00EO
211185 -
211186 -     Since we are running in a DOS virtual machine, there are
211187 -     limitations to MS-DOS applications.  If you require DPMI memory
211188 -     and require more than 600K to be available to run MS-DOS
211189 -     applications, there is some hardware this application will not
211190 -     have enough conventional memory to run. ref DRT 1 FQ5G
211191 -
211192 -
211193 -  ..
211194 - Joe says solution is still pending, noting.....
211195 -
211196 -     I have not discovered a way to alter this behavior.
211197 -     Microsoft attempts to retain backward compatiblity as practically
211198 -     possible but there are limits. I believe we have discovered one.
211199 -     Also, keep in mind that in the NT world we do not guarantee
211200 -     compatibility with MS-DOS applications.  In future operating
211201 -     systesm, there may be even less memory available to an application
211202 -     running in a NTVDM. ref DRT 1 00GP
211203 -
211204 -         [On 010314 ask Joe about follow up. ref SDS 42 5E5M
211205 -
211206 -
211207 -
211208 -
211209 -
211210 -
211211 -
211212 -
211213 -
211214 -