LoadLibraryA vs LoadLibrary

[ctrueden]

The ImageJ Launcher's Windows implementation of dlopen uses LoadLibraryA #if WIN32, and LoadLibrary #if defined(WIN32). Firstly: what's the difference in these cases? Secondly, should Jaunch pattern its dlopen/dlsym/dlerror functions more closely after the ImageJ Launcher?

[mkitti]

LoadLibrary is a macro alias for either LoadLibraryA or LoadLibraryW.
https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya

The libloaderapi.h header defines LoadLibrary as an alias which automatically selects the ANSI or Unicode version of this function based on the definition of the UNICODE preprocessor constant.

The Unicode counterpart of LoadLibraryA is LoadLibraryW. We probably want to support LoadLibraryW if possible to support internationalization.

There are also LoadLibaryExA and LoadLibraryExW. These accept an additional flag argument that can be used to modify the search path. See the following about the possibilities for configuring the Windows search path:
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

In particularly find the LOAD_LIBRARY_SEARCH_USER_DIRS interesting. This allows for the use of AddDllDirectory that can be used to build a set of directories to search, perhap similar to the *NIX method of using LD_LIBRARY_PATH.

[mkitti]

LOAD_WITH_ALTERED_SEARCH_PATH is another interesting option. It makes the following modification.

If a module changes the standard search order by calling the LoadLibraryEx function with LOAD_WITH_ALTERED_SEARCH_PATH, then the search order is the same as the standard search order except that in step 7 the system searches the folder that the specified module was loaded from (the top-loading module's folder) instead of the executable's folder.

[marktsuchida]

The Unicode counterpart of LoadLibraryA is LoadLibraryW. We probably want to support LoadLibraryW if possible to support internationalization.

Note that "Unicode" or W in Win32 refers to UTF-16. With recent versions of Windows 10 (since 2019 I think), the /utf-8 compiler option can be used to set the "multibyte" (A) encoding to UTF-8. Then LoadLibraryA will work with non-ASCII text (and I would hope it would also work on older Windows versions as long as the DLL name/path is ASCII-only, though I've never tested this).

LoadLibraryA #if WIN32, and LoadLibrary #if defined(WIN32)

This is probably a bug (which would only manifest if compiled in "Unicode" mode, which perhaps never happened). #if WIN32 is true if WIN32 is defined and nonzero; #if defined(WIN32) (same as #ifdef WIN32) would be true even if defined to zero, but nobody should define WIN32 to zero, so they were probably equivalent. Also note that WIN32 is not defined by the platform headers or the compiler -- it is a conventional macro defined by Visual Studio's project templates, and some projects use it even if not building with Visual Studio. _WIN32 is defined by the compiler and might be a better choice for this kind of thing.