psql 8.0 final not working on NT 4.0sp6

Hi Magnus,

On Jan 18, 2005, at 10:50 AM, Magnus Hagander wrote:

I'm running 'psql.exe -- version' and I'm getting this dialog:

psql.exe - Entry Point Not Found: The procedure entry point
SHGetSpecialFolderPathA could not be located in the dynamic
link library SHELL32.DLL.

Do you have the IE4 Desktop Update installed?

I think so. System Properties for my computer shows

NT 4.00.1381
IE 5 5.50.4308.2900

If this is not what you are asking, let me know where to look.

I'm also curious as to why the version of psql I compile is
about 7K bytes smaller than what the installer gives me.

SSL suport possibly? Use pg_config from the installer to find the exact
commandline used for that. If that's not it, then different version of
mingw gcc probably.

That's it -- thanks.

If I'm posting to the wrong list for this, please let me know.

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

I'm running 'psql.exe -- version' and I'm getting this dialog:

psql.exe - Entry Point Not Found: The procedure entry point
SHGetSpecialFolderPathA could not be located in the dynamic link
library SHELL32.DLL.

Do you have the IE4 Desktop Update installed?

I think so. System Properties for my computer shows

NT 4.00.1381
IE 5 5.50.4308.2900

If this is not what you are asking, let me know where to look.

Hmm. That would seem to have it. Can you check the version on your
SHELL32.DLL?
The MSDN docs for the version in question
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellc
c/platform/shell/reference/functions/shgetspecialfolderpath.asp) claims
it needs either Win2k or The IE 4.0 Desktop Update. Which resolves to
shell32.dll version 4.71 or later.

I'm also curious as to why the version of psql I compile

is about 7K

bytes smaller than what the installer gives me.

SSL suport possibly? Use pg_config from the installer to find the
exact commandline used for that. If that's not it, then different
version of mingw gcc probably.

That's it -- thanks.

If I'm posting to the wrong list for this, please let me know.

hackers-win32 is prboably slightly more on-topic.

//Magnus

On Jan 18, 2005, at 11:05 AM, Magnus Hagander wrote:

Hmm. That would seem to have it. Can you check the version on your
SHELL32.DLL?
The MSDN docs for the version in question
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
shellc
c/platform/shell/reference/functions/shgetspecialfolderpath.asp) claims
it needs either Win2k or The IE 4.0 Desktop Update. Which resolves to
shell32.dll version 4.71 or later.

WINNT\System32\Shell32.dll is version 4.00, so that appears to be the
problem.

According to this: http://support.microsoft.com/kb/q165695/ Windows
Desktop update was included with IE 4, but not with IE 5 or later.
Further, if you want to install Windows Desktop Update you have to
first remove IE 5 or later. And finally it says that Windows Desktop
Update can only be installed using the IE 4 setup, but this is no
longer available from Microsoft. What a mess.

hackers-win32 is prboably slightly more on-topic

OK, will do for next time.

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

Hmm. That would seem to have it. Can you check the version on your
SHELL32.DLL?
The MSDN docs for the version in question
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
shellc

c/platform/shell/reference/functions/shgetspecialfolderpath.asp) claims

it needs either Win2k or The IE 4.0 Desktop Update. Which resolves to
shell32.dll version 4.71 or later.

WINNT\System32\Shell32.dll is version 4.00, so that appears to be the
problem.

According to this: http://support.microsoft.com/kb/q165695/ Windows
Desktop update was included with IE 4, but not with IE 5 or later.
Further, if you want to install Windows Desktop Update you have to
first remove IE 5 or later. And finally it says that Windows Desktop
Update can only be installed using the IE 4 setup, but this is no
longer available from Microsoft. What a mess.

Yikes. that's certainly a mess. I see the following options:

1) Declare NT4 without IE4 unsupported. This is by far the easiest :P
What we'd do later is add a check to the MSI installer to inform the
user about this.

2) Revert to the pre-8.0 behaviour with the files. This is IMHO a very
bad idea, because that was not well-behaved on *current* Windows
platforms.

3) Change to using SHGetFolderPath() linked from shfolder.dll (note that
this function exists in two different dlls. We'd need the one in
shfolder.dll to have any effect). And then point people who don't have
shfolder.dll to the Microsoft download site for this file (it's
redistributable, but only in an unmodified self-extracting file, so we
can't easily embed it in the installer. can be done, but not as easy as
one would like). It will be required on most systems running 95, 98 and
NT4 (without it we'll be broken on 95 and 98, which work today). The
file is included on current windows versions by default. This is
probably the nicest idea, but I'm not sure how much work we want to
throw into the NT4 support. Considering MS has stopped supporting it
even to their pay-through-the-nose-for-support customers by now. (and we
*do* work on NT4 as long as the user has installed IE4)

Thoughts?

//Magnus

Hi Magnus,

On Jan 18, 2005, at 1:34 PM, Magnus Hagander wrote:

1) Declare NT4 without IE4 unsupported. This is by far the easiest :P
What we'd do later is add a check to the MSI installer to inform the
user about this.

Seems a bit gross to say that NT4 is supported, but only if you happen
to have a really old version of IE (or you happened to install it and
choose the right option somewhere along your way to a later IE
version). If I read the MS page correctly, having IE 4 installed does
not guarantee things will work. You must have chosen the option to
install Windows Desktop Update. I would not be surprised if I did this
-- I hate the Windows explorer interfaces that tries to make everything
look like a web page :).

