What does the final setting of a Registry value?

[Felecha]

I have used regedit many times, I know how to write .reg files and run them. If I run one, and look inside with the Regedit tool, I can see it shows right there, immediately.

For this one I want 3 little reg files to switch a handful of Environment Variables, i have 3 versions of our application that I need to test and I'm tired of going into the System Properties to edit them there. Depending on which one I want opened, the registry tells the app which version to do.

Hey! They are in the Registry and I know how to do that! So with the 3 files and 3 buttons to push on the taskbar, much quicker. And yes, I backed it all up first.

But the application does not seem to pick up on the change right away. Even opening a command prompt (this is Windows XP) and calling "set", the value has not "updated" to the new one I just set. This really startled me. Playing around with things, I tried opening the System Properties /Environment Variables window and just clicking OK without any changes. That does it. So there is something in there that makes the change available to new processes opening, that just running the reg file does not.

What can I add to a script or reg file to make it kick in?

 

[Nothinman]

Environment variables are special, when you set them via the System Properties it does some extra magic to make them take affect. You would need to find out what function that is and call it via VBS or a custom program after changing your variables.

 

[Smilin]

ok so what you are after is a changing set of environment variables right?
You are leveraging the registry to accomplish this but not so much interested in what's actually in the registry so long as the environment variables are properly set?


could be wrong here but..

The environment variables that you see in the registry are just there as a place to permanently store the variables between reboots. The session manager sets up those variables in memory each boot and they are referenced from memory, not the registry.

To get them "refreshed" from the registry you need to either restart the session manager (not really possible without a reboot) or trigger some code in the OS that causes the session manager to rebuild the environment variables from the registry. Hitting the 'OK' in system properties after adjusting the variables there probably does this.

If what you are after is just changing the environment variables, use the "Set" command via the command line. It just immediately changes the environment variables in memory and you're good to go.

edit: and when I say use "set" here I mean using the command to literally set the variables, not just view them (aka run "set" without any parameters). See "set /?" for info.

 

[Felecha]

Both of you, that's what I have been told by others here at work, who have many more years than I have.

My previous experience with writing to the Registry, including doing it in code, never ran into this. Evidently, as you are saying, the environment variables are stored in the Registry, yes, but they are actually used and referenced from whatever you are calling it, the Session Manager. I can wrap around that. Still wish I could trigger the "refresh" or update, or whatever, into the "live" OS session, from code. I've looked around some, but havent found anything much about it.

This is the kind of thing I can spend many happy hours chasing after, probably way more than I would ever save by not having to use the System Properties to do it.

🙂

 

[Smilin]

I'm not sure if we're connecting on this idea or not...answer a quick question and i"ll know: You know that the Set command is used to set environment variables and not just to view them right?


Environment variables reside in memory, unrelated at all to the registry. Environment variables have existed since DOS. Back in the DOS days they got placed in memory during boot by autexec.bat. Now they are getting set by session manager (who just happens to save them on disk in the registry hive files).

You could update it into the live session merely by updating it in the registry AND the environment variables at the same time. It could then "refresh" from the registry at it's leisure but won't really be changing anything because you've already done it.

 

[Felecha]

My fault, not enough detail from this end.

I think I'm following you OK. My actual use of it is the pertinent thing.

I do automated testing of a big GUI application. I write test scripts in SilkTest that run the application, it's fun - you tell the script what you want it to do, and it opens the application and moves the mouse and enters stuff in the text fields and clicks the buttons and all that - no one but SilkTest is making it happen. The tests include verifications of what happens.

One of the things we have to deal with is whenever we make changes in a script, we have to make sure that it also runs correctly on any earlier versions, and that's always an adventure. The thing is that there are certain things inside the application that are controlled by environment variables - Windows environment variables taht are created by the installer, and it's the responsibility of the user to know that if he needs to, and if he makes certain changes he has to edit them. Using the System Properties tool, that works of course. Different versions do not run correctly on other versions' environment variables, which are mostly paths to where the app expects to find certain files.

So as a tester, I sometimes end up with having to run my tests against each of 4 different versions, each of which has several variables to change. After a long time of saying "OK, finished running that test against version 12.5, let's switch to version 15.0 and run it." Then 15.0.1 and then 15.0.2. Not a killer, but I always like to find little convenience tricks, and I'm a software engineer and I'm supposed to be smart enough to do things like that.

So in this case a reg file seemed to be the thing to do. At my last job the app we built used the Registry to store things, but they werent environment variables. Back then I did the trick and it worked fine. I forgot about it till now and when I said "Hey, let's do it here!" I was surprised that simply running the reg files I wrote (they were correct) did not make the environment variables immediately "available".

I understand the set command, and at time use it here to set the environment in a DOS window, but in this case I am not working in a DOS window, I want to set the variables and then have them available to the processes that run my app and SilkTest. That is where I am finding the stone wall.

So what was said above, about being able to do it if I knew how to get at the underlying session manager thingie, is probably the only hope, and like I said it's not crucial, just very very interesting.

Did that clarify?

Thanks again

F

 

[tyanni]

so why not write a script that uses set?

 

[Felecha]

because that will set for the process running the script. My test process and the app process would not know about it

 

[Felecha]

Well, nothinman was on the track. I did a little more detailed searching for "set" and found that the XP Resource Kit has setx.exe, that does what I want!

 

[bsobel]

Originally posted by: Felecha
because that will set for the process running the script. My test process and the app process would not know about it

:roll: You call set in your script and then launch your test process. That process will inherit the environment that you setup. Your jumping thru hoops to do something that is already completely supported and has worked since basically DOS 1.0.

 

[Felecha]

Do you mean to launch the test process itself from the script? Yes, I see that would work. But the app getting tested gets called from inside the testcase scripts in the SilkTest testplan file, and the SilkTest scripts call for actions from other executables.

What I'm looking for is setting the environment, then working for an hour or so using the SilkTest IDE to run the SilkTest scripts, which it does by calling to its SilkTest Agent and passing it the script, then the Agent calls the application, which opens its window, and the Agent drives it through the testcase, and the app itself calls a number of underlying separate standalone exe's, some windowed, some not. The environment for all the related pieces of our product will expect to find the same values set in my kickoff "set" script and run on them.

Then I would close SilkTest, reset the environment, and go back to running SilkTest scripts from the IDE.

I will try that on Tuesday and see if the inheritance of the environment cascades all the way out to all involved executables.