MS-DOS environment variables and WinXP

[Trifle Menot]

To run my DOS programs on WinXP, I needed to set environment variables
from a DOS batch file. Problem was, they didn't stick. As soon as the
batch file ended, all the environment variables reverted to what they
were before running the batch file.

If command.com was forking another copy of itself to run the batch file,
that would explain why my changes were not sticking.

After searching but finding no advice, I was frustrated enough to hack
around just to see what I could break. I noticed in the MS-DOS shortcut
properties Program tab, Cmd line box:

F:\WINDOWS\system32\command.com

and I wondered what would happen if I changed it from \command.com to
\cmd.exe. Maybe XP would crash, burn, and explode.

But to my surprise, that was the solution. Now, when I set environment
variables from a DOS batch file, the changes remain after the batch file
ends and the command prompt returns.

Seem counterintuitive to call \cmd.exe from an MS-DOS shortcut, but it
still behaves like an MS-DOS shortcut, because config.nt and autoexec.nt
are processed, as when calling \command.com (verified by testing).

[A***@NOT.AT.Arargh.com]

On Mon, 29 Aug 2011 08:28:40 +0000, Trifle Menot
<***@beewyz.com> wrote:

I have/had that same problem. Locate a copy of "setx.exe". It's on
the nt4 resource disk or you can download a copy from microsoft. go
to the download area and search for setx.

Post by Trifle Menot
To run my DOS programs on WinXP, I needed to set environment variables
from a DOS batch file. Problem was, they didn't stick. As soon as the
batch file ended, all the environment variables reverted to what they
were before running the batch file.
If command.com was forking another copy of itself to run the batch file,
that would explain why my changes were not sticking.
After searching but finding no advice, I was frustrated enough to hack
around just to see what I could break. I noticed in the MS-DOS shortcut
F:\WINDOWS\system32\command.com
and I wondered what would happen if I changed it from \command.com to
\cmd.exe. Maybe XP would crash, burn, and explode.
But to my surprise, that was the solution. Now, when I set environment
variables from a DOS batch file, the changes remain after the batch file
ends and the command prompt returns.
Seem counterintuitive to call \cmd.exe from an MS-DOS shortcut, but it
still behaves like an MS-DOS shortcut, because config.nt and autoexec.nt
are processed, as when calling \command.com (verified by testing).

[R.Wieser]

Hello Trifle

Post by Trifle Menot
If command.com was forking another copy of itself to run the batch file,
that would explain why my changes were not sticking.

Under XP the COMMAND.COM program is just another app, and all environment
settings (as shown with "set | more") are copied from the OS.

To have a "sticky" set of settings I simply use COMMAND.COMs "/k" switch,
followed by the full path & filename of the batch-file which does additional
settings. Works quite well.

Another trick might be to place the extra environment-variables into the
registry under the hive "HKCU\volatile environment". This is for the
current session only (rebooting means you have to re-apply the changes).

If you want to have a more permanent set of environment variables you could
place them into the "HKCU\environment" subtree.

Hope that helps.
Rudy Wieser


-- origional message

Post by Trifle Menot
To run my DOS programs on WinXP, I needed to set environment variables
from a DOS batch file. Problem was, they didn't stick. As soon as the
batch file ended, all the environment variables reverted to what they
were before running the batch file.
If command.com was forking another copy of itself to run the batch file,
that would explain why my changes were not sticking.
After searching but finding no advice, I was frustrated enough to hack
around just to see what I could break. I noticed in the MS-DOS shortcut
F:\WINDOWS\system32\command.com
and I wondered what would happen if I changed it from \command.com to
\cmd.exe. Maybe XP would crash, burn, and explode.
But to my surprise, that was the solution. Now, when I set environment
variables from a DOS batch file, the changes remain after the batch file
ends and the command prompt returns.
Seem counterintuitive to call \cmd.exe from an MS-DOS shortcut, but it
still behaves like an MS-DOS shortcut, because config.nt and autoexec.nt
are processed, as when calling \command.com (verified by testing).

[Trifle Menot]

Post by R.Wieser
To have a "sticky" set of settings I simply use COMMAND.COMs "/k" switch,
followed by the full path & filename of the batch-file which does additional
settings. Works quite well.
Yes, that is strange behaivor. While this is not a solution, you could
prefix the command line to run the batch with COMMAND.COM/K. Unfortunately,
the side effect is there will be an unnecessary command processor instance
in memory each time this is repeated. Another annoying aspect to using
command.com instead of cmd.exe is there is no command history. DOSKEY does
not work in command.com on XP (most likely same for other NT based systems).
In fact command.com is a stub that calls cmd.exe for all the work.
As you have discovered, using cmd.exe is the best solution.

On XP, using \command.com as the MS-DOS command prompt shell, seems to
have no advantage.

\cmd.exe can be the command prompt shell, even with an MS-DOS shortcut
having pif settings for DPMI/EMS/XMS memory, etc.

\cmd.exe seems to start DOS programs just as well as \command.com, and
retains changes to environment variables until the command prompt window
is closed.

That's what I was looking for.

[R.Wieser]

Hello Trifle,

Post by Trifle Menot

Another annoying aspect to using command.com
instead of cmd.exe is there is no command history.

Which, depending on your POV, could be a good thing: in CMD.EXE you can't
replace it (I tried) ...

And yes, I abhor CMD.EXEes command-history as it behaves inconsistently :
sometimes (seemingly random) the up-arrow key will *not* land you on the
previous command *executed* (but somewhere much further up the list. Very
funny if you have a "del <something>" in there :-( ).

Post by Trifle Menot
That's what I was looking for.

Well, than the problem is solved. :-)

Regards
Rudy Wieser


-- Origional message

Post by Trifle Menot

To have a "sticky" set of settings I simply use COMMAND.COMs "/k" switch,
followed by the full path & filename of the batch-file which does additional
settings. Works quite well.
Yes, that is strange behaivor. While this is not a solution, you could
prefix the command line to run the batch with COMMAND.COM/K.

Unfortunately,

Post by Trifle Menot

the side effect is there will be an unnecessary command processor instance
in memory each time this is repeated. Another annoying aspect to using
command.com instead of cmd.exe is there is no command history. DOSKEY does
not work in command.com on XP (most likely same for other NT based systems).
In fact command.com is a stub that calls cmd.exe for all the work.
As you have discovered, using cmd.exe is the best solution.

On XP, using \command.com as the MS-DOS command prompt shell, seems to
have no advantage.
\cmd.exe can be the command prompt shell, even with an MS-DOS shortcut
having pif settings for DPMI/EMS/XMS memory, etc.
\cmd.exe seems to start DOS programs just as well as \command.com, and
retains changes to environment variables until the command prompt window
is closed.
That's what I was looking for.

[Howard Schwartz]

Post by Trifle Menot
If command.com was forking another copy of itself to run the batch
file, that would explain why my changes were not sticking.

A way out of this extra instance, is to place your presistent variables,
or settings in the autoexec.nt file that is read before starting any
command.com session. The variables are read in, without launching
another instance of command.com, and the variables are only available to
your dos box sessions: You need not make them permanent parts of the
windows environment.

If have even taken to putting if and call statements in autoexec.bat, so
I can have different command.com environments by creating little file or
using setx in advance.

Command.com does have some advantages over cmd.exe. It seems capable of
running more old dos programs, especially network or internet ones.

And one can probably get doskey to work with command.com, by loading a
real copy of doskey into autoexec.nt