Environment variables defined using My Computer Properties

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

I have seen this weird behavior with Windows XP

using system properties (advanced tab) define following environment
variables in this order:

Name Value
==========
C CCC
B %C%\BBB
A %B%\AAA

Now when you open command window and run set, you would see these variables
defined as:

A %B%\AAA
B CCC\BBB
C CCC

What is interesting is that variable B expands to include definition
variable C, but for some reason variable A does not expand to include
definition of B.

These cases are very simplified examples. I encountered this while I was
defining some directory locations using environment variables. If A, B and C
are all directory components, then following commands would work properly:

cd %B%
cd %C%

but follwoing command would fail:

cd %A%

Another interesting observation is that: if you look at definition of these
variables using "Advanced" tab of system properties, you would see that all
of them expand properly.

Does anybody has any idea what's happening?

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

From: "Yogi Watcher" <YogiWatcher@discussions.microsoft.com>

| I have seen this weird behavior with Windows XP
|
| using system properties (advanced tab) define following environment
| variables in this order:
|
| Name Value
| ==========
| C CCC
| B %C%\BBB
| A %B%\AAA
|
| Now when you open command window and run set, you would see these variables
| defined as:
|
| A %B%\AAA
| B CCC\BBB
| C CCC
|
| What is interesting is that variable B expands to include definition
| variable C, but for some reason variable A does not expand to include
| definition of B.
|
| These cases are very simplified examples. I encountered this while I was
| defining some directory locations using environment variables. If A, B and C
| are all directory components, then following commands would work properly:
|
| cd %B%
| cd %C%
|
| but follwoing command would fail:
|
| cd %A%
|
| Another interesting observation is that: if you look at definition of these
| variables using "Advanced" tab of system properties, you would see that all
| of them expand properly.
|
| Does anybody has any idea what's happening?

It is the same in Win2K.

I'd have to say it has to do with a secondary dependancy and the order set in the Registry
since the Registry is sorted alphebetically and A is set before B being which is set before
C is being set.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

When I changed the A variable to Z it works as expected

B=CCC\BBB
C=CCC
Z=CCC\BBB\AAA

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

Is there any way around this....other than renaming variables to be in
alphabetical order?

"David H. Lipman" wrote:

> From: "Yogi Watcher" <YogiWatcher@discussions.microsoft.com>
>
> | I have seen this weird behavior with Windows XP
> |
> | using system properties (advanced tab) define following environment
> | variables in this order:
> |
> | Name Value
> | ==========
> | C CCC
> | B %C%\BBB
> | A %B%\AAA
> |
> | Now when you open command window and run set, you would see these variables
> | defined as:
> |
> | A %B%\AAA
> | B CCC\BBB
> | C CCC
> |
> | What is interesting is that variable B expands to include definition
> | variable C, but for some reason variable A does not expand to include
> | definition of B.
> |
> | These cases are very simplified examples. I encountered this while I was
> | defining some directory locations using environment variables. If A, B and C
> | are all directory components, then following commands would work properly:
> |
> | cd %B%
> | cd %C%
> |
> | but follwoing command would fail:
> |
> | cd %A%
> |
> | Another interesting observation is that: if you look at definition of these
> | variables using "Advanced" tab of system properties, you would see that all
> | of them expand properly.
> |
> | Does anybody has any idea what's happening?
>
> It is the same in Win2K.
>
> I'd have to say it has to do with a secondary dependancy and the order set in the Registry
> since the Registry is sorted alphebetically and A is set before B being which is set before
> C is being set.
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
>
> When I changed the A variable to Z it works as expected
>
> B=CCC\BBB
> C=CCC
> Z=CCC\BBB\AAA
>
> --
> Dave
> http://www.claymania.com/removal-trojan-adware.html
> http://www.ik-cs.com/got-a-virus.htm
>
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

From: "Yogi Watcher" <YogiWatcher@discussions.microsoft.com>

| Is there any way around this....other than renaming variables to be in
| alphabetical order?
|

None that I can see.
{ I have to say it was a phun experiment ! ;-) }

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

The registry is not in alphabetical order. Regedit sorts it before showing (which is why it's slow). Keys and values are in the order added (which is why file associations can act wierd for those without an open or default if you remove and readd in wrong order).



--
--------------------------------------------------------------------------------------------------
http://webdiary.smh.com.au/archives/_comment/001075.html
=================================================
"Yogi Watcher" <YogiWatcher@discussions.microsoft.com> wrote in message news:E2B71FD9-6582-4312-A383-BAC284C12CDD@microsoft.com...
> Is there any way around this....other than renaming variables to be in
> alphabetical order?
>
> "David H. Lipman" wrote:
>
>> From: "Yogi Watcher" <YogiWatcher@discussions.microsoft.com>
>>
>> | I have seen this weird behavior with Windows XP
>> |
>> | using system properties (advanced tab) define following environment
>> | variables in this order:
>> |
>> | Name Value
>> | ==========
>> | C CCC
>> | B %C%\BBB
>> | A %B%\AAA
>> |
>> | Now when you open command window and run set, you would see these variables
>> | defined as:
>> |
>> | A %B%\AAA
>> | B CCC\BBB
>> | C CCC
>> |
>> | What is interesting is that variable B expands to include definition
>> | variable C, but for some reason variable A does not expand to include
>> | definition of B.
>> |
>> | These cases are very simplified examples. I encountered this while I was
>> | defining some directory locations using environment variables. If A, B and C
>> | are all directory components, then following commands would work properly:
>> |
>> | cd %B%
>> | cd %C%
>> |
>> | but follwoing command would fail:
>> |
>> | cd %A%
>> |
>> | Another interesting observation is that: if you look at definition of these
>> | variables using "Advanced" tab of system properties, you would see that all
>> | of them expand properly.
>> |
>> | Does anybody has any idea what's happening?
>>
>> It is the same in Win2K.
>>
>> I'd have to say it has to do with a secondary dependancy and the order set in the Registry
>> since the Registry is sorted alphebetically and A is set before B being which is set before
>> C is being set.
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
>>
>> When I changed the A variable to Z it works as expected
>>
>> B=CCC\BBB
>> C=CCC
>> Z=CCC\BBB\AAA
>>
>> --
>> Dave
>> http://www.claymania.com/removal-trojan-adware.html
>> http://www.ik-cs.com/got-a-virus.htm
>>
>>
>>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

From: "David Candy" <.>

| The registry is not in alphabetical order. Regedit sorts it before showing (which is why
| it's slow). Keys and values are in the order added (which is why file associations can act
| wierd for those without an open or default if you remove and readd in wrong order).
|
| --
| ------------------------------------------------------------------------------------------
| http://webdiary.smh.com.au/archives/_comment/001075.html
| =================================================

Dave:

The fact that when I changed the variable name "A" to "Z" the variable was et correctly is
indicative that at least it was processed in alphabetical order.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

I doubt the environment is in the registry (of course some of it is stored there but each program gets a copy of the environment and it's a memory thing). I suspect it IS stored alphabetically in memory (I went looking for a debugger to confirm but it's not installed).

--
--------------------------------------------------------------------------------------------------
http://webdiary.smh.com.au/archives/_comment/001075.html
=================================================
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message news:uHK%23stcrFHA.3096@TK2MSFTNGP15.phx.gbl...
> From: "David Candy" <.>
>
> | The registry is not in alphabetical order. Regedit sorts it before showing (which is why
> | it's slow). Keys and values are in the order added (which is why file associations can act
> | wierd for those without an open or default if you remove and readd in wrong order).
> |
> | --
> | ------------------------------------------------------------------------------------------
> | http://webdiary.smh.com.au/archives/_comment/001075.html
> | =================================================
>
> Dave:
>
> The fact that when I changed the variable name "A" to "Z" the variable was et correctly is
> indicative that at least it was processed in alphabetical order.
>
> --
> Dave
> http://www.claymania.com/removal-trojan-adware.html
> http://www.ik-cs.com/got-a-virus.htm
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

From: "David Candy" <.>

| I doubt the environment is in the registry (of course some of it is stored there but each
| program gets a copy of the environment and it's a memory thing). I suspect it IS stored
| alphabetically in memory (I went looking for a debugger to confirm but it's not
| installed).
|
| --


It's in the Registry...
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

No it's not. It is in memory. You are confusing storage with the environment. And the registry is not the only place the the evironment is stored, only part of it is stored there.

When you logon your environment is made from the the registry and autoexec.bat (and autoexec.nt/config.nt for 16 bit programs). Each program that is started gets it's own copy of the environment FROM the program that started it, usually explorer but may not be.

This is what CreateProcess (the thing that executes programs on windows) has to say

lpEnvironment
[in] Pointer to an environment block for the new process. If this parameter is NULL, the new process uses the environment of the calling process.
An environment block consists of a null-terminated block of null-terminated strings. Each string is in the form:

name=value Because the equal sign is used as a separator, it must not be used in the name of an environment variable.

An environment block can contain either Unicode or ANSI characters. If the environment block pointed to by lpEnvironment contains Unicode characters, be sure that dwCreationFlags includes CREATE_UNICODE_ENVIRONMENT.

Note that an ANSI environment block is terminated by two zero bytes: one for the last string, one more to terminate the block. A Unicode environment block is terminated by four zero bytes: two for the last string, two more to terminate the block.


Here is the environment lifted from a memory block (I got bored reformatting it - but here's enough to show that it is NOT in alphabetical order, though it appears to be in alpha order by where it came from).

COMSPEC=C:\WINDOWS\SYSTEM32\COMMAND.COM
ALLUSERSPROFILE=C:\DOCUME~1\ALLUSE~1
APPDATA=C:\DOCUME~1\DAVIDC~1\APPLIC~1
COMMONPROGRAMFILES=C:\PROGRA~1\COMMON~1
COMPUTERNAME=SERENITY
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\David Candy
LOGONSERVER=\\SERENITY
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
PATH=C:\PROGRA~1\WINDOW~4\Tools\;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\PROGRA~1\SUPPOR~1\;c:\msbob;C:\MSBOB\;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 7, GenuineIntel.PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0207
PROGRAMFILES=C:\PROGRA~1
PROMPT=$P$G
SESSIONNAME=Console.SYSTEM
DRIVE=C:
SYSTEMROOT=C:\windows
TEMP=C:\windows\T

--
--------------------------------------------------------------------------------------------------
http://webdiary.smh.com.au/archives/_comment/001075.html
=================================================
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message news:eQjYTjjrFHA.464@TK2MSFTNGP15.phx.gbl...
> From: "David Candy" <.>
>
> | I doubt the environment is in the registry (of course some of it is stored there but each
> | program gets a copy of the environment and it's a memory thing). I suspect it IS stored
> | alphabetically in memory (I went looking for a debugger to confirm but it's not
> | installed).
> |
> | --
>
>
> It's in the Registry...
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
>
> --
> Dave
> http://www.claymania.com/removal-trojan-adware.html
> http://www.ik-cs.com/got-a-virus.htm
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

From: "David Candy" <.>

| No it's not. It is in memory. You are confusing storage with the environment. And the
| registry is not the only place the the evironment is stored, only part of it is stored
| there.
|
| When you logon your environment is made from the the registry and autoexec.bat (and
| autoexec.nt/config.nt for 16 bit programs). Each program that is started gets it's own
| copy of the environment FROM the program that started it, usually explorer but may not be.
|
| This is what CreateProcess (the thing that executes programs on windows) has to say
|
| lpEnvironment
| [in] Pointer to an environment block for the new process. If this parameter is NULL, the
| new process uses the environment of the calling process. An environment block consists of
| a null-terminated block of null-terminated strings. Each string is in the form:
|
| name=value Because the equal sign is used as a separator, it must not be used in the name
| of an environment variable.
|
| An environment block can contain either Unicode or ANSI characters. If the environment
| block pointed to by lpEnvironment contains Unicode characters, be sure that
| dwCreationFlags includes CREATE_UNICODE_ENVIRONMENT.
|
| Note that an ANSI environment block is terminated by two zero bytes: one for the last
string,
| one more to terminate the block. A Unicode environment block is terminated by four zero
bytes:
| two for the last string, two more to terminate the block.
|
| Here is the environment lifted from a memory block (I got bored reformatting it - but
| here's enough to show that it is NOT in alphabetical order, though it appears to be in
| alpha order by where it came from).
|
| COMSPEC=C:\WINDOWS\SYSTEM32\COMMAND.COM
| ALLUSERSPROFILE=C:\DOCUME~1\ALLUSE~1
| APPDATA=C:\DOCUME~1\DAVIDC~1\APPLIC~1
| COMMONPROGRAMFILES=C:\PROGRA~1\COMMON~1
| COMPUTERNAME=SERENITY
| FP_NO_HOST_CHECK=NO
| HOMEDRIVE=C:
| HOMEPATH=\Documents and Settings\David Candy
| LOGONSERVER=\\SERENITY
| NUMBER_OF_PROCESSORS=1
| OS=Windows_NT
| PATH=C:\PROGRA~1\WINDOW~4\Tools\;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C
| :\PROGRA~1\SUPPOR~1\;c:\msbob;C:\MSBOB\;
| PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86
| PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 7, GenuineIntel.PROCESSOR_LEVEL=15
| PROCESSOR_REVISION=0207
| PROGRAMFILES=C:\PROGRA~1
| PROMPT=$P$G
| SESSIONNAME=Console.SYSTEM
| DRIVE=C:
| SYSTEMROOT=C:\windows
| TEMP=C:\windows\T
|
| --
| ------------------------------------------------------------------------------------------
| http://webdiary.smh.com.au/archives/_comment/001075.html
| =================================================
| "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:eQjYTjjrFHA.464@TK2MSFTNGP15.phx.gbl...
>> From: "David Candy" <.>
>>
|>> I doubt the environment is in the registry (of course some of it is stored there but
|>> each program gets a copy of the environment and it's a memory thing). I suspect it IS
|>> stored alphabetically in memory (I went looking for a debugger to confirm but it's
|>> not installed).
|>>
|>> --


Processing and displaying are two different things.
We haven't even gotten into the Environmental variables that are usable, not in the
Registry, and are not displayed.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

That's a Dos block. The docs say they MUST be sorted in case insensitive order (despite the fact I just proved they aren't in a dos environment).

But remember that each program has it's own environment.

--
--------------------------------------------------------------------------------------------------
http://webdiary.smh.com.au/archives/_comment/001075.html
=================================================
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message news:eQjYTjjrFHA.464@TK2MSFTNGP15.phx.gbl...
> From: "David Candy" <.>
>
> | I doubt the environment is in the registry (of course some of it is stored there but each
> | program gets a copy of the environment and it's a memory thing). I suspect it IS stored
> | alphabetically in memory (I went looking for a debugger to confirm but it's not
> | installed).
> |
> | --
>
>
> It's in the Registry...
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
>
> --
> Dave
> http://www.claymania.com/removal-trojan-adware.html
> http://www.ik-cs.com/got-a-virus.htm
>
>