Re: win2k, service, pg_ctl, popen, etc

> If we don't know why, sign one more down as a bug in mingw (hardly
> surprising - just the area of pipes and consoles seems to be
> where it's weak). In that case, why not just recode pg_ctl to execute
> postmaster.exe from the same directory it found pg_ctl.exe
> in. This can easily be done using GetModuleFileName(). Is a pipe opened at

> any other place? Or does other places need to be fixed as well (I haven't
gone
> through the whole code).

Moreover, all the find_*_exec calls could (and IMHO, should) make use of
GetModuleFileName. Win32 has an API to find the running file name; *nix does
not and so we have to jump through a few hoops. I just don't see the sense
in jumping through the same hoops under Win32.

Sure, the functions also make certain that the version is as expected, but
to my mind this is just a safety check to make sure the hoops we just jumped
through were all in order. Of course, we'd also lose the ability to protect
people who mix versions in the same directory, but such people need a lot
more protection from themselves than we can provide. ;-)

Does there continue to be any resistance to this approach? If not, I'll
gladly provide a patch.

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli wrote:

>>If we don't know why, sign one more down as a bug in mingw (hardly
>>surprising - just the area of pipes and consoles seems to be
>>where it's weak). In that case, why not just recode pg_ctl to execute
>>postmaster.exe from the same directory it found pg_ctl.exe
>>in. This can easily be done using GetModuleFileName(). Is a pipe opened at
>>
>>
>
>
>
>>any other place? Or does other places need to be fixed as well (I haven't
>>
>>
>gone
>
>
>>through the whole code).
>>
>>
>
>Moreover, all the find_*_exec calls could (and IMHO, should) make use of
>GetModuleFileName. Win32 has an API to find the running file name; *nix does
>not and so we have to jump through a few hoops. I just don't see the sense
>in jumping through the same hoops under Win32.
>
>Sure, the functions also make certain that the version is as expected, but
>to my mind this is just a safety check to make sure the hoops we just jumped
>through were all in order. Of course, we'd also lose the ability to protect
>people who mix versions in the same directory, but such people need a lot
>more protection from themselves than we can provide. ;-)
>
>Does there continue to be any resistance to this approach? If not, I'll
>gladly provide a patch.
>
>
>
>

As I understand it, Windows has a standard set of DLL/EXE metadata
(build number, copyright, product name yadda yadda yadda) stored in some
well-known segment of the file. Is there any reason we can't put the
version number somewhere in there and use some standard API to extract
it, rather than running the .exe to make it tell us? (Not that I have
any idea how to do such a thing.)

cheers

andrew

Andrew Dunstan wrote:

>
> As I understand it, Windows has a standard set of DLL/EXE metadata
> (build number, copyright, product name yadda yadda yadda) stored in some
> well-known segment of the file. Is there any reason we can't put the
> version number somewhere in there and use some standard API to extract
> it, rather than running the .exe to make it tell us? (Not that I have
> any idea how to do such a thing.)

It's the VERSION resource, look at GetFileVersionInfo in the docs.

Regards,
Andreas

Claudio Natoli wrote:
>
> > If we don't know why, sign one more down as a bug in mingw (hardly
> > surprising - just the area of pipes and consoles seems to be
> > where it's weak). In that case, why not just recode pg_ctl to execute
> > postmaster.exe from the same directory it found pg_ctl.exe
> > in. This can easily be done using GetModuleFileName(). Is a pipe opened at
>
> > any other place? Or does other places need to be fixed as well (I haven't
> gone
> > through the whole code).
>
> Moreover, all the find_*_exec calls could (and IMHO, should) make use of
> GetModuleFileName. Win32 has an API to find the running file name; *nix does
> not and so we have to jump through a few hoops. I just don't see the sense
> in jumping through the same hoops under Win32.
>
> Sure, the functions also make certain that the version is as expected, but
> to my mind this is just a safety check to make sure the hoops we just jumped
> through were all in order. Of course, we'd also lose the ability to protect
> people who mix versions in the same directory, but such people need a lot
> more protection from themselves than we can provide. ;-)
>
> Does there continue to be any resistance to this approach? If not, I'll
> gladly provide a patch.

GetModuleFileName() doesn't solve our problem here. We already know
what we think is the right path, but we have to be sure that we are
calling a matching version binary. For example, initdb wants to call a
postgres that is the right version, as does pg_ctl. We have had
mismatches reported in the past, and with relocatable installs it is
even more likely.

The version check is centralized in one place, exec.c, and I don't want
to have different behaviors on Win32 and Unix if we can help it. Let's
go with the system() into a temp file.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

> The version check is centralized in one place, exec.c, and I don't want
> to have different behaviors on Win32 and Unix if we can help it. Let's
> go with the system() into a temp file.

You know that system() isn't executed synchronously under win32, don't you?

Version resource checking seems much more suitable. Additionally, more
or less every win32 executable or dll should have the version resource.
IMHO a missing resource is an indicator of a win32 novice programmer.

Regards,
Andreas

Bruce Momjian wrote:

>The version check is centralized in one place, exec.c, and I don't want
>to have different behaviors on Win32 and Unix if we can help it. Let's
>go with the system() into a temp file.
>
>
>

I had another thought - would the popen work for a nonconsole app (e.g.
a service) if we redirect stdin from the nul device (and maybe also do
stderr via 2>&1), so it doesn't try to inherit from the caller, which
doesn't have these?

cheers

andrew