Subject: Re: Sorting environment
From: [email-masked] (Jon Thackray)

10 Apr 1997 20:18:57 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Original-To: Jim Balter <[email-masked]>
Original-Cc: Jon Thackray <[email-masked]>, [email-masked]
In-Reply-To: <[email-masked]>
Original-Sender: [email-masked]

Jim Balter writes:
 > Jon Thackray wrote:
 > > 
 > > Jim Balter writes:
 > >  > Jon Thackray wrote:
 > >  > >
 > >  > > I belive it to be part of the spec of CreateProcess that the
 > >  > > environment it is passed should be sorted.
 > >  >
 > >  > The CreateProcess documentation does not require this.
 > >  > In fact, since the environment block can be in Unicode,
 > >  > the sort order isn't even defined.
 > > 
 > > Quoting from the Oct 96 MSDN docs for CreateProcess, near the end of the
 > > "Remarks" section:
 > > 
 > >   If the current directory on drive C is \MSVC\MFC, there is an
 > >   environment variable called =C: whose value is C:\MSVC\MFC. As noted in
 > >   the previous description of lpEnvironment, such current directory
 > >   information for a system's drives does not automatically propagate to a
 > >   new process when the CreateProcess function's lpEnvironment parameter is
 > >   non-NULL. An application must manually pass the current directory
 > >   information to the new process. To do so, the application must
 > >   explicitly create the =X environment variable strings, get them into
 > >   alphabetical order (because Windows NT and Windows 95 use a sorted
 > >   environment), and then put them into the environment block specified by
 > >   lpEnvironment. Typically, they will go at the front of the environment
 > >   block, due to the previously mentioned environment block sorting.
 > 
 > This parenthetical comment about what these systems "use" is not
 > part of the win32 specification.  If there really is Windows NT
 > and Windows 95 software that depends upon sorting, then that is a
 > bug.  Not that that has any bearing on the real world, where
 > practical software must accomodate MS's bugs.

Well, at the end of the day, that is what they do, and so even if the
information doesn't appear in a document called Win32 specification,
it is still effectively part of the specification. cmd in particular
does depend on that sorting and there's nothing we can do to change
that. So as you say, practical software must work around MS's bugs.
The effect of the bug is that one can end up with multiple copies of
the same environment variable, and thus attempts to clear such a
variable simply result in a previous value being revealed. A typical
code sequence that this will affect is the argument collecting code,
eg

set MYARGS= 
:startmyargs
if "%1"=="" goto endmyargs
set MYARGS=%MYARGS% %1
shift
goto startmyargs
:endmyargs

In this case, one can end up with old values of MYARGS as well as the
parameters.
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".