Subject: Re: Sorting environment
From: [email-masked] (Ken Estes)

11 Apr 1997 19:42:06 -0700
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Original-To: [email-masked], [email-masked]
In-reply-to: 
	<[email-masked]>
	(message from Stephan Mueller on Fri, 11 Apr 1997 12: 30:23 -0700)
Original-Sender: [email-masked]

 Stephan Mueller <[email-masked]> wrote:

>> Sounds like a bug in whatever implementation of _putenv() you are using.
>> I just typed 'set' on my Windows95 machine, in a DOS box, and the
>> entries listed look something like:
	winbootdir
	COMSPEC
	PATH
	PROMPT
	CTOOLS_PRJ
	DIRCMD
	...
	BLASTER
	TERM
	CMDLINE

>> It is conceivable that command.com, in its wackiness is reordering them
>> just to spite me, but I doubt it.  Parenthetical comment aside, I see no
>> evidence that the environment is guaranteed to be sorted.  The
>> parenthetical comment appears to be wrong.

Are you speaking for yourself or MS (when you write from your MS
account it appears as if you are offering official commentary on the
documentation)? Just because your simple experiment did not uncover
the problem does not mean that the documentation is wrong.  You have
performed NONE of the steps that I have outlined to trigger this
problem.

I am using WinNT and I am launching my programs from other programs
not command.com (which may indeed reorder its envrionment before
spawning processes).  It is well known that the environment handling
in NT is very different from Win95.  I try to keep my code portable to
both OS so I need to work in the intersection of these
constraints. Even if this is not a problem for 95 it is still a
problem for NT and must be solved in Cygwin32.

The version of _putenv() that I use comes from the MS development
studio for C/C++ so any bugs there in are still part of the standard
NT envrionment.

All documentaion I have seen requires that NT environment be sorted
(more then just one parenthetical comment), thus it is a constraint of
the Win32 API which intends to be independent of 95/NT and is the
target of the Cygwin32 effort. I have personally verified this bug
under the conditions I have explained.

Ken Estes

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".