From:	jont AT harlequin DOT co DOT uk (Jon Thackray)
Subject:	Re: Sorting environment
10 Apr 1997 20:18:57 -0700 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<22801.9704101628.cygnus.gnu-win32@dedekind.cam.harlequin.co.uk>
References:	<24837 DOT 9704091211 AT dedekind DOT cam DOT harlequin DOT co DOT uk>
	<334BEE15 DOT 170D AT netcom DOT com>
	<20894 DOT 9704101126 AT dedekind DOT cam DOT harlequin DOT co DOT uk>
	<334D1255 DOT 7FFA AT netcom DOT com>
Original-To:	Jim Balter <jqb AT netcom DOT com>
Original-Cc:	Jon Thackray <jont AT harlequin DOT co DOT uk>, gnu-win32 AT cygnus DOT com
In-Reply-To:	<334D1255.7FFA@netcom.com>
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

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
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -