Use of LoadLibraryExA with LOAD_WITH_ALTERED_SEARCH_PATH flag about dlfcn-win32 HOT 9 OPEN

Well, adding shlwapi to CMake target_link_libraries is not enough. It does not work for statically compiled library and also for library compiled by Makefile. In past there was similar linking issue with psapi.dll library which was resolved by removing this dependency at build time.

Anyway, I looked how is PathIsRelativeA() implemented (in ReactOS) and it is pretty simple:

/*************************************************************************
 * PathIsRelativeA	[SHLWAPI.@]
 *
 * Determine if a path is a relative path.
 *
 * PARAMS
 *  lpszPath [I] Path to check
 *
 * RETURNS
 *  TRUE:  The path is relative, or is invalid.
 *  FALSE: The path is not relative.
 */
BOOL WINAPI PathIsRelativeA (LPCSTR lpszPath)
{
  TRACE("(%s)\n",debugstr_a(lpszPath));

  if (!lpszPath || !*lpszPath || IsDBCSLeadByte(*lpszPath))
    return TRUE;
  if (*lpszPath == '\\' || (*lpszPath && lpszPath[1] == ':'))
    return FALSE;
  return TRUE;
}

If you remove all traces and conditions which are constant false, then you can write:

hModule = LoadLibraryExA(lpFileName, NULL, (lpFileName[0] == '\\' || (lpFileName[0] != '\0' && lpFileName[1] == ':')) ? 0 : LOAD_WITH_ALTERED_SEARCH_PATH);

And you do not need to use shlwapi at all.

from dlfcn-win32.

Thanks for the detailed bug report.

Thanks for the quick response. I just moved the info from A to B. @larskanis found the issue.

Actually the code is present since the initial commit

Sorry, I just saw the history of when it was moved, apparently didn't look at the patch well enough.

Both MSYS2 and vcpkg have packages based on this repo. This issue appeared while testing various Ruby Windows builds.

Lastly, haven't written any cmake code, so I thought an issue would be best.

from dlfcn-win32.

Thanks for the detailed bug report. For linking shlwapi we can link it via target_link_libraries or the CMake build system, and just document in the README for anyone else. However, I think that we can probably wait for @pali opinion as he originally wrote that part of the code .

from dlfcn-win32.

However, I think that we can probably wait for @pali opinion as he originally wrote that part of the code .

Actually the code is present since the initial commit of the library: 4c4b268#diff-b222daab7a869ff07e8988874a544fe19839599a3a20af7fa6752bf08d5d9271R134 .

from dlfcn-win32.

Thanks for investigating. I think the failing test added a folder with SetDllDirectoryA, then a filename (like mycode.dll) was passed to LoadLibraryExA. Not.Sure.

EDIT:

Is that backwards? Or, should it be:

hModule = LoadLibraryExA(lpFileName, NULL, (lpFileName[0] == '\\' || (lpFileName[0] != '\0' && lpFileName[1] == ':')) ? LOAD_WITH_ALTERED_SEARCH_PATH : 0);

from dlfcn-win32.

Documentation for LOAD_WITH_ALTERED_SEARCH_PATH says:

• If this value is used and lpFileName specifies an absolute path, the system uses the alternate file search strategy discussed in the Remarks section to find associated executable modules that the specified module causes to be loaded. If this value is used and lpFileName specifies a relative path, the behavior is undefined.
• If this value is not used, or if lpFileName does not specify a path, the system uses the standard search strategy discussed in the Remarks section to find associated executable modules that the specified module causes to be loaded.
• Note that the standard search strategy and the alternate search strategy specified by LoadLibraryEx 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.

There is a comment in dlfcn-win32 source code:

LOAD_WITH_ALTERED_SEARCH_PATH is used to make it behave more closely to UNIX's search paths (start with system folders instead of current folder).

But LOAD_WITH_ALTERED_SEARCH_PATH does not do for what it was intended (start with system folders instead of current folder).

So this just show the real issue, which is different.

And you are right, condition needs to be negated, I exchanged relative and absolute.

from dlfcn-win32.

condition needs to be negated

Been there, done that. A lot.

I tried the code, and the test failure no longer occurs.

Lastly, I think the above MSFT wording that you quoted is a mess. By 'or if lpFileName does not specify a path', do they mean that lpFileName is a file name? And 'the alternate search begins in the directory of the executable module that LoadLibraryEx is loading'. Is a dll an 'executable module', or are they actually referring to exe files?

Regardless, your patch fixes the issue. Thank you...

from dlfcn-win32.

MSFT wording that you quoted is a mess

Yes, this is normal.

By 'or if lpFileName does not specify a path', do they mean that lpFileName is a file name?

Based on context, I'm guessing that there is missing word absolute.

And 'the alternate search begins in the directory of the executable module that LoadLibraryEx is loading'. Is a dll an 'executable module', or are they actually referring to exe files?

My understanding is that 'executable module' is EXE, DLL or any other file which EXE or DLL reference as a dependency. And 'executable module that LoadLibraryEx is loading' I understand that is lpFileName.

Whole article is at https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

Regardless, your patch fixes the issue.

As I said in previous post, it does not fix this issue. This code change just change this issue to another one.

from dlfcn-win32.

@pali

This code change just change this issue to another one.

I think I just found the same...

Ruby has a few 'packages' that wrap libffi, most also use dlfcn. The change discussed here fixes one set of tests, but breaks another.

One test was using SetDllDirectoryA, and the fix here worked. Another test was loading a system file, and that test fails with the fix here. Hence, need to figure out how to make both tests sets pass. Thanks, it might take a few days...

from dlfcn-win32.