Обсуждение: psql 8.0 final not working on NT 4.0sp6
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. I got this for both the version I compiled and psql from the pgInstaller (both operations done on Windows XP). I suppose that the compiler and/or installer could be doing something different for Windows NT? The last version I tested on NT 4 was 8.0.0rc-1 which works OK. I'm also curious as to why the version of psql I compile is about 7K bytes smaller than what the installer gives me. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
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
> >> 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
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
>> 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 { throwan 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