2) Revert to the pre-8.0 behaviour with the files. This is IMHO a very
bad idea, because that was not well-behaved on *current* Windows
platforms.

Is it not possible to add a version check and just use the old method
with Windows NT?

What is this function call used to get other than the user's home
directory?

3) Change to using SHGetFolderPath() linked from shfolder.dll (note
that
this function exists in two different dlls. We'd need the one in
shfolder.dll to have any effect). And then point people who don't have
shfolder.dll to the Microsoft download site for this file (it's
redistributable, but only in an unmodified self-extracting file, so we
can't easily embed it in the installer. can be done, but not as easy as
one would like). It will be required on most systems running 95, 98 and
NT4 (without it we'll be broken on 95 and 98, which work today). The
file is included on current windows versions by default. This is
probably the nicest idea, but I'm not sure how much work we want to
throw into the NT4 support. Considering MS has stopped supporting it
even to their pay-through-the-nose-for-support customers by now. (and
we
*do* work on NT4 as long as the user has installed IE4)

I certainly understand not wanting to spend a bunch of time on NT
support. But everything seemed fine through 8.0.0-rc1, so I would hate
to see it go away over this one issue. I did not realize that 95/98
worked at all. I don't think anyone really wants to setup a server on
95, 98, or even NT4, but it would be really nice if psql would work.

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

Magnus Hagander wrote:

According to this: http://support.microsoft.com/kb/q165695/ Windows
Desktop update was included with IE 4, but not with IE 5 or later.
Further, if you want to install Windows Desktop Update you have to
first remove IE 5 or later. And finally it says that Windows Desktop
Update can only be installed using the IE 4 setup, but this is no
longer available from Microsoft. What a mess.

Yikes. that's certainly a mess. I see the following options

Hello, Magnus. I read the -bugs thread that resulted in this code and
choose not to comment since I thought that perhaps my understanding of
the implications of using SHFolder.dll v. Shell32.dll was in error.

However, installer code that I had authored before that works on both
98, XP, and NT does:

module = LoadLibrary("SHFolder.dll");
if (module != NULL) {
getfolderv1 = GetProcAddress(module, "SHGetFolderPathA");
...
invoke function, deal with ANSI path
...
FreeLibrary(module);
} else {
module = LoadLibrary("shell32.dll");
if (module != NULL) {
getfolderv2 = GetProcAddress(module, "SHGetSpecialFolderLocation");
...
invoke function, deal with UNICODE path
...
FreeLibrary(module);
} else {
throw an exception here...
}
}

I think the way to guarantee success is to ship the redistributable dll,
shfolder.dll with the application, which would eliminate the need to try
and fall back to shell32.dll. shfolder.dll is redistributable:

http://www.microsoft.com/downloads/details.aspx?FamilyID=6ae02498-07e9-48f1-a5d6-dbfa18d37e0f&DisplayLang=en

This article explains what needs to be done to write an installer for
older platforms:

http://support.microsoft.com/default.aspx?scid=kb%3BEN-US%3B227051

Note:

"Important: SHGetFolderPath is new to the Windows 2000 API. If you call
SHGetFolderPath from an application that can be installed on a previous
version of Windows, then you will need to redistribute the file
SHFolder.dll with your application."

as does this one:

http://support.microsoft.com/default.aspx?scid=kb%3BEN-US%3BQ241733

My code expects to find an shfolder.dll on < Windows 2000 systems and a
shell32.dll on >= Windows 2000 systems. As I said, I *believe* you can
guarantee success by just shipping shfolder.dll with the application.

Hope that helps,

Mike Mascari

3) Change to using SHGetFolderPath() linked from shfolder.dll (note
that this function exists in two different dlls. We'd need

the one in

shfolder.dll to have any effect). And then point people who

don't have

shfolder.dll to the Microsoft download site for this file (it's
redistributable, but only in an unmodified self-extracting

file, so we

can't easily embed it in the installer. can be done, but

not as easy

as one would like). It will be required on most systems

running 95, 98

and
NT4 (without it we'll be broken on 95 and 98, which work

today). The

file is included on current windows versions by default. This is
probably the nicest idea, but I'm not sure how much work we want to
throw into the NT4 support. Considering MS has stopped

supporting it

even to their pay-through-the-nose-for-support customers by

now. (and

we
*do* work on NT4 as long as the user has installed IE4)

I certainly understand not wanting to spend a bunch of time
on NT support. But everything seemed fine through 8.0.0-rc1,
so I would hate to see it go away over this one issue. I did
not realize that 95/98 worked at all. I don't think anyone
really wants to setup a server on 95, 98, or even NT4, but it
would be really nice if psql would work.

I investigated this further, and have submitted a patch to use this
behaviour. Turns out that my almost-fresh-NT4-install already contains
shfolder.dll - even though I have *not* installed IE on it (it still
runs IE2). Since thw patch itself was trivial, I think this is the
acceptable solution.

Oh, and things were not fine until rc1. It read config/rc files from
different locations, and SSL files were simlpy broken.

95, 98, ME only work for the client. The server never have and never
will work on them (unless you use cygwin).

//Magnus