asked on
windows code example how to change path variable for current process
Hi all,
Basically I am looking for a code example to change the "path" for the current process (so it will find the correct DLL).
Can anyone give such a code example ?
Background for the curious people.
I am working "inside" a 32 bit program - quite an OLD program (it's a general utility which enable you to run "sub programs"). We shall call this program "EnvironmentProgram.exe".
When we are running in a 32 bit windows - everything is fine.
But when we are running in a 64 bit windows (using wow64) , it turns out that this system "fails" to load the "correct 32 bit DLL", and finds the "incorrect 64 bit DLL" - which fails to load obviously. This problem occurs because EnvironmentProgram.exe looks for DLLs according to the order in the "path". Basically, I want to remove one element from the path, so it would not fail.
Thanks
zmau
Basically I am looking for a code example to change the "path" for the current process (so it will find the correct DLL).
Can anyone give such a code example ?
Background for the curious people.
I am working "inside" a 32 bit program - quite an OLD program (it's a general utility which enable you to run "sub programs"). We shall call this program "EnvironmentProgram.exe".
When we are running in a 32 bit windows - everything is fine.
But when we are running in a 64 bit windows (using wow64) , it turns out that this system "fails" to load the "correct 32 bit DLL", and finds the "incorrect 64 bit DLL" - which fails to load obviously. This problem occurs because EnvironmentProgram.exe looks for DLLs according to the order in the "path". Basically, I want to remove one element from the path, so it would not fail.
Thanks
zmau
Windows OS* path* LoadLibrary
Last Comment
Joe Winograd
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Another option might be to copy correct the DLL to a folder earlier in the path and possibly the folder in which the executable is run from.
This is more complicated than it is.
The issue is that a 32 bit that is not using the system calls, will keep refering to paths as c:\program files or c:\program files\common on a 64 bit system..
Without a source and alterations, I think your best bet is to place the DLLs in the c:\program files\common
the DLL that it is looking for is in c:\windows\system32 which is the 64 bit version while the syswow64\ is the 32bit repository.
best tool for your situation is dependency walker
http://dependencywalker.com/
This way you can see where your application is looking for the DLL and then placing it there should resolve the issue. unless you place the DLL in the same folder where the application is installed.
Not sure %PATH% is the only issue you are running into.
Placing the files in where it would be found on a 32bit system, is likely to succeed.
The issue is that a 32 bit that is not using the system calls, will keep refering to paths as c:\program files or c:\program files\common on a 64 bit system..
Without a source and alterations, I think your best bet is to place the DLLs in the c:\program files\common
the DLL that it is looking for is in c:\windows\system32 which is the 64 bit version while the syswow64\ is the 32bit repository.
best tool for your situation is dependency walker
http://dependencywalker.com/
This way you can see where your application is looking for the DLL and then placing it there should resolve the issue. unless you place the DLL in the same folder where the application is installed.
Not sure %PATH% is the only issue you are running into.
Placing the files in where it would be found on a 32bit system, is likely to succeed.
ASKER
Thanks for the good advices.
Arnold, Lee:
Still the easiest solution would be from code - hard to explain but it is true (mainly history + customers). So, I still wonder if there is a code example for this idea ?
Thanks a lot.
Arnold, Lee:
Placing the DLL's is completely not in my hands - it not my computers, and not my DLL's - their installation programs puts them where they want :-)
Bill :Running from a batch file ? this actually can do the work, but my customers might not like it. I will check with them.
Still the easiest solution would be from code - hard to explain but it is true (mainly history + customers). So, I still wonder if there is a code example for this idea ?
Thanks a lot.
> I still wonder if there is a code example for this idea ?
It depends on what language you're coding in. I suspect that most modern Windows programming/scripting languages have the ability to read and write environment variables (and, of course, perform string operations). For example, as you requested, here's a code sample (with comments) in the AutoHotkey language (which is my go-to choice these days for programming/scripting in Windows):
AutoHotkey - Getting Started
However, as noted earlier, just about any language should be able to do it, so it all depends on your coding language of choice. Regards, Joe
It depends on what language you're coding in. I suspect that most modern Windows programming/scripting languages have the ability to read and write environment variables (and, of course, perform string operations). For example, as you requested, here's a code sample (with comments) in the AutoHotkey language (which is my go-to choice these days for programming/scripting in Windows):
ElementToRemove:="c:\whatever folder you want to remove;"
EnvGet,CurrentPath,Path ; get current Path environment var
NewPath:=StrReplace(CurrentPath,ElementToRemove) ; remove folder from Path var
EnvSet,Path,%NewPath% ; set new Path with folder removed
AutoHotkey - Getting Started
However, as noted earlier, just about any language should be able to do it, so it all depends on your coding language of choice. Regards, Joe
Can you repackage the installer?
ASKER
Arnold thanks - sorry - but the answer is no - not mine.
ASKER
Joe Winograd,
Thanks
I am not familiar with AutoHotkey - it looks like it needs an installation on the customer's computer, which is not option for me.
I would have prefer a regular C/C++ code.
Thanks
Zmau
Thanks
I am not familiar with AutoHotkey - it looks like it needs an installation on the customer's computer, which is not option for me.
I would have prefer a regular C/C++ code.
Thanks
Zmau
Not sure what language your application is written in, but many of the VB based languages use a technique like:
Environment.SetEnvironment
Here's some C++ examples...
Set local environment variables in C++ - Stack Overflow
Would need to know what language you are working in.
»bp
Environment.SetEnvironment
Here's some C++ examples...
Set local environment variables in C++ - Stack Overflow
Would need to know what language you are working in.
»bp
> it looks like it needs an installation on the customer's computer
It doesn't. Read my AutoHotkey article...look at the Compiler section. You would use the compiler to create a stand-alone executable (a .EXE file with no dependencies) that you would put on the customer's computer...same as you would do with C/C++ or any language that can compile into a stand-alone EXE. Regards, Joe
It doesn't. Read my AutoHotkey article...look at the Compiler section. You would use the compiler to create a stand-alone executable (a .EXE file with no dependencies) that you would put on the customer's computer...same as you would do with C/C++ or any language that can compile into a stand-alone EXE. Regards, Joe