Question about DLL search directories

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In recent versions of Windows, the following order is used to search
for a DLL that an application wants to load:

1) the directory from which the application loaded
2) the system directory
3) the 16-bit system directory
4) the Windows directory
5) the current directory
6) the directories that are listed in the PATH environment variable

Prior to Windows XP SP2, the current directory was searched second
(before the system directory), but that was changed for security
purposes.

But can someone explain to me how the current directory could ever
contain DLLs that the program needs, if the current directory is
different from the other directories listed above? Seems like if a
program needs DLLs, then they will be located in either the
application directory (or one of its subdirectories) or in the system
directories. Why would the current directory need to be searched at
all?
 
May also depend on DLL registrations. Really a question for the application
developer.

--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
 
On Wed, 11 Jul 2007 10:15:06 -0700, "(e-mail address removed)"
In recent versions of Windows, the following order is used to search
for a DLL that an application wants to load:
Click to expand...

0) In-memory copy (i.e. if the .DLL is already loaded)
1) the directory from which the application loaded
2) the system directory
3) the 16-bit system directory
4) the Windows directory
5) the current directory
6) the directories that are listed in the PATH environment variable
Click to expand...
Prior to Windows XP SP2, the current directory was searched second
(before the system directory), but that was changed for security
purposes.
Click to expand...

The same concern might apply to order of elements in %Path%.
But can someone explain to me how the current directory could ever
contain DLLs that the program needs, if the current directory is
different from the other directories listed above?
Click to expand...

I think it depends on how you define "the directory from which the
application loaded". A formal installation may populate the registry
with such settings, which may be absent if the app is one that has
been scraped over, distributed as an un-automated "extract and run"
..ZIP, or otherwise does not need integration.

But I agree with you; the dir I'd look in is the dir where the primary
executable was located, not the directory that was current.

For example, I may launch C:\SomePath\RunMe.exe via a shortcut that
sets the current folder to C:\Somewhere\Else, or I may invoke the
program via a file association to process C:\Somewhere\Else\Data.xyz

In both cases, the dir to expect related .DLL would be C:\SomePath,
and not C:\Somewhere\Else - and it is really hard to think of a
context where one would want to find and use .DLL in the latter.
Seems like if a program needs DLLs, then they will be located in
either the application directory (or one of its subdirectories) or in
the system directories. Why would the current directory need to
be searched at all?
Click to expand...

One clue suggests itself; "(or one of its subdirectories)". There is,
or should be, no searching in subdirectories for .DLLs, and yet you
could contrive the situation where common .DLLs are in a base
directory set as "current", while the actual programs being launched
are in subdirectories of this, or elsewhere.

In practice, you may find most .DLL are explicitly pathed via registry
settings - which is another potential can of worms.



--------------- ---- --- -- - - - -
Click to expand...
"We have captured lightning and used
it to teach sand how to think."
 
Back
Top