Thread: Patch for EDB binary path not set by default.

Patch for EDB binary path not set by default.

From

Dinesh Kumar

Date:

09 October 2013, 16:12:27

Hi Dave/Team,

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.

Thanks in advance.

Dinesh

--
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

Attachment

Fix_EnterpriseDBPath_Notset_Bydefault.patch

Re: Patch for EDB binary path not set by default.

From

Dave Page

Date:

11 October 2013, 16:35:31

On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave/Team,

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.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Patch for EDB binary path not set by default.

From

Dinesh Kumar

Date:

14 October 2013, 12:13:22

Hi Dave,

Thanks for your valuable inputs.

On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:
Hi Dave/Team,

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.

Kindly let me know your inputs on this patch.

Thanks in advance.

Regards,

Dinesh

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

Fix_EnterpriseDBPath_Notset_Bydefault-V2.patch

Re: Patch for EDB binary path not set by default.

From

Dave Page

Date:

29 October 2013, 13:07:34

Ashesh - can you review/commit this please? I'm swamped at the moment. Thanks.

On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi Dave,
>
> Thanks for your valuable inputs.
>
> On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.com> wrote:
>>>
>>> Hi Dave/Team,
>>>
>>> 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.
>
> Kindly let me know your inputs on this patch.
>
> Thanks in advance.
>
> Regards,
> Dinesh
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Patch for EDB binary path not set by default.

From

Ashesh Vashi

Date:

30 October 2013, 15:04:40

As per your comments, you first need to check - it is 64 bit windows or not, and then check it is 32 bit pgAdmin III.

Hence - the code should look like something like this:

if (::wxIsPlatform64Bit() && programFiles == programFilesX86)

{

...

pgRegKey *pgKey = pgRegKey::OpenRegKey(HKEY_LOCAL_MACHINE, wxT("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"), pgRegKey::PGREG_READ, pgRegKey::PGREG_WOW64);

...

}

On Tue, Oct 29, 2013 at 3:37 PM, Dave Page <dpage@pgadmin.org> wrote:

Ashesh - can you review/commit this please? I'm swamped at the moment. Thanks.

On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi Dave,
>
> Thanks for your valuable inputs.
>
> On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.com> wrote:
>>>
>>> Hi Dave/Team,
>>>
>>> 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.
>
> Kindly let me know your inputs on this patch.
>
> Thanks in advance.
>
> Regards,
> Dinesh
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

Re: Patch for EDB binary path not set by default.

From

Dinesh Kumar

Date:

30 October 2013, 15:46:21

Thanks Ashesh.

Let me send new patch as per the suggested changes.

Dinesh

--
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 5:34 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

As per your comments, you first need to check - it is 64 bit windows or not, and then check it is 32 bit pgAdmin III.

Hence - the code should look like something like this:
if (::wxIsPlatform64Bit() && programFiles == programFilesX86)
{
...
pgRegKey *pgKey = pgRegKey::OpenRegKey(HKEY_LOCAL_MACHINE, wxT("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"), pgRegKey::PGREG_READ, pgRegKey::PGREG_WOW64);
...
}

On Tue, Oct 29, 2013 at 3:37 PM, Dave Page <dpage@pgadmin.org> wrote:
Ashesh - can you review/commit this please? I'm swamped at the moment. Thanks.

On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi Dave,
>
> Thanks for your valuable inputs.
>
> On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.com> wrote:
>>>
>>> Hi Dave/Team,
>>>
>>> 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.
>
> Kindly let me know your inputs on this patch.
>
> Thanks in advance.
>
> Regards,
> Dinesh
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

Re: Patch for EDB binary path not set by default.

From

Dinesh Kumar

Date:

11 November 2013, 09:57:52

Hi Ashesh,

Sorry for the huge delay on this.

Please find the updated patch for this issue.

Thanks.

Dinesh

--
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 6:15 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Thanks Ashesh.

Let me send new patch as per the suggested changes.

Dinesh

--
Dinesh Kumar
Software Engineer

Ph: +918087463317
Skype ID: dinesh.kumar432
www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 5:34 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
As per your comments, you first need to check - it is 64 bit windows or not, and then check it is 32 bit pgAdmin III.

Hence - the code should look like something like this:
if (::wxIsPlatform64Bit() && programFiles == programFilesX86)
{
...
pgRegKey *pgKey = pgRegKey::OpenRegKey(HKEY_LOCAL_MACHINE, wxT("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"), pgRegKey::PGREG_READ, pgRegKey::PGREG_WOW64);
...
}

