When we install a 32-bit pgAdmin-III in a windows 64-bit machine, which is already having the 64-bit EnterpriseDB database installed, then EDB binary path not set to by default.
Further to my observation, below is the mechanism how the pgAdmin looks for the PPAS binary path.
A) Read the settings.ini for the entry "EnterpriseDBPath" and get the value.
B) Read the "EnterpriseDBPath" as a key in the registries. If the key is not found, then create one key and assign the value of settings.ini file.
C) If the registry is found, and still the value of "EnterpriseDBPath" is null, then we are checking the %PATH% which will be having the "pg_dump.exe" file and it's a type of "EnterpriseDB".
D) If we don't find any "pg_dump.exe" edb version, then we go for the default locations to search for the edb version.
I have verified the above A, B and C cases, and those are working fine in a 64-bit machine. But the case D is not working as expected in a 64-bit machine. Hence, would like to submit a patch for this case.
Kindly let me know your inputs on this patch.
I don't think you can do it that way - what if the directory name doesn't end in "(x86)"? You can configure Windows to use any arbitrary directory for the Program Files folders. I suspect you'll need to use a preprocessor macro to handle the 32 vs. 64 bit cases accordingly.
Sorry for the delay on this issue.
I have done some google around the same problem, and found the solution to use "programw6432" environment variable , if a 32 bit application runs in a 64 bit machine. But, this option only works on windows 7 and windows 2008 R2 onwards. And after spending some time, i have found one suitable solution for this case, which we need to read the key "ProgramFilesDir" from the registry "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion", and i have implemented this mechanism using pgRegKey.
Here i have used, "wxIsPlatform64Bit()" as an alternative to preprocessor macros.
