load .dll in visual studio project

[Cplusc]

Hello,
I need to load a dynamic library in my visual studio project and I wrote the following code for this purpose,

HINSTANCE hInst = LoadLibrary(L"D:\\Library\\MyDll.dll");
	if (!hInst)
	{
		std::cout << "\nCould Not Load the Library";
		return EXIT_FAILURE;
	}

Now I have two problems, First I can't load the dll file and second how I can load several .dll file at once.
Bests,

[deleted account xyzzy]

Try with the DLL in the directory where you launch the executable that wants to use the DLL. If your DLL still doesn't load then it might be how your built your DLL.

You want to load multiple DLLs? Use multiple instances of LoadLibrary, one for each DLL to load.

Of course you need to check each was loaded before you can use them.

[Ganado]

https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

[Cplusc]

@ George P
Thanks for the answer, but I tried the first solution before asking this question and it didn't work. I am not building the dll files, I am just using them in my project. I just don't get one thing clearly. Is that correct to say That the purpose of using dynamics library is to take les memory than statics library in run time. If it is so, why some libraries give both .lib and .dll and in other to use them in your projects you need to both include the statics library and also load the dynamics library. I think the problem may arise because of _DEBUG or _NDEBUG mode in preprocessors. I think maybe the library is built when some macro definition is there, for example ndebug. I am not sure, but I guess so.

[Cplusc]

@Gaunado
Thanks for your response

[thmm]

Yes .dll can save memory, because they will be loaded when needed and unloaded when not longer needed. Static libraries will be linked with the .exe and will always be in memory.
Dynamic linking makes updating apps easier.
Imagine you have an app.exe and a app.dll. If you need to change the code in app.dll you need only to recompile and distribute app.dll.
It the code you need to change would be in a app.lib you would need to recompile app.lib and app.exe.

Back to the original problem. What error code did GetLastError() return ?

[kigar64551]

Keep in mind that even if you load a DLL via LoadLibrary() with an absolute path, then that DLL can have further DLL dependencies! Those "recursive" DLL dependencies will not be loaded from the directory where the DLL you specified (by absolute path) is located, but the Standard DLL Search Order applies:

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications

Cplusc wrote:

If it is so, why some libraries give both .lib and .dll and in other to use them in your projects you need to both include the statics library and also load the dynamics library

The .lib file that comes together with a DLL is the so-called import library for that DLL. If you use implicit DLL loading, then the .lib file needs to be linked into your EXE file, at link-time, and the operating system's loader then takes care of loading the corresponding DLL file, at runtime. No LoadLibrary() needed!

Loading a DLL file via LoadLibrary() is called explicit DLL loading and does not use or require an import library (.lib file) at all. With explicit DLL loading you simply load the DLL file directly, at runtime.

(BTW: Static libraries also have a .lib file extensions, but still are different from import libraries for DLLs!)

[Cplusc]

@thmm
I add this line to the code DWORD lasterror = GetLastError(); but it doesn't give me anything

[Cplusc]

@kigar64551 Thanks for the good point

[kigar64551]

I add this line to the code DWORD lasterror = GetLastError(); but it doesn't give me anything

You have to call GetLastError() immediately after LoadLibrary() has failed. This gives you the Win32 error code. You'll have to print the error code in order to "see" it ;-)

HMODULE module = LoadLibrary(L"D:\\Library\\MyDll.dll");
if (!module )
{
    const DWORD errorCode = GetLastError();
    printf("LoadLibrary failed with error code 0x%X\n", errorCode);
}

See also:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/18d8fbe8-a967-4f1c-ae50-99ca8e491d2d

[Cplusc]

@kigar64551

LoadLibrary failed with error code 0x7E

[Ganado]

0x0000007E is ERROR_MOD_NOT_FOUND, "The specified module could not be found.", as seen in the link kigar posted.

The other point kigar made still stands: It might be that it can't find a dependency of that DLL (the error messages sometimes aren't very stellar). You should use a tool like Dependency Walker or Dependencies to open the DLL and see if it can't find particular dependent DLLs.

I have had success with: https://github.com/lucasg/Dependencies

https://stackoverflow.com/questions/16700810/loadlibraryexw-fails-last-error-is-error-mod-not-found-but-no-missing-depend
Raymond Chen suggests using loader snaps in the above link. I have actually never done this, but the page above gives details if you want to explore it on your own.

[Cplusc]

#ifdef NDEBUG 

	HINSTANCE hInst = LoadLibrary(L"D:\\Library\\MyDll.dll");
	HMODULE module = LoadLibrary(L"D:\\Library\\MyDll.dll");
	if (!module)
	{
		const DWORD errorCode = GetLastError();
		printf("LoadLibrary failed with error code 0x%X\n", errorCode);

	}

#endif 

I think now it's loaded.

(process 17376) exited with code 0

[kigar64551]

As far as I can tell, you are now loading the same DLL twice. This doesn't really make any sense, even though it is not forbidden (LoadLibrary uses ref counting). This certainly is not what fixed your problem....

BTW: The return type of LoadLibrary() is HMODULE. But, because on modern Windows, HMODULE is an alias for HINSTANCE, both types can be used interchangeably. It makes no difference which type you use!

BTW²: Are you sure NDEBUG is defined? Otherwise your #ifdef'ed code is disabled and does nothing :-D

[Cplusc]

@kigar64551
I think NDEBUG fixed the bug. I am not completely sure but I think this has something to do with compilation time in DEBUG configuration or RELEASE configuration.

[kigar64551]

Yeah, disabling the code with #ifdef directives, so that it does nothing, kind of "fixes" the problem.

If we don't even try to load the DLL, it won't fail ;-)

Note: Unless NDEBUG is defined, any source code in between "#ifdef NDEBUG" and "#endif" is just disabled!

(And, apparently, in your configuration, NDEBUG is not defined)

[deleted account xyzzy]

Dependencies has a limitation; if the executable or DLL being checked for dependencies has any dynamic loading (i.e. LoadLibrary) that will NOT be reported.

Since the DLL in question is one that is pre-built knowing if it uses LoadLibrary for any dependency becomes hard to determine.

Dynamic loading of DLLs is definitely fraught with issues that don't exist with apps and DLLs that use import libraries for compile-time integration with the app using the DLL(s).

[kigar64551]

Dependencies has a limitation; if the executable or DLL being checked for dependencies has any dynamic loading (i.e. LoadLibrary) that will NOT be reported.

That's right. However, it will report those implicit DLL dependencies of a DLL file which matter at the moment when the DLL is loaded via LoadLibrary() and which may cause the ERROR_MOD_NOT_FOUND error.

After the DLL (and its implicit dependencies) have been loaded successfully, the code in the DLL gets a chance to run. Only then it may try to explicitly load further DLLs, by invoking LoadLibrary() once more...