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).
ArarghMai...@not.at.arargh.com
<trifl...@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.
--
ArarghMail107 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
R.Wieser
> 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
Trifle Menot <trifl...@beewyz.com> schreef in berichtnieuws
7fgm571sbjpevbadd...@4ax.com...
Trifle Menot
wrote:
>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.
In another group, it was said:
>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).
and:
>In fact command.com is a stub that calls cmd.exe for all the work.
thus:
>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.
--
Free web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
R.Wieser
> > 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 :-( ).
> That's what I was looking for.
Well, than the problem is solved. :-)
Regards
Rudy Wieser
-- Origional message
Trifle Menot <trifl...@beewyz.com> schreef in berichtnieuws
1vm1671909cdlo145...@4ax.com...
Howard Schwartz
news:4e60989b$0$2485$e4fe...@news2.news.xs4all.nl:
>> If command.com was forking another copy of itself to run the batch
>> file, that would explain why my changes were not sticking.
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