Magnus Hagander said:
>> >1) I would not suggest copying the LIB directory to the windows
>> >directory. That is just evil :-) Instead, add the pg lib
>> directory to
>> >the system PATH.
>> >
>> >
>>
>> I agree that putting stuff in the Windows directory is evil.
>>
>> Having to use 2 path elements is a bit ugly too, though. My
>> solution has been to move libpq.dll to the bin directory,
>> which makes it work just fine for me without any PATH
>> adjustment. It should actually load binaries slightly faster,
>> too, since the binary location is the very first place
>> Windows looks for DLLs, as I understand it.
>
> That depends on your Windows version.
> In XP with Service Pack 1 and later, and in Server 2003, it searches:
> 1) System locations
> 2) Current directory
> 3) User defined PATHs
>
> Before, it was:
> 1) Current directory
> 2) System locations
> 3) User defined PATHs
>
>
> These newer versions also added SetDllDirectory() - maybe this one will
> help us in some ways?
>
Hmm.
My understanding is that there's a 0th element to these lists:
0) Directory from which the .exe was loaded.
Experimentation on W2K has shown this to be true - i.e. I have the DLL in
the same dir as the exe, but it is not in my path, nor my current dir, nor
my System locs, and it works (e.g. in <install-root> I say "bin\initdb -D
data" and it finds the DLL just fine.
http://support.microsoft.com/default.aspx?scid=kb;en-us;815065 says:
Windows then searches for the DLLs in the following sequence:
. The directory where the executable program for the current process is
located.
. The current directory.
. The Windows system directory. (The GetSystemDirectory function gets the
path of the Windows system directory.)
. The Windows directory. (The GetWindowsDirectory function gets the path
of the Windows directory.)
. The directories that are listed in the PATH environment variable.
cheers
andrew