Whence windir?
A program I wrote retrieves the value of the "windir" environment variable
to obtain the location of Windows' SYSTEM.INI file. I noticed that when
the program ran under NT 3.51, it wasn't finding the windir environment
variable, even though it shows up in the listing produced by the SET
command in an NT command prompt window.
Curious, I wrote a 1-line program which just prints the value of the
windir environment variable using the getenv function, and compiled it
twice: once using MSVC 1.52 (Win16) and again under MSVC 4.0 (Win32).
The Win16 version runs fine on WFW 3.11, but can't see windir under NT.
The Win32 version displays windir under NT. Same code, different compiler.
OK, what's going on? It appeared that getenv is implemented differently
by Win16 and Win32. I examined the online help for getenv and was reminded
of another way to examine environment variables, by using the envp pointer
array as the third arg passed to main().
I modified my simple program to display the value of each environment
variable in envp's list. What do you think happened? At the end of
the Win16 list is our friend windir. When running the Win16 code under
Win32, however, the list stops at USERNAME. The Win32-compiled version
works as expected; windir is at the end of the list.
But hey, closer examination reveals other small differences between the
list of environment variables obtained from envp as displayed by the
Win16 and Win32-compiled versions of THE SAME CODE.
First, the order is slightly different. In Win32 the list starts out
address=, BLASTER=, COMPUTERNAME, and ComSpec. Win16 starts the list
COMSPEC, ADDRESS, BLASTER, COMPUTERNAME... and not only is the order
different, but Win32 shows ComSpec=D:\NT\system32\cmd.exe while Win16
shows COMSPEC=D:\NT\SYSTEM32\COMMAND.COM. Upon reflection this makes
sense, as CMD is a 32-bit command interpreter, while COMMAND.COM is
the old DOS version. So, NT uses CMD for 32-bit code and COMMAND for
16-bit code. And under NT, COMMAND doesn't have a windir environment
variable while CMD does!
What does it all mean? It means that 16-bit code can't depend on using
environment variables under NT (at least windir). Even if they exist
under CMD, and show up with the SET command, they will not necessarily
be there when your code executes under COMMAND. I confirmed this by
starting a COMMAND window via typing START COMMAND from a command prompt
window. Typing SET from the COMMAND window produces an environment
variable list without windir. Trying the same thing in a window created
from START CMD shows windir at the end of the list.
Frank Brown