Mail Archives: djgpp/2004/02/19/01:40:23
> From: "Roger S Gay" <roger DOT gay AT shaw DOT ca>
> Newsgroups: comp.os.msdos.djgpp
> Date: Thu, 19 Feb 2004 02:45:48 GMT
>
> In W2K, a MSDOS box is implemented as the program CMD.EXE.
Close, but not entirely true. On the NT family of Windows (NT, W2K
and Windows XP), the DOS box is implemented as NTVDM, the NT Virtual
DOS Machine, which starts cmd.exe as the shell.
> While running
> this program one may issue "SET" which lists the environment variables and
> their settings, and which shows me
>
> ComSpec=C:\WINDOWS\system32\cmd.exe
>
> however a dump of the environ variable from a running C program shows
>
> COMSPEC=C:\WINDOWS\SYSTEM32\COMMAND.COM
>
> COMSPEC is listed first with the remaining variables in two
> alphabetically ordered lists, including those which should
> precede it. All variable names are in uppercase, not the mixed case
> shown by SET. A GETENV("ComSpec") call returns a null pointer.
Correct. This is MS Big Brother deciding for you what you want.
Their logic is that a DOS program that runs on Windows expects a
DOS-like shell and DOS-like all-caps environment variables. So when a
DOS program is invoked, Windows modifies COMSPEC to point to
COMMAND.COM, upcases all the other environment variables, and stuffs
all that down your program's throat.
> Now, I am a very occasional user of system(...) but MAKE calls it
> frequently on my behalf, and of course COMMAND.COM gets invoked.
Not true: the DJGPP port of Make will only invoke the system shell,
be it COMMAND.COM or CMD.EXE, only when it cannot emulate their
functionality. In practice, that means the shell is invoked to run
batch files and commands that are built into the shell that don't
have a .exe file on PATH with the same name. For example, if you
invoke DIR and you have GNU Fileutils installed which bring you
dir.exe, Make will invoke dir.exe, not the shell's built-in.
In general, Make refrains from calling the system shell as much as it
can, precisely because of the kind of mess like the one you face. As
a bonus, emulation of shell features like redirection and pipes gives
us features like forward slashes in shell commands and better quoting
support that the DOS/Windows shells don't have.
> Under W2K COMMAND.COM is somewhat of a second class citizen. In particular
> the PATH is not set from W2K's list of settings, but is set instead
> from AUTOEXEC.NT.
Are you sure? I just checked this on the nearest XP box, and I see
different results: the value of PATH passed to DJGPP programs is the
same as I see in CMD.EXE, but with names of all directories converted
to their 8+3 short aliases. I don't have autoexec.nt on that machine,
so perhaps if you remove or rename yours, you will get around this
misfeature. Or maybe this is something they've improved on XP, I
don't know.
> System() is documented as being able to determine that the command given
> will invoke a .BAT script. CMD.EXE prefers a .CMD suffix. Is system()
> sensitive to this?
`system' doesn't know about the .cmd extensions, it only knows about
.bat and .btm. If you must run the batch file via cmd.exe (i.e. if
you are certain that COMMAND.COM will not be able to run it), you
will have to either set SHELL (or MAKESHELL, if this is for Make
alone), or invoke cmd.exe explicitly, like this:
cmd.exe /c foo.cmd
If COMMAND.COM can run that batch file, I suggest to rename it to a
.bat extension and be done.
> Could it or should it be made so?
It could, but given the mess whose iceberg's tip you've just described,
I'm not sure it should.
> Is it possible that the install instructions, particularly those on the
> zip-picker page could emphasize the importance of setting up a correct path
> in AUTOEXEC.NT
I believe this is already mentioned somewhere.
> and the desirability of setting the SHELL environment variable
> if the user has specified W2K (or XP) as his OS.
I'm not sure we should tell users about this. Please try the
suggestions above and see if there's an easier way out.
- Raw text -