DOS memory - differences between XPpro and XPpro OEM

[ncopernic]

Hello,

Here is a problem that I try to solve for a long time without success.
I need to run a dos software. A critical aspect is the max size for
executable program under CMD.exe.
I know how to optimize the config.nt and autoecex.nt to maximize this.

I runs well under Win XPpro "standard, bought from the shop"

Now,under Win XPpro OEM, this memory seems to be managed differently and is
lessened.

For example, without optimization of the .nt files:
XPpro non-OEM : 625888 octets
XPpro non-OEM : 590'800 octets

The .nt files are the same. This difference stays even after optimization of
those files.
I tried to run the non-OEM CMD.EXE on the OEM windows. Same problem.
Since we use HP computers that come standard with WinXP OEM, buying XP again
for every computer is not an option.

Has anyone a hint about that problem ?

Thanks

Nick

 

[Alex Nichol]

Here is a problem that I try to solve for a long time without success.
I need to run a dos software. A critical aspect is the max size for
executable program under CMD.exe.
I know how to optimize the config.nt and autoecex.nt to maximize this.

I runs well under Win XPpro "standard, bought from the shop"

Now,under Win XPpro OEM, this memory seems to be managed differently and is
lessened.

For example, without optimization of the .nt files:
XPpro non-OEM : 625888 octets
XPpro non-OEM : 590'800 octets

The .nt files are the same. This difference stays even after optimization of
those files.
I tried to run the non-OEM CMD.EXE on the OEM windows.

If the ,nt files are truely the same, it seems likely that one of your
instances has a different version of one of the other files loaded from
autoexec.nt - or that you have in fact got an extra one loading that you
thought you had eliminated. But I suspect a very small difference,
probably in the EMM line of config.nt, see below

Cross check with this recipe for best conventional memory:

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)

and in autoexec.nt have

REM Install DPMI support
lh %SystemRoot%\system32\dosx

with other earlier lh lines REM ed out, and then any SET or PATH lines
that may already be present at the end.

This should give about 612K for a program, run from a shortcut made to
its .exe file. R-click the shortcut, 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

 

[ncopernic]

Hello,

Thanks for taking time to read my post.

I'm afraid that both machines have EXACTELY the same config.nt and
autoexec.nt.

Config.nt has the following lines apart from the standard REM first lines
dos=high, umb
device=%SystemRoot%\system32\himem.sys
files=90
I tried to add the "EMM = B=4000 RAM" line to it. It doesn't increase the
max size of executable program (see below)

Autoexec.nt has the following non-REM lines
lh %SystemRoot%\system32\mscdexnt.exe
lh %SystemRoot%\system32\redir
lh %SystemRoot%\system32\dosx

---- I found more precisely what gives me so much trouble ----

On the OEM versions, the dosx loads only 0.1K in high memory, even with the
"lh".
If i don't load it at all, I end up with about the same conv. usable memory
as on an non-OEM system.
It seems even more trickier.

----------------------------------------------------------------

I can add that both windows are french(swiss) versions. The problem appears
on EVERY computer we have and I don't use any particular registry tips or
tricks. So I really think that this comes with standard config. It was
already like that before SP2 and win2K seems to have the same flaw, although
I have not tested as extensively.

The tested non-OEM have been tested on several brands of computers and come
from different shops. The OEM versions are all native HP preinstalled
versions.

Thanks for your help,

Nick