Re: Novice Guide to Windows Compile How to

> >> 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.

From what I can tell, this article is not valid for XP SP1+ and Server
2003 (if you look at the article, you'll see that it specifically
excludes Windows Server 2003). Current Directory is moved way down on
the list. But it could be that "application directory" is treated
different than "current directory". Look at the text in this article:
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/
html/secure06122003.asp

under the header "DLL Search Order Has Changed".
It says it loads from the system directories *first*. Now, if there is
no DLL in the system directories, then it will pick it up from the app
dir. But if there is a different version in the system dirs, it will use
that one (and break).


But then it really shouldn't affect this. It's still loaded before
what's in the PATH. What it says is we should stay away from stuffing
things in the windows/system directories. That will create problems in
the future.

//Magnus