• DLL Dynamic-Link Library Search Order

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

    A system can contain multiple versions of the same dynamic-link library (DLL).

    Applications can control the location from which a DLL is loaded by specifying a full path or

    using another mechanism such as a manifest.

    If these methods are not used, the system searches for the DLL at load time as described in this topic. 

    • Factors That Affect Searching
    • Search Order for Windows Store apps
      • Standard Search Order for Windows Store apps
      • Alternate Search Order for Windows Store apps
    • Search Order for Desktop Applications
      • Standard Search Order for Desktop Applications
      • Alternate Search Order for Desktop Applications
      • Search Order Using LOAD_LIBRARY_SEARCH Flags
    • Related topics

    Factors That Affect Searching

    The following factors affect whether the system searches for a DLL:

    • If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
    • If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any) instead of searching for the DLL. For a list of known DLLs on the current system, see the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs.
    • If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

     Search Order for Windows Store apps

    When a Windows Store app loads a packaged module by calling the LoadPackagedLibraryfunction, the DLL must be in the package dependency graph of the process. For more information, see LoadPackagedLibrary. When a Windows Store app loads a module by other means and does not specify a full path, the system searches for the DLL and its dependencies at load time as described in this section.

    Windows 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP:  Windows Store apps are supported starting with Windows 8 and Windows Server 2012.

    Before the system searches for a DLL, it checks the following:

    • If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
    • If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any). The system does not search for the DLL. For a list of known DLLs on the current system, see the following registry key:HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs.

    If the system must search for a module or its dependencies, it always uses the search order for Windows Store apps even if a dependency is not Windows Store app code.

    Standard Search Order for Windows Store apps

    If the module is not already loaded or on the list of known DLLs, the system searches these locations in this order:

    1. The package dependency graph of the process. This is the application's package plus any dependencies specified as <PackageDependency> in the <Dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.
    2. The directory the calling process was loaded from.
    3. The system directory (%SystemRoot%system32).

    If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

    Alternate Search Order for Windows Store apps

    If a module changes the standard search order by calling the LoadLibraryEx function withLOAD_WITH_ALTERED_SEARCH_PATH, the system searches the directory the specified module was loaded from instead of the directory of the calling process. The system searches these locations in this order:

    1. The package dependency graph of the process. This is the application's package plus any dependencies specified as <PackageDependency> in the <Dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.
    2. The directory the specified module was loaded from.
    3. The system directory (%SystemRoot%system32).

    Search Order for Desktop Applications

    Desktop applications can control the location from which a DLL is loaded by specifying a full path, using DLL redirection, or by using a manifest. If none of these methods are used, the system searches for the DLL at load time as described in this section.

    Before the system searches for a DLL, it checks the following:

    • If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
    • If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any). The system does not search for the DLL. For a list of known DLLs on the current system, see the following registry key:HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs.

    If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

    Important  If an attacker gains control of one of the directories that is searched, it can place a malicious copy of the DLL in that directory. For ways to help prevent such attacks, see Dynamic-Link Library Security.

    Standard Search Order for Desktop Applications

    The standard DLL search order used by the system depends on whether safe DLL search mode is enabled or disabled. Safe DLL search mode places the user's current directory later in the search order.

    Safe DLL search mode is enabled by default. To disable this feature, create theHKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerSafeDllSearchMode registry value and set it to 0. Calling the SetDllDirectoryfunction effectively disables SafeDllSearchMode while the specified directory is in the search path and changes the search order as described in this topic.

    Windows XP:  Safe DLL search mode is disabled by default. To enable this feature, create theSafeDllSearchMode registry value and set it to 1. Safe DLL search mode is enabled by default starting with Windows XP with Service Pack 2 (SP2).

    If SafeDllSearchMode is enabled, the search order is as follows:

    1. The directory from which the application loaded.
    2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    5. The current directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    If SafeDllSearchMode is disabled, the search order is as follows:

    1. The directory from which the application loaded.
    2. The current directory.
    3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    Alternate Search Order for Desktop Applications

    The standard search order used by the system can be changed by calling the LoadLibraryExfunction with LOAD_WITH_ALTERED_SEARCH_PATH. The standard search order can also be changed by calling the SetDllDirectory function.

    Windows XP:  Changing the standard search order by calling SetDllDirectory is not supported until Windows XP with Service Pack 1 (SP1).

    If you specify an alternate search strategy, its behavior continues until all associated executable modules have been located. After the system starts processing DLL initialization routines, the system reverts to the standard search strategy.

    The LoadLibraryEx function supports an alternate search order if the call specifiesLOAD_WITH_ALTERED_SEARCH_PATH and the lpFileName parameter specifies an absolute path.

    Note that the standard search strategy and the alternate search strategy specified byLoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH differ in just one way: The standard search begins in the calling application's directory, and the alternate search begins in the directory of the executable module that LoadLibraryEx is loading.

    If SafeDllSearchMode is enabled, the alternate search order is as follows:

    1. The directory specified by lpFileName.
    2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    5. The current directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    If SafeDllSearchMode is disabled, the alternate search order is as follows:

    1. The directory specified by lpFileName.
    2. The current directory.
    3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    The SetDllDirectory function supports an alternate search order if the lpPathName parameter specifies a path. The alternate search order is as follows:

    1. The directory from which the application loaded.
    2. The directory specified by the lpPathName parameter of SetDllDirectory.
    3. The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
    4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
    5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    If the lpPathName parameter is an empty string, the call removes the current directory from the search order.

    SetDllDirectory effectively disables safe DLL search mode while the specified directory is in the search path. To restore safe DLL search mode based on the SafeDllSearchMode registry value and restore the current directory to the search order, call SetDllDirectory with lpPathName as NULL.

    Search Order Using LOAD_LIBRARY_SEARCH Flags

    An application can specify a search order by using one or more LOAD_LIBRARY_SEARCH flags with the LoadLibraryEx function. An application can also use LOAD_LIBRARY_SEARCH flags with the SetDefaultDllDirectories function to establish a DLL search order for a process. The application can specify additional directories for the process DLL search order by using theAddDllDirectory or SetDllDirectory functions.

    Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008:  TheLOAD_LIBRARY_SEARCH flags are available on systems with KB2533623 installed.

    Windows Server 2003 and Windows XP:  The LOAD_LIBRARY_SEARCH flags are not supported.

    The directories that are searched depend on the flags specified with SetDefaultDllDirectoriesor LoadLibraryEx. If more than one flag is used, the corresponding directories are searched in the following order:

    1. The directory that contains the DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR). This directory is searched only for dependencies of the DLL to be loaded.
    2. The application directory (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
    3. Paths explicitly added with the AddDllDirectory function (LOAD_LIBRARY_SEARCH_USER_DIRS) or the SetDllDirectory function. If more than one path has been added, the order in which the paths are searched is unspecified.
    4. The System directory (LOAD_LIBRARY_SEARCH_SYSTEM32).

    If the application does not call LoadLibraryEx with any LOAD_LIBRARY_SEARCH flags or establish a DLL search order for the process, the system searches for DLLs using either the standard search order or the alternate search order.

    Related topics

    AddDllDirectory
    Application Registration
    Dynamic-Link Library Redirection
    Dynamic-Link Library Security
    LoadLibrary
    LoadLibraryEx
    LoadPackagedLibrary
    SetDefaultDllDirectories
    SetDllDirectory

    ---恢复内容结束---

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

    A system can contain multiple versions of the same dynamic-link library (DLL).

    Applications can control the location from which a DLL is loaded by specifying a full path or

    using another mechanism such as a manifest.

    If these methods are not used, the system searches for the DLL at load time as described in this topic. 

    • Factors That Affect Searching
    • Search Order for Windows Store apps
      • Standard Search Order for Windows Store apps
      • Alternate Search Order for Windows Store apps
    • Search Order for Desktop Applications
      • Standard Search Order for Desktop Applications
      • Alternate Search Order for Desktop Applications
      • Search Order Using LOAD_LIBRARY_SEARCH Flags
    • Related topics

    Factors That Affect Searching

    The following factors affect whether the system searches for a DLL:

    • If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
    • If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any) instead of searching for the DLL. For a list of known DLLs on the current system, see the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs.
    • If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

     Search Order for Windows Store apps

    When a Windows Store app loads a packaged module by calling the LoadPackagedLibraryfunction, the DLL must be in the package dependency graph of the process. For more information, see LoadPackagedLibrary. When a Windows Store app loads a module by other means and does not specify a full path, the system searches for the DLL and its dependencies at load time as described in this section.

    Windows 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP:  Windows Store apps are supported starting with Windows 8 and Windows Server 2012.

    Before the system searches for a DLL, it checks the following:

    • If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
    • If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any). The system does not search for the DLL. For a list of known DLLs on the current system, see the following registry key:HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs.

    If the system must search for a module or its dependencies, it always uses the search order for Windows Store apps even if a dependency is not Windows Store app code.

    Standard Search Order for Windows Store apps

    If the module is not already loaded or on the list of known DLLs, the system searches these locations in this order:

    1. The package dependency graph of the process. This is the application's package plus any dependencies specified as <PackageDependency> in the <Dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.
    2. The directory the calling process was loaded from.
    3. The system directory (%SystemRoot%system32).

    If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

    Alternate Search Order for Windows Store apps

    If a module changes the standard search order by calling the LoadLibraryEx function withLOAD_WITH_ALTERED_SEARCH_PATH, the system searches the directory the specified module was loaded from instead of the directory of the calling process. The system searches these locations in this order:

    1. The package dependency graph of the process. This is the application's package plus any dependencies specified as <PackageDependency> in the <Dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.
    2. The directory the specified module was loaded from.
    3. The system directory (%SystemRoot%system32).

    Search Order for Desktop Applications

    Desktop applications can control the location from which a DLL is loaded by specifying a full path, using DLL redirection, or by using a manifest. If none of these methods are used, the system searches for the DLL at load time as described in this section.

    Before the system searches for a DLL, it checks the following:

    • If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
    • If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any). The system does not search for the DLL. For a list of known DLLs on the current system, see the following registry key:HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs.

    If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

    Important  If an attacker gains control of one of the directories that is searched, it can place a malicious copy of the DLL in that directory. For ways to help prevent such attacks, see Dynamic-Link Library Security.

    Standard Search Order for Desktop Applications

    The standard DLL search order used by the system depends on whether safe DLL search mode is enabled or disabled. Safe DLL search mode places the user's current directory later in the search order.

    Safe DLL search mode is enabled by default. To disable this feature, create theHKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerSafeDllSearchMode registry value and set it to 0. Calling the SetDllDirectoryfunction effectively disables SafeDllSearchMode while the specified directory is in the search path and changes the search order as described in this topic.

    Windows XP:  Safe DLL search mode is disabled by default. To enable this feature, create theSafeDllSearchMode registry value and set it to 1. Safe DLL search mode is enabled by default starting with Windows XP with Service Pack 2 (SP2).

    If SafeDllSearchMode is enabled, the search order is as follows:

    1. The directory from which the application loaded.
    2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    5. The current directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    If SafeDllSearchMode is disabled, the search order is as follows:

    1. The directory from which the application loaded.
    2. The current directory.
    3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    Alternate Search Order for Desktop Applications

    The standard search order used by the system can be changed by calling the LoadLibraryExfunction with LOAD_WITH_ALTERED_SEARCH_PATH. The standard search order can also be changed by calling the SetDllDirectory function.

    Windows XP:  Changing the standard search order by calling SetDllDirectory is not supported until Windows XP with Service Pack 1 (SP1).

    If you specify an alternate search strategy, its behavior continues until all associated executable modules have been located. After the system starts processing DLL initialization routines, the system reverts to the standard search strategy.

    The LoadLibraryEx function supports an alternate search order if the call specifiesLOAD_WITH_ALTERED_SEARCH_PATH and the lpFileName parameter specifies an absolute path.

    Note that the standard search strategy and the alternate search strategy specified byLoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH differ in just one way: The standard search begins in the calling application's directory, and the alternate search begins in the directory of the executable module that LoadLibraryEx is loading.

    If SafeDllSearchMode is enabled, the alternate search order is as follows:

    1. The directory specified by lpFileName.
    2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    5. The current directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    If SafeDllSearchMode is disabled, the alternate search order is as follows:

    1. The directory specified by lpFileName.
    2. The current directory.
    3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
    4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    The SetDllDirectory function supports an alternate search order if the lpPathName parameter specifies a path. The alternate search order is as follows:

    1. The directory from which the application loaded.
    2. The directory specified by the lpPathName parameter of SetDllDirectory.
    3. The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
    4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
    5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    If the lpPathName parameter is an empty string, the call removes the current directory from the search order.

    SetDllDirectory effectively disables safe DLL search mode while the specified directory is in the search path. To restore safe DLL search mode based on the SafeDllSearchMode registry value and restore the current directory to the search order, call SetDllDirectory with lpPathName as NULL.

    Search Order Using LOAD_LIBRARY_SEARCH Flags

    An application can specify a search order by using one or more LOAD_LIBRARY_SEARCH flags with the LoadLibraryEx function. An application can also use LOAD_LIBRARY_SEARCH flags with the SetDefaultDllDirectories function to establish a DLL search order for a process. The application can specify additional directories for the process DLL search order by using theAddDllDirectory or SetDllDirectory functions.

    Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008:  TheLOAD_LIBRARY_SEARCH flags are available on systems with KB2533623 installed.

    Windows Server 2003 and Windows XP:  The LOAD_LIBRARY_SEARCH flags are not supported.

    The directories that are searched depend on the flags specified with SetDefaultDllDirectoriesor LoadLibraryEx. If more than one flag is used, the corresponding directories are searched in the following order:

    1. The directory that contains the DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR). This directory is searched only for dependencies of the DLL to be loaded.
    2. The application directory (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
    3. Paths explicitly added with the AddDllDirectory function (LOAD_LIBRARY_SEARCH_USER_DIRS) or the SetDllDirectory function. If more than one path has been added, the order in which the paths are searched is unspecified.
    4. The System directory (LOAD_LIBRARY_SEARCH_SYSTEM32).

    If the application does not call LoadLibraryEx with any LOAD_LIBRARY_SEARCH flags or establish a DLL search order for the process, the system searches for DLLs using either the standard search order or the alternate search order.

    Related topics

    AddDllDirectory
    Application Registration
    Dynamic-Link Library Redirection
    Dynamic-Link Library Security
    LoadLibrary
    LoadLibraryEx
    LoadPackagedLibrary
    SetDefaultDllDirectories
    SetDllDirectory

    Dynamic-Link Library Redirection

    Applications can depend on a specific version of a shared DLL and

    start to fail if another application is installed with a newer or older version of the same DLL.

    There are two ways to ensure that your application uses the correct DLL:

    DLL redirection and side-by-side components.

    Developers and administrators should use DLL redirection for existing applications,

    because it does not require any changes to the application.

    If you are creating a new application or updating an application

    and want to isolate your application from potential problems, create a side-by-side component.

    To use DLL redirection, create a redirection file for your application.

    The redirection file must be named as follows: 

    App_name.local

    For example, if the application name is Editor.exe, the redirection file should be named Editor.exe.local.

    You must install the .local file in the application directory.

    You must also install the DLLs in the application directory.

    The contents of a redirection file are ignored,

    but its presence causes Windows to check the application directory first whenever it loads a DLL,

    regardless of the path specified to LoadLibrary orLoadLibraryEx.

    If the DLL is not found in the application directory, then these functions use their usual search order.

    For example, if the application

    c:myappmyapp.exe

    calls LoadLibrary using the following path:

    c:program filescommon filessystemmydll.dll

    And, if both

    c:myappmyapp.exe.local and c:myappmydll.dll

    exist, LoadLibrary loads c:myappmydll.dll.

    Otherwise, LoadLibrary loads c:program filescommon filessystemmydll.dll.

    Alternatively, if a directory named

    c:myappmyapp.exe.local

    exists and contains mydll.dll, LoadLibrary loads

    c:myappmyapp.exe.localmydll.dll

    Known DLLs cannot be redirected.

    For a list of known DLLs, see the following registry key: 

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs

    The system uses Windows File Protection to ensure that system DLLs such as these are not updated or deleted

    except by operating system updates such as service packs.

    If the application has a manifest, then any .local files are ignored.

    If you are using DLL redirection and the application does not have access to all drives and directories in the search order, 

    LoadLibrary stops searching as soon as access is denied.

    (If you are not using DLL redirection, LoadLibrary skips directories that it cannot access and then continues searching.)

    It is good practice to install application DLLs in the same directory that contains the application,

    even if you are not using DLL redirection.

    This ensures that installing the application does not overwrite other copies of the DLL

    and cause other applications to fail.

    Also, if you follow this good practice, other applications do not overwrite your copy of the DLL

    and cause your application to fail.

    Windows 7: Running application using App Paths vs Batch File

    I have an (PowerBuilder) application (let's call it MyApp.exe) in a folder with a sub-directory that has all the required dlls.

    I am able to run this application, by adding the application path and associated path variable to Windows App Paths registry key.

    [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionApp PathsMyApp.EXE]
"Path"="C:\Prog32\MyAPP;C:\Prog32\MyAPP\DLL\;"
@="C:\Prog32\MyApp\MyApp.EXE"

    The above runs file. I didn't even have to register DLLs.

    If possible, I would like to run it using a batch file though,

    as users may install multiple versions of the same application in separate folders.

    When I tried to do the same thing in a batch file, it cannot find the DLLs.

    @SETLOCAL
SET CURDIR=%~dp0
CD %CURDIR%
PUSHD %CURDIR%

SET PATH=%CURDIR%;%CURDIR%dll;%PATH%
start "" %CURDIR%myApp.exe
POPD

ENDLOCAL

    I created this batch in the same directory as the executable, MyApp.exe.

    I was expecting it would find the DLLs, same way App Paths PATH setting did.

    The Batch file errors out not being able to find the DLLs.

    Do we need to register DLLs in this case?

    Why is it treated differently?

    Notes:

    1. If I copied all the required DLLs to the same directory as the executable
      (without a DLL sub-directory), it runs fine without needing to worry about PATH or registering dlls.

    2. We used to use installShield to install before, but admins have automated scripts to copy files,
      they shied away from InstallShield programs after the first install.
      I am trying to refine the process, so what they copy will be simplified.

    Thanks in advance for all your valuable comments and suggestions.-Sam

    Because Windows is a mess when searching for libraries. See

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx#search_order_for_desktop_applications

    There are many elements to how the search order is determined, but in general it is like this

    Check for the library...

    1. already loaded in memory
    2. on the KnownDLL list
    3. in the application's directory
    4. in the System directory
    5. in the 16-bit System directory
    6. in the Windows directory
    7. in the current working directory
    8. in the directories listed in the PATH environment variable

    Overall I would agree with what MSDN states on their DLL Redirection page

    It is good practice to install application DLLs in the same directory that contains the application

    However, if using sub-folders is how you want to organize your application, you might take a look into using Application Manifests.

    Something else to try would be to set the library directory as the working directory

    @ECHO off
SETLOCAL
SET "CURDIR=%~dp0"
PUSHD "%CURDIR%dll"
start "" /D "%CURDIR%dll" "%CURDIR%myApp.exe"
POPD
ENDLOCAL

    Application Registration

    This topic discusses how applications can expose information about themselves necessary to enable certain scenarios. This includes information needed to locate the application, the verbs that the application supports and the types of files that an application can handle.

    This topic is organized as follows:

    • Finding an Application Executable
    • Registering Applications
      • Using the App Paths Subkey
      • Using the Applications Subkey
    • Registering Verbs and Other File Association Information
    • Registering a Perceived Type
    • Related topics

    Note  Applications can also be registered in the Set Program Access and Computer Defaults (SPAD) and Set Your Default Programs (SYDP) control panel applications. For information about SPAD and SYDP application registration, see Guidelines for File Associations and Default Programs, and Set Program Access and Computer Defaults (SPAD).

    Finding an Application Executable

    When the ShellExecuteEx function is called with the name of an executable file in its lpFileparameter, there are several places where the function looks for the file. We recommend registering your application in the App Paths registry subkey. Doing so avoids the need for applications to modify the system PATH environment variable.

    The file is sought in the following locations:

    • The current working directory.
    • The Windows directory only (no subdirectories are searched).
    • The WindowsSystem32 directory.
    • Directories listed in the PATH environment variable.
    • Recommended:HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

    Registering Applications

    Both the App Paths and Applications registry subkeys are used to register and control the behavior of the system on behalf of applications. The App Paths subkey is the preferred location.

    Using the App Paths Subkey

    In Windows 7 and later, we strongly recommend you install applications per user rather than per machine. An application that is installed for per user can be registered underHKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionApp Paths. An application that is installed for all users of the computer can be registered underHKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionApp Paths.

    The entries found under App Paths are used primarily for the following purposes:

    • To map an application's executable file name to that file's fully qualified path.
    • To pre-pend information to the PATH environment variable on a per-application, per-process basis.

    If the name of a subkey of App Paths matches the file name, the Shell performs two actions:

    • The (Default) entry is used as the file's fully qualified path.
    • The Path entry for that subkey is pre-pended to the PATH environment variable of that process. If this is not required, the Path value can be omitted.

    Potential issues to be aware of include:

    • The Shell limits the length of a command line to MAX_PATH * 2 characters. If there are many files listed as registry entries or their paths are long, file names later in the list could be lost as the command line is truncated.
    • Some applications do not accept multiple file names in a command line.
    • Some applications that accept multiple file names do not recognize the format in which the Shell provides them. The Shell provides the parameter list as a quoted string, but some applications might require strings without quotes.
    • Not all items that can be dragged are part of the file system; for example, printers. These items do not have a standard Win32 path, so there is no way to provide a meaningfullpParameters value to ShellExecuteEx.

    Using the DropTarget entry avoids these potential issues by providing access to all of the clipboard formats, including CFSTR_SHELLIDLIST (for long file lists) and CFSTR_FILECONTENTS(for non-file-system objects).

    To register and control the behavior of your applications with the App Paths subkey:

    1. Add a subkey with the same name as your executable file to the App Paths subkey, as shown in the following registry entry. 
      HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER
   SOFTWARE
      Microsoft
         Windows
            CurrentVersion
               App Paths
                  file.exe
                     (Default)
                     DontUseDesktopChangeRouter
                     DropTarget
                     Path
                     UseUrl
    2. See the following table for details of the App Paths subkey entries.
      Registry entryDetails
      (Default) Is the fully qualified path to the application. The application name provided in the (Default) entry can be stated with or without its .exe extension. If necessary, the ShellExecuteExfunction adds the extension when searching App Pathssubkey. The entry is of the REG_SZ type.
      DontUseDesktopChangeRouter Is mandatory for debugger applications to avoid file dialog deadlocks when debugging the Windows Explorer process. Setting the DontUseDesktopChangeRouter entry produces a slightly less efficient handling of the change notifications, however. The entry is of the REG_DWORD type and the value is 0x1.
      DropTarget Is a class identifier (CLSID). The DropTarget entry contains the CLSID of an object (usually a local server rather than an in-process server) that implements IDropTarget. By default, when the drop target is an executable file, and no DropTarget value is provided, the Shell converts the list of dropped files into a command-line parameter and passes it to ShellExecuteEx through lpParameters.
      Path Supplies a string (in the form of a semicolon-separated list of directories) to append to the PATH environment variable when an application is launched by calling ShellExecuteEx. It is the fully qualified path to the .exe. It is of REG_SZ. InWindows 7 and later, the type can be REG_EXPAND_SZ, and is commonly REG_EXPAND_SZ %ProgramFiles%.

      Note  In addition to the (Default), Path, and DropTarget entries recognized by the Shell, an application can also add custom values to its executable file's App Paths subkey. We encourage application developers to use the App Pathssubkey to provide an application-specific path instead of making additions to the global system path.
      UseUrl

      Indicates that your application can accept a URL (instead of a file name) on the command line. Applications that can open documents directly from the internet, like web browsers and media players, should set this entry.

      When the ShellExecuteEx function starts an application and the UseUrl=1 value is not set, ShellExecuteEx downloads the document to a local file and invokes the handler on the local copy.

      For example, if the application has this entry set and a user right-clicks on a file stored on a web server, the Open verb will be made available. If not, the user will have to download the file and open the local copy.

      The UseUrl entry is of REG_DWORD type, and the value is 0x1.

      In Windows Vista and earlier, this entry indicated that the URL should be passed to the application along with a local file name, when called via ShellExecuteEx. In Windows 7, it indicates that the application can understand any http or https url that is passed to it, without having to supply the cache file name as well. The registry key SupportedProtocols contains multiple registry values to indicate which URL schemes are supported.

    Using the Applications Subkey

    Through the inclusion of registry entries under theHKEY_CLASSES_ROOTApplicationsApplicationName.exe subkey, applications can provide the application-specific information shown in the following table.

    Registry entryDescription
    shellverb Provides the verb method for calling the application from OpenWith. Without a verb definition specified here, the system assumes that the application supportsCreateProcess, and passes the file name on the command line. This functionality applies to all the verb methods, including DropTarget, ExecuteCommand, and Dynamic Data Exchange (DDE).
    DefaultIcon Enables an application to provide a specific icon to represent the application instead of the first icon stored in the .exe file.
    FriendlyAppName Provides a way to get a localizable name to display for an application instead of just the version information appearing, which may not be localizable. The association query ASSOCSTR reads this registry entry value and falls back to use the FileDescription name in the version information. If that name is missing, the association query defaults to the display name of the file. Applications should useASSOCSTR_FRIENDLYAPPNAME to retrieve this information to obtain the proper behavior.
    SupportedTypes Lists the file types that the application supports. Doing so enables the application to be listed in the cascade menu of the Open with dialog box.
    NoOpenWith Indicates that no application is specified for opening this file type. Be aware that if an OpenWithProgIDs subkey has been set for an application by file type, and the ProgID subkey itself does not also have a NoOpenWith entry, that application will appear in the list of recommended or available applications even if it has specified the NoOpenWith entry.

    For more information, see How to How to Include an Application in the Open With Dialog Box and How to exclude an Application from the Open with Dialog Box.
    IsHostApp Indicates that the process is a host process, such as Rundll32.exe or Dllhost.exe, and should not be considered for Start menu pinning or inclusion in the Most Frequently Used (MFU) list. When launched with a shortcut that contains a non-null argument list or an explicit Application User Model IDs (AppUserModelIDs), the process can be pinned (as that shortcut). Such shortcuts are candidates for inclusion in the MFU list.
    NoStartPage Indicates that the application executable and shortcuts should be excluded from the Start menu and from pinning or inclusion in the MFU list. This entry is typically used to exclude system tools, installers and uninstallers, and readme files.
    UseExecutableForTaskbarGroupIcon Causes the taskbar to use the default icon of this executable if there is no pinnable shortcut for this application, and instead of the icon of the window that was first encountered.
    TaskbarGroupIcon Specifies the icon used to override the taskbar icon. The window icon is normally used for the taskbar. Setting the TaskbarGroupIcon entry causes the system to use the icon from the .exe for the application instead.

    Examples

    Some examples of application registrations through theHKEY_CLASSES_ROOTApplicationsApplicationName.exe subkey are as follows. All registry entry values are of REG_SZ type, with the exception of DefaultIcon which is ofREG_EXPAND_SZ type.

    HKEY_CLASSES_ROOT
   Applications
      wordpad.exe
         FriendlyAppName = @%SystemRoot%System32shell32.dll,-22069
    HKEY_CLASSES_ROOT
   Applications
      wmplayer.exe
         SupportedTypes
            .3gp2
    HKEY_CLASSES_ROOT
   Applications
      wmplayer.exe
         DefaultIcon
            (Default) = %SystemRoot%system32wmploc.dll,-730
    HKEY_CLASSES_ROOT
   Applications
      WScript.exe
         NoOpenWith
    HKEY_CLASSES_ROOT
   Applications
      photoviewer.dll
         shell
            open
               DropTarget
                  Clsid = {FFE2A43C-56B9-4bf5-9A79-CC6D4285608A}
    HKEY_CLASSES_ROOT
   Applications
      mspaint.exe
         SupportedTypes
            .bmp
            .dib
            .rle
            .jpg
            .jpeg
            .jpe
            .jfif
            .gif
            .emf
            .wmf
            .tif
            .tiff
            .png
            .ico

    Registering Verbs and Other File Association Information

    Subkeys registered under HKEY_CLASSES_ROOTSystemFileAssociations enable the Shell to define the default behavior of attributes for file types and enable shared file associations. When users change the default application for a file type, the ProgID of the new default application has priority in providing verbs and other association information. This priority is due to it being the first entry in the association array. If the default program is changed, the information under the previous ProgID is no longer available.

    To deal proactively with the consequences of a change to default programs, you can useHKEY_CLASSES_ROOTSystemFileAssociations to register verbs and other association information. Due to their location after the ProgID in the association array, these registrations are lower priority. These SystemFileAssociationsregistrations are stable even when users change the default programs, and provide a location to register secondary verbs that will always be available for a particular file type. For a registry example, see Registering a Perceived Type later in this topic.

    The following registry example shows what happens when the user runs the Default Programsitem in Control Panel to change the default for .mp3 files to App2ProgID. After changing the default, Verb1 is no longer available, and Verb2 becomes the default.

    HKEY_CLASSES_ROOT
   .mp3
      (Default) = App1ProgID
    HKEY_CLASSES_ROOT
   App1ProgID
      shell
         Verb1
    HKEY_CLASSES_ROOT
   App2ProgID
      shell
         Verb2

    Registering a Perceived Type

    Registry values for perceived types are defined as subkeys of theHKEY_CLASSES_ROOTSystemFileAssociations registry subkey. For example, the perceived type text is registered as follows:

    HKEY_CLASSES_ROOT
   SystemFileAssociations
      text
         shell
            edit
               command
                  (Default) = "%SystemRoot%system32NOTEPAD.EXE" "%1"
            open
               command
                  (Default) = "%SystemRoot%system32NOTEPAD.EXE" "%1"

    A file type's perceived type is indicated by including a PerceivedType value in the file type's subkey. The PerceivedType value is set to the name of the perceived type registered underHKEY_CLASSES_ROOTSystemFileAssociations registry subkey, as shown in the previous registry example. To declare .cpp files as being of perceived type "text", for example, add the following registry entry:

    HKEY_CLASSES_ROOT
   .cpp
      PerceivedType = text

    Related topics

    File Types
    How File Associations Work
    Content View By File Type or Kind
    File Type Verifier
    File Type Handlers
    Programmatic Identifiers
    Perceived Types
    Association Arrays

    LoadLibrary unable to load a library even when given a full path

     I tried to load a C++ DLL from a C++ application using LoadLibrary.
     
    I gave it the full path but it couldn't find the DLL (and obviously, the DLL is found where I said it is if a person looks for it using Windows Explorer).
     
    Eventually, the only way I got my application to find the said DLL was to put the application in the same folder as the DLL.
     
    <Rhetorical>
    So what's the point of writing the full path then!?
    </Rhetorical>
     
    How can this happen, and what can I do to solve this problem?
    I really would rather not have to put the application in the same folder as the DLL. 

    Also, COM DLLs in the same folder as the DLL in question cannot find the DLL either.
    I suppose the COM doesn't have a strong enough idea as to where it is located with respect to other modules.

    ...
HMODULE hmDLL = LoadLibrary(_T("C:\MyPath\MyDLL.dll"));
DWORD dwError = 0;
if(NULL == hmDLL)
{
    dwError = GetLastError();
}
// break here and inspect dwError
// -> find out dwError = 0x7e
...

    After reading the first 4 solutions, here's some information to help you...it has to do with the DLL Search Path [^].
     
    As the article says, the typical search order is

    1.The directory from which the application loaded.
2.The current directory. 
3.The system directory. Use the GetSystemDirectory function to get the path of this directory. 
4.The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6.The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. 
    The App Paths key is not used when computing the DLL search path.

    So, as you see, it looks in the app directory first, and in your case, didn't find it. Then it looks in the current directory - but still didn't find it, and so on.
     
    Since you gave the full path, it probably found your NAMED DLL, but couldn't find the dependency DLLs becuase if follows the DLL Search algorithm.
     
    However, if you put your EXE in the DLL directory (not generally a good idea) it finds your DLL and all the dependencies (becuse the directory from which the app loaded contains all the needed DLLs).
     
    If you put your dll in the app directory, it finds it, but not the dependent DLLs.
     
    Hope this helps you - be sure to read the entire article.

    Application Specific Paths for DLL Loading

    Configuring workstations to handle shared DLLs is difficult.

    In many organizations, the PATH environment becomes a point of contention between project teams.

    Configuring a PATH specific to your application can solve the problems associated with using a common search PATH,

    and eliminate many configuration errors in your application as well.

    This article first describes the current methods of application configuration and the problems associated with them.

    Finally, the specific details of adding an application specific path in the registry are described.

    The solution is compatible with both NT and '95.

    As many of you already know, and as the Visual C++ documentation illustrates,

    the operating system will use the following algorithm for locating a DLL. (Load Visual C++ help on LoadLibrary()).

    1. The directory where the executable module for the current process is located.
    2. The current directory.
    3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
    4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
    5. The directories listed in the PATH environment variable. 

    Now, imagine the following situation in which two applications (ONE.EXE and TWO.EXE)

    need to share a common DLL (COMMON.DLL).

    The applications install the files into the following directories.

    Application 1 Application 2
    C:Program FilesONEONE.exe C:Program FilesTWOTWO.exe
    C:Program FilesCommonCOMMON.DLL C:Program FilesCommonCOMMON.DLL

    There are several ways to configure the machine using the above search algorithm.

    1) Put all applications into a single directory

    Hmm, one big directory. Sounds great until you need to remove one application,

    and can't figure out which files to delete. While your at it, why not just make one big .EXE file?

    2) Modify the current directory

    Faced with the above problems, many programs were configured to be started with the current directory pointing to the DLL.

    This is easily set in the short-cut which starts the application.

    While this gives each program control of the DLLs that it loads, it also has several side effects:

    1. Any documents written will be written to the DLL location.
    2. File Open dialogs start out in the DLL location.
    3. Programmatically changing the current directory may cause future DLL loads to fail.
    4. It's difficult to control current directory if one program invokes another.

    3) Put common files into the Windows or System directory

    Many applications store DLLs in the Windows or System directory.

    This creates a maintenance problem, particularly if the system files need to be replaced.

    Many organizations have begun locking down the Windows and System directories, in an effort to reduce maintenance costs.

    4) Modify the PATH environment variable

    Certainly the most straight forward approach is to have C:Program FilesCommon added to the path.

    This was how things were done in the Win 3.1 days. There are several problems:

    1. If the workstation includes several applications, the PATH becomes incredibly long.
    2. The order in which directories appear on the path becomes important.
    3. The system spends a great deal of time searching directories that are never used by the application.
    4. The program cannot determine which location is used to load a DLL.
    5. Installation programs require re-boots for the path changes to take effect.

    Finally, Application Specific Paths!

    Microsoft has offered a solution to all these problems.

    Each application can now store it own path the registry under the following key:

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths

    The use the application path, set a key for your application, using ONE.EXE from the example above:

    HKEY_LOCAL_MACHINE...CurrentVersionApp PathsONE.exe

    Set the (Default) value to the full path of your executable, for example:

    C:Program FilesONEONE.exe

    Add a sub-key named Path, set it's value to the full path of the DLL, for example:

    C:Program FilesCommon

    With an App Path registry entry, the system will load DLLs in the following order.

    1. The directories listed in the App Path registry key
    2. The directory where the executable module for the current process is located.
    3. The current directory.
    4. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
    5. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
    6. The directories listed in the PATH environment variable.

    Run REGEDIT to see examples of other applications, and how they setup their App Path keys.
  • 相关阅读:
    shell变量解析
    visual studio code（vscode）使用
    linux虚拟机安装
    算法总结系列之八:复读机的故事散列表及其在.NET中的应用浅析(上集)
    对改善Dictionary时间性能的思考及一个线程安全的Dictionary实现
    算法总结系列之八:复读机的故事 散列表.NET应用的研究(下集)
    使用WiX打包你的应用程序之二向WiX脚本传递信息(属性)的几种方式
    当心Dictionary带来的一种隐式内存泄漏
    从DWG到XAML (II) DWFx格式解析及其和XPS的关系
    从DWG到XAML (I) 浅谈DWG历史,现状及方向
  • 原文地址：https://www.cnblogs.com/shangdawei/p/4056967.html
Copyright © 2020-2023  润新知