After all of these years, the Win32 API still does not provide a mechanism for updating a System or User Environment Variable.
I sympathize... I re-encountered this (for the 259th time over 15 years) just today! (Worse yet, I've got to this from within a korn shell script running under KSH that comes with Windows SFU 3.5... EEeeewww!) Have a look at the only "official" statement of how to do this: KB Q104011 HOWTO: Propagate Environment Variables to the System. (You may have to go back in time with your MSDN Lib...say to the Oct 2001 edition, the last version that contains the VS6 manual set...) Basically, one could argue that the example showing how to use a WM_SETTINGCHANGE message indicates that the Win32 API does include the functionality. It's just not wrapped up as an pretty obvious-named function, like the exisiting SetEnvironmentVariable API. The example from the KB article is: SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0, (LPARAM) "Environment", SMTO_ABORTIFHUNG, 5000, &dwReturnValue); Of course, to complicate things you can't just use SetEnvironmentVariable to change the environment variable in the current process' environment block and then issue the above WM_SETTINGCHANGE. You've got to change the registry keys (cited in the KB article) first... Yuck! (I've actually had to do this in several apps... Personally, I wish SetEnvironmentVariable had an additional parameter to indicate whether or not to propogate the changed key to the registry and issue the broadcast. That'd be a LOT EASIER...) Maybe we should bug Raymond (in the Windows Shell group) about this. I'm tired of writing this crap-ass code instead of simply calling SetEnvironmentVariable. Longhorn's not entirely "feature locked-down" yet, so maybe this could be thrown in. I haven't looked at Longhorn's beta MSDN page for SetEnvironmentVariable, so you might check it out before complaining. Instead of bugging Raymond, we might get somewhere by opening a "suggestion" problem report on the new MSDN product feedback website (http://lab.msdn.microsoft.com/productfeedback/) against the Longhorn product. Are you game for this? Actually, upon checking the recent June 2005 MSDN Lib, I ran across KB 829145 PRB: System.Environment Class Does Not Have a Method to Set the Environment Variable for the Current Process. It would seem that there's a conspiracy to make it difficult to change environment variables even temporarily in the BCL! (The solution they describe is to call Win32 SetEnvironmentVariable...) This should be a second problem report. I can't believe they actually forgot this! Having to pillage and plunder in the registry and then in Windows Messages (esp. broadcast messages!) is just plain WRONG in this day and age!
Wow, Steve! You obviously had more to say on this issue than I did. I've run into the same problems as you, and although my time writing Windows software isn't quite as long as you, I've probably complained about this as many times. The good news is that the .NET Framework 2.0 takes care of this. (See http://blogs.msdn.com/brada/archive/2004/01/03/50984.aspx) I still find that it's interesting that even though updating System or User Environment is not in the Win32 API, the .NET framework 'hacks' the registry to manage this.
Thanks Jerry for the link to Brad's article. I somehow missed that post... (Odd! I read Brad's posts religiously!) I'm kinda surprised they got it into .NET 2.0, but NOT Longhorn. (Well, I guess it's time to look at the Longhorn beta MSDN webpages to be sure about that!) But this still doesn't help me with my korn shell script I've gotta kludge tomorrow. NUTS! (Just what I always wanted to do: edit the registry and issue broadcast messages from within a shell script. I think I'm going to be sick! This'll teach me to port KSH scripts from Solaris to SFU, instead of rewriting them in Perl or Python!)