On Tue, Oct 29, 2013 at 3:37 PM, Dave Page <dpage@pgadmin.org> wrote:
Ashesh - can you review/commit this please? I'm swamped at the moment. Thanks.

On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi Dave,
>
> Thanks for your valuable inputs.
>
> On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.com> wrote:
>>>
>>> Hi Dave/Team,
>>>
>>> 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.
>
> Kindly let me know your inputs on this patch.
>
> Thanks in advance.
>
> Regards,
> Dinesh
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

Attachment

Fix_EnterpriseDBPath_Notset_Bydefault-V3.patch

Re: Patch for EDB binary path not set by default.

From

Ashesh Vashi

Date:

18 November 2013, 11:03:12

On Mon, Nov 11, 2013 at 12:27 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Ashesh,

Sorry for the huge delay on this.

Please find the updated patch for this issue.

Checked-in with small change.

Thanks.

Dinesh

--
Dinesh Kumar
Software Engineer

Ph: +918087463317
Skype ID: dinesh.kumar432
www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 6:15 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:
Thanks Ashesh.

Let me send new patch as per the suggested changes.

Dinesh

--
Dinesh Kumar
Software Engineer

Ph: +918087463317
Skype ID: dinesh.kumar432
www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 5:34 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
As per your comments, you first need to check - it is 64 bit windows or not, and then check it is 32 bit pgAdmin III.

Hence - the code should look like something like this:
if (::wxIsPlatform64Bit() && programFiles == programFilesX86)
{
...
pgRegKey *pgKey = pgRegKey::OpenRegKey(HKEY_LOCAL_MACHINE, wxT("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"), pgRegKey::PGREG_READ, pgRegKey::PGREG_WOW64);
...
}

On Tue, Oct 29, 2013 at 3:37 PM, Dave Page <dpage@pgadmin.org> wrote:
Ashesh - can you review/commit this please? I'm swamped at the moment. Thanks.

On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi Dave,
>
> Thanks for your valuable inputs.
>
> On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.com> wrote:
>>>
>>> Hi Dave/Team,
>>>
>>> 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.
>
> Kindly let me know your inputs on this patch.
>
> Thanks in advance.
>
> Regards,
> Dinesh
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

--
--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

Re: Patch for EDB binary path not set by default.

From

Dinesh Kumar

Date:

18 November 2013, 11:40:49

On Mon, Nov 18, 2013 at 1:32 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Mon, Nov 11, 2013 at 12:27 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:
Hi Ashesh,

Sorry for the huge delay on this.

Please find the updated patch for this issue.
Checked-in with small change.

Thanks Ashesh.

Thanks.

Dinesh

--
Dinesh Kumar
Software Engineer

Ph: +918087463317
Skype ID: dinesh.kumar432
www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 6:15 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:
Thanks Ashesh.

Let me send new patch as per the suggested changes.

Dinesh

--
Dinesh Kumar
Software Engineer

Ph: +918087463317
Skype ID: dinesh.kumar432
www.enterprisedb.co m

Follow us on Twitter
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Oct 30, 2013 at 5:34 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
As per your comments, you first need to check - it is 64 bit windows or not, and then check it is 32 bit pgAdmin III.

Hence - the code should look like something like this:
if (::wxIsPlatform64Bit() && programFiles == programFilesX86)
{
...
pgRegKey *pgKey = pgRegKey::OpenRegKey(HKEY_LOCAL_MACHINE, wxT("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"), pgRegKey::PGREG_READ, pgRegKey::PGREG_WOW64);
...
}

On Tue, Oct 29, 2013 at 3:37 PM, Dave Page <dpage@pgadmin.org> wrote:
Ashesh - can you review/commit this please? I'm swamped at the moment. Thanks.

On Mon, Oct 14, 2013 at 10:13 AM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> Hi Dave,
>
> Thanks for your valuable inputs.
>
> On Fri, Oct 11, 2013 at 7:05 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Wed, Oct 9, 2013 at 2:12 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.com> wrote:
>>>
>>> Hi Dave/Team,
>>>
>>> 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.
>
> Kindly let me know your inputs on this patch.
>
> Thanks in advance.
>
> Regards,
> Dinesh
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

--
--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi