msvcr80.dll and PostgreSQL 8.3 under Windows XP

Hi.

It seems that MSVCR80.dll is not registered to InstallFinalize on the problem of the timing of an installer.
It is not found at the time of initdb. Therefore, please before install this.
http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en

The adjustment of Installer may be necessity. It must consider many situations. However, The solution
method was not found even in MSDN....It seems that what is used in the middle of install can't be execute.

to Dave.
Did you already find the solution method?

Regards,
Hiroshi Saito

----- Original Message -----
From: "Hermann Muster" <Hermann.Muster@gmx.de>
To: <pgsql-general@postgresql.org>
Sent: Monday, February 04, 2008 11:43 PM
Subject: [GENERAL] msvcr80.dll and PostgreSQL 8.3 under Windows XP

Konbanwa Hiroshi-san,

thanks for your fast reply. I installed the Microsoft Visual C++ 2005
SP1 Redistributable Package (x86) before running the PostgreSQL 8.3
setup. However, the PostgreSQL installation does still not find the
msvcr80.dll.

It seems, that the PostgreSQL setup has to be adjusted or is there any
other possibility to get it working under XP? Background is that our
application's setup is installing it's database on PostgreSQL and can't
completely do that with the dll missing.

Greetings,
Hermann

Hiroshi Saito schrieb:

On Feb 4, 2008 3:38 PM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote:

Hi.

It seems that MSVCR80.dll is not registered to InstallFinalize on the problem of the timing of an installer.
It is not found at the time of initdb. Therefore, please before install this.
http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&amp;DisplayLang=en

The adjustment of Installer may be necessity. It must consider many situations. However, The solution
method was not found even in MSDN....It seems that what is used in the middle of install can't be execute.

to Dave.
Did you already find the solution method?

I haven't been looking for one. One of my standard tests when
releasing a new version is to try an iinstall on a clean copy of XP.
I've just re-tested that to be sure and I see the installer copying
the runtimes, and everything works just fine afterwards.

As an additional test, I tried to execute a copy of psql.exe. Before
running the installer it simply exited with 'The system cannot execute
the specified program' (which is the normal message if the runtimes
cannot be found), but after I ran the installer, the same copy of psql
popped up a message box saying it couldn't find an SSL library (to be
expected - I didn't copy it) - that tells me it could then find the
runtimes.

So, is there some reason the runtimes might not install in non-English
versions of Windows? We're using the Windows Installer merge module as
per Microsoft's recommendations.

Regards, Dave.

Hi.

Umm, Please investigate msm under the following.
C:\Program Files\Common Files\Merge Modules
Microsoft_VC80_CRT_x86.msm

Please investigate the date and size of that.?

Regards,
Hiroshi Saito

----- Original Message -----
From: "Hermann Muster" <Hermann.Muster@gmx.de>

Hi.

----- Original Message -----
From: "Dave Page" <dpage@postgresql.org>

So, is there some reason the runtimes might not install in non-English
versions of Windows? We're using the Windows Installer merge module as
per Microsoft's recommendations.

Surely your examination is passed. Therfore, It may be the problem of some languages.
However, It seems that MSVCR80 also has the version problem. Furthermore, the
problem was seen by VISTA...but but, I did not have a spare time....
Anyway, If there are again in addition to this situation, we need investigation deep as
a clear problem.

Regards,
Hiroshi Saito

There's at least one website out there that offers DLLs for download,
but I have no idea whether this is legal or not. Can anyone comment?

Ray.

---------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
---------------------------------------------------------------

On Feb 4, 2008, at 9:37 AM, Raymond O'Donnell wrote:

There's at least one website out there that offers DLLs for
download, but I have no idea whether this is legal or not. Can
anyone comment?

It's the C runtime. IIRC that's one of the redistributables, so it's
OK to distribute.

Cheers,
Steve

Hi.

MSVCR80.dll which the binary of 8.3 refers to is this.
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll
I tried again in the beautiful environment which does not have 8.0.50727.762 in the environment of XP-SP2.
Then, It was fine. I can't remember the environment which received the report by RC2.?_?
It is likely to be necessary to investigate the environment of Hermann-san.

P.S)
However, It seems that a VISTA user's problem remains.

Regards,
Hiroshi Saito

----- Original Message -----
From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>

On Feb 4, 2008 6:37 PM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote:

Hi.

MSVCR80.dll which the binary of 8.3 refers to is this.
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll
I tried again in the beautiful environment which does not have 8.0.50727.762 in the environment of XP-SP2.
Then, It was fine. I can't remember the environment which received the report by RC2.?_?
It is likely to be necessary to investigate the environment of Hermann-san.

Yes - Hermann; can you elaborate on your system please? Service pack
level, language etc. etc.

However, It seems that a VISTA user's problem remains.

Sorry, which Vista problem?

/D

Dave Page schrieb:

On Feb 4, 2008 6:37 PM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote:

Hi.

MSVCR80.dll which the binary of 8.3 refers to is this.
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll
I tried again in the beautiful environment which does not have 8.0.50727.762 in the environment of XP-SP2.
Then, It was fine. I can't remember the environment which received the report by RC2.?_?
It is likely to be necessary to investigate the environment of Hermann-san.

Yes - Hermann; can you elaborate on your system please? Service pack
level, language etc. etc.

However, It seems that a VISTA user's problem remains.

Sorry, which Vista problem?

/D

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

I'm using a clean Virtual PC Image of a German Windows XP SP2.

I also checked the folder C:\Program Files\Common Files\Merge Modules
Microsoft_VC80_CRT_x86.msm which is not available on my system.

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll
is however exactly there on my system. But Dependancy Walker still does
not find the MSVCR80.dll.

Do you need any other information from me?

Regards,
Hermann

On Feb 5, 2008 7:52 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

I'm using a clean Virtual PC Image of a German Windows XP SP2.

OK - I've been testing on a clean English XP Pro SP2.

I also checked the folder C:\Program Files\Common Files\Merge Modules
Microsoft_VC80_CRT_x86.msm which is not available on my system.

It wouldn't be - that file is the merge module we build into the
installer, and unless you have a non-Express version of Visual C++ you
won't have it. It'll get unpacked into the files we need upon
installation.

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll
is however exactly there on my system. But Dependancy Walker still does
not find the MSVCR80.dll.

Thats where it is on my machine. Looking at the Microsoft notes
(http://msdn2.microsoft.com/en-us/library/ms235290.aspx) - it makes
the point that the installation will fail for non-administrators, and
the dependent apps then won't work. I don't suppose you have power
user rights but not full administrator rights in user account you're
using?

Regards,. Dave

On Feb 13, 2008 3:05 PM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

Dave Page schrieb:

On Feb 5, 2008 7:52 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

I also checked the folder C:\Program Files\Common Files\Merge Modules
Microsoft_VC80_CRT_x86.msm which is not available on my system.

It wouldn't be - that file is the merge module we build into the
installer, and unless you have a non-Express version of Visual C++ you
won't have it. It'll get unpacked into the files we need upon
installation.

Where will it be unpacked? Into the PostgreSQL application directory? As
we are using similar systems, can you tell me if the dll is successfully
installed on your system?

The merge module? Into the directory you already checked:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll

The user I'm trying to install it with is an user with full
administrator rights. I hope you can help me with this issue, as besides
other issues concerning PostgreSQL 8.3 we could solve on our own, this
one is the last thing preventing us to release our application with
PostgreSQL 8.3 support.

My best guess at the moment is that something is borked on your
system. I've spent most of the week testing various methods of
installing the runtimes and the one that has worked every time without
fail is the Microsoft installer that Hiroshi-san suggested you try.

I would suggest re-running that, but with a slightly more inventive
commandline - eg, something like:

vcredist_x86.exe /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /i
vcredist.msi REINSTALLMODE=vamus REINSTALL=ALL /qb /l*v
vcredist_install.log"" "

What that /should/ do, is run the MSI installer (which is buried
inside two, count 'em, two .exe wrappers!) in full reinstall
*everything* mode, and create a nice verbose logfile so we can see if
anything fails.

Once thats reinstalled, try running the PG installer again (also with
logging enabled), and if it still doesn't work, we can start looking
at the logfiles.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Oracle-compatible database company

Dave Page schrieb:

On Feb 13, 2008 3:05 PM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

Dave Page schrieb:

On Feb 5, 2008 7:52 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

I also checked the folder C:\Program Files\Common Files\Merge Modules
Microsoft_VC80_CRT_x86.msm which is not available on my system.

It wouldn't be - that file is the merge module we build into the
installer, and unless you have a non-Express version of Visual C++ you
won't have it. It'll get unpacked into the files we need upon
installation.

Where will it be unpacked? Into the PostgreSQL application directory? As
we are using similar systems, can you tell me if the dll is successfully
installed on your system?

The merge module? Into the directory you already checked:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll

The user I'm trying to install it with is an user with full
administrator rights. I hope you can help me with this issue, as besides
other issues concerning PostgreSQL 8.3 we could solve on our own, this
one is the last thing preventing us to release our application with
PostgreSQL 8.3 support.

My best guess at the moment is that something is borked on your
system. I've spent most of the week testing various methods of
installing the runtimes and the one that has worked every time without
fail is the Microsoft installer that Hiroshi-san suggested you try.

I would suggest re-running that, but with a slightly more inventive
commandline - eg, something like:

vcredist_x86.exe /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /i
vcredist.msi REINSTALLMODE=vamus REINSTALL=ALL /qb /l*v
vcredist_install.log"" "

What that /should/ do, is run the MSI installer (which is buried
inside two, count 'em, two .exe wrappers!) in full reinstall
*everything* mode, and create a nice verbose logfile so we can see if
anything fails.

Once thats reinstalled, try running the PG installer again (also with
logging enabled), and if it still doesn't work, we can start looking
at the logfiles.

Hi Dave,

after testing several combinations I can tell you following, because
maybe I couldn't make clear what my problem is. The msvcr80.dll is
correctly installed in the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700
respective the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb
folder for my german version of Windows XP.

What I don't understand is why the msvcr80.dll is not copied to the
PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup. Because when I
check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not
be found, however it is installed in the above two folders. And that's
where my application comes into play. The libpq.dll can't be used
because it does not find the msvcr80.dll. Did you check on that before?
Can you load this library?

Thanks for your help.
Regards,
Hermann

On Feb 18, 2008 10:05 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

Hi Dave,

after testing several combinations I can tell you following, because
maybe I couldn't make clear what my problem is. The msvcr80.dll is
correctly installed in the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700
respective the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb
folder for my german version of Windows XP.

What I don't understand is why the msvcr80.dll is not copied to the
PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup.

Because it's not supposed to be.

Because when I
check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not
be found, however it is installed in the above two folders. And that's
where my application comes into play. The libpq.dll can't be used
because it does not find the msvcr80.dll. Did you check on that before?
Can you load this library?

Yes - if the runtimes are *properly* installed, any application should
be able to find them in the winsxs folder - thats how Microsoft
designed it to work.

Did you try doing what I asked in my previous message?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Oracle-compatible database company

Dave Page schrieb:

On Feb 18, 2008 10:05 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

Hi Dave,

after testing several combinations I can tell you following, because
maybe I couldn't make clear what my problem is. The msvcr80.dll is
correctly installed in the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700
respective the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb
folder for my german version of Windows XP.

What I don't understand is why the msvcr80.dll is not copied to the
PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup.

Because it's not supposed to be.

Because when I
check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not
be found, however it is installed in the above two folders. And that's
where my application comes into play. The libpq.dll can't be used
because it does not find the msvcr80.dll. Did you check on that before?
Can you load this library?

Yes - if the runtimes are *properly* installed, any application should
be able to find them in the winsxs folder - thats how Microsoft
designed it to work.

Did you try doing what I asked in my previous message?

I finally found the problem. I unfortunately used an "very" old version
of Dependency Walker which couldn't handle the libpq.dll and always
showed that the msvcr80.dll is missing. After installing PostgreSQL 8.3
and updating the Dependency Walker, everything seems to be fine and my
application can use the libpq.dll. Will test it again in the next days.

However, one question remains. On my clean Virtual PC Image, there is
already a folder
"C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb"
containing the msvcr80.dll. After installing PostgreSQL or the runtimes,
there is another folder
"C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700".
But only the path of the dll installed with the runtimes is recognized.
Does that mean our customers have to install the runtimes at all costs?
That would be the case if our application is running on a client, not
the server PostgreSQL is installed on?

Thanks again.

Regards,
Hermann

On Feb 18, 2008 3:11 PM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

I finally found the problem. I unfortunately used an "very" old version
of Dependency Walker which couldn't handle the libpq.dll and always
showed that the msvcr80.dll is missing. After installing PostgreSQL 8.3
and updating the Dependency Walker, everything seems to be fine and my
application can use the libpq.dll. Will test it again in the next days.

Good :-)

However, one question remains. On my clean Virtual PC Image, there is
already a folder
"C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb"
containing the msvcr80.dll. After installing PostgreSQL or the runtimes,
there is another folder
"C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700".
But only the path of the dll installed with the runtimes is recognized.
Does that mean our customers have to install the runtimes at all costs?
That would be the case if our application is running on a client, not
the server PostgreSQL is installed on?

Microsoft have changed things so that you now have multiple versions
of the runtimes installed side by side without them conflicting with
one another - we use the latest (SP1) version (8.0.50727.762) with
PostgreSQL - something else has presumably added the earlier verison
you also have (8.0.50727.163). Any machine using libpq (client or
server) or any part of the server will need the correct version of the
runtimes to be installed.

You can avoid this by building your own libpq.dll using mingw/msys if
you like - that will work just fine with a VC++ built server.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Oracle-compatible database company

On Mon, Feb 18, 2008 at 04:11:14PM +0100, Hermann Muster wrote:

Dave Page schrieb:

On Feb 18, 2008 10:05 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote:

Hi Dave,

after testing several combinations I can tell you following, because
maybe I couldn't make clear what my problem is. The msvcr80.dll is
correctly installed in the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700
respective the
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb
folder for my german version of Windows XP.

What I don't understand is why the msvcr80.dll is not copied to the
PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup.

Because it's not supposed to be.

Because when I
check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not
be found, however it is installed in the above two folders. And that's
where my application comes into play. The libpq.dll can't be used
because it does not find the msvcr80.dll. Did you check on that before?
Can you load this library?

Yes - if the runtimes are *properly* installed, any application should
be able to find them in the winsxs folder - thats how Microsoft
designed it to work.

Did you try doing what I asked in my previous message?

I finally found the problem. I unfortunately used an "very" old version
of Dependency Walker which couldn't handle the libpq.dll and always
showed that the msvcr80.dll is missing. After installing PostgreSQL 8.3
and updating the Dependency Walker, everything seems to be fine and my
application can use the libpq.dll. Will test it again in the next days.

However, one question remains. On my clean Virtual PC Image, there is
already a folder
"C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb"
containing the msvcr80.dll. After installing PostgreSQL or the runtimes,
there is another folder
"C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700".

The second one is a servicepacked version. IIRC, it also contains some
security fixes.

But only the path of the dll installed with the runtimes is recognized.
Does that mean our customers have to install the runtimes at all costs?
That would be the case if our application is running on a client, not the
server PostgreSQL is installed on?

Yes, any app linked against libpq need these runtimes.

//Magnus

Dave Page wrote:

You can avoid this by building your own libpq.dll using mingw/msys if
you like - that will work just fine with a VC++ built server.

Hi Dave,
Just some thoughts on the whole libpq.dll thing.

It would be really nice from a client distribution view of things to
have a libpq.dll that was not so dependency heavy.
For the 8.3 release the total amount of files needed to use things such
as pg_dump.exe is close to 5mb.

maybe a light version of libpq.dll is needed, just the libpq and the
open ssl dlls would be ideal, many times all that extra stuff is not
needed just to run pg_dump.

Didn't there used to be a project on pgfoundry that built the client
tools separate from the server build?

Just some thoughts,

Later,

Tony

On Feb 18, 2008 3:38 PM, Tony Caduto <tony_caduto@amsoftwaredesign.com> wrote:

Dave Page wrote:

You can avoid this by building your own libpq.dll using mingw/msys if
you like - that will work just fine with a VC++ built server.

Hi Dave,
Just some thoughts on the whole libpq.dll thing.

It would be really nice from a client distribution view of things to
have a libpq.dll that was not so dependency heavy.
For the 8.3 release the total amount of files needed to use things such
as pg_dump.exe is close to 5mb.

maybe a light version of libpq.dll is needed, just the libpq and the
open ssl dlls would be ideal, many times all that extra stuff is not
needed just to run pg_dump.

Didn't there used to be a project on pgfoundry that built the client
tools separate from the server build?

I think so. From our perspective though we need to ensure that libpq
will support the same options as the server we ship (for example, I
know people that do need Kerberos support) - bundling two different
builds will doubtless create confusion.

Maybe you should consider reviving that project?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Oracle-compatible database company