I need to load a dll within another dll (Visual C++ both), so I can use the classes embedded in the first one in the second. I have the code of both, since I created both dll's, but I have never dynamically loaded a library so I'm not sure how this is done...
Besides, I want to make this multi-platform, I already compiled both as .dll and .so, so it would be great a platform independent method to do this...otherwise, I can use macros to include windows or linux specific code.
Best regards and many thanks
The functions to load the library dynamically are: LoadLibrary (Windows), dlopen (Linux). To get the symbols: GetProcAddress (Windows), dlsym (LInux). Close the Open Library: FreeLibrary (Windows), dlclose(Linux). There is an article of how to load classes dynamically on windows: http://www.codeproject.com/KB/DLL/classesexportedusingLL.aspx and Linux: http://www.linuxjournal.com/article/3687?page=0,0. And there is code to load the libraries dynamically on windows and linux: http://www.sview.ru/sources/libexample/loadLibrary.h. I hope this could help you.
There is additional information about load classes dynamically on windows and linux:
http://www.codeguru.com/cpp/w-p/win32/article.php/c1443 (Windows).
http://www.faqs.org/docs/Linux-mini/C++-dlopen.html#loadingclasses (Linux).
Typically just compile and link the lowest-level DLL. That will create the DLL itself and a .LIB file. Compile and link the next DLL up the chain, linking against that .LIB file. Continue up the chain until you reach the .EXE that (typically) nothing else links against.
Related
I'm using MYSQL library, and libmysql.lib /.dll.
My program cannot be working without the libmysql.dll
When I'm trying to run my project without the dll I'm getting that error message.
What I'm basically want to do is to put that dll in my .exe file.
build the .exe file with that dll and make the program read it from himself.
I mean, give the program to people with that dll inside.
It is possible ?
I tried this section: embed DLL in MFC C++ EXE?
But the program still asking for the dll .. (But I do see that the size of the .exe has been changed) so that dll has been added.
But the program still asking for the libmysql.dll ..
All the point is to use it inside the .exe file..
thanks.
What you are asking for cannot be done if you statically link to the DLL at compile-time. You need to dynamically link to the DLL at run-time instead, either by explicit calls to LoadLibrary() and GetProcAddress() to access the DLL functions directly, or by utilizing your compiler's delay-load functionality (which uses LoadLibrary() and GetProcAddress() internally, but hides that fact from your code). Either way, you can then store the DLL in your EXE's resources at compile-time, then extract the resource to a temporary file at run-time and load/use it as needed (you can't use the DLL from inside the EXE's resources directly. Well, there is a way to do it, but it is a VERY complicated and advanced technique, as it requires implementing your own executable loader that basically mimics what the OS's built-in executable loader already does). When you are done using the DLL, you can unload it from memory and delete the temp file.
I am new to C++ programming. There are 2 libraries in my program, one needs to be linked dynamically, and the other needs to be linked statically, how can I set this up in Eclipse? I am using
Eclipse CDT + MinGW + Windows 7.
Thanks.
It's not entirely clear what you're after here.
Most of static vs. dynamic is in the library itself, not how you link to it. You can have a static library, which is basically just a collection of object files, stuffed together into a single file, with a directory to tell what parts were originally which files.
You can also have a DLL. When you create a DLL, the linker will normally also create a link library for that DLL. This library basically just contains stubs -- enough information so the linker can insert a link to the DLL into another DLL or executable.
When you use a DLL, you basically have three options for how to use it:
The most common case: the DLL will be loaded as the parent executable is loaded.
delayload: doesn't load that DLL until/unless you actually use a function from it (handy if you have, for example, a special DLL that's only used under, say, Windows Vista or newer).
Explicit dynamic linking. Here, you don't tell the linker about the DLL or an associated library at all. You call LoadLibrary and GetProcAddress to load the library, and get a callable function address.
This question is regarding dynamic linking of libraries and usage of dynamic linking of libraries in application.
For example we are devloping an application using C++ using Visual studio environment.
Here for include header files we specify in Additional Include Directories, and
in Additional Dependencies: Mylibrary.lib
in Additional Libraries Directories: We specifies path of libraries
And in Windows we also have "LoadLibrary" API which is used to load dynamically linked ibrary.
My question is
when we include dll in Additional dependencies libraries why we should use "LoadLibrary" API?
When we should use "LoadLibrary" API?
Thanks!
LoadLibrary lets you continue program execution if the dll is not on the running machine. It returns an error status that can be checked and execution can be continued.
Also, linking lets you do stuff like use classes from the other binary & others. LoadLibrary only lets you find functions via GetProcAddress.
Imagine that you have a software that for example needes at a determined time to convert
Internet network address into strings.
On windows vista or later you can use the "InetNtop" function that is also able to deal with ipv6, but if you link directly to the DLL your program will no work on lower OS (ex: windows xp).
So the best solution would probably be making 2 DLL's one that used "InetNtop" and another that used for example "inet_ntoa".
Then your "main" program would do at runtime a LoadLibrary of the "InetNtop DLL", or the "inet_ntoa DLL", according to the OS that he his installed.
You asked that you can include dll in Additional dependencies libraries, and then why to use loadlibrary.
First lets clear the understanding:
While linking statically, A programmer is needed to add the .lib file to
Additional library dependency, which is linked to the caller program at compile time,
However, Dlls are loaded dynamically, hence you need not to add dlls in Additional library dependency when you are using LoadLibrary ie; if you are linking the Dll explicitly you are not needed to give your dll path in Additional library dependencies.
Please note:
using LoadLibrary you will be able to Get the Dll handle, which you can call the exported function using GetProcAddress.
refer:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
I am attempting to delay load wintrust.dll and crypt32.dll in my application (these are used to perform digital signature/publisher checks in a DLL). I am using VS2008. After adding these two DLLs as entries in the Delay Load property in the Linker section of my project properties, I still get LNK4199 warnings that nothing was loaded from the DLL and LNK2019 errors unable to resolve symbols such as WinVerifyTrust.
Adding the following as entries to Additional Dependencies alleviates this problem: crypt32.lib and wintrust.lib. I now get no issues with linking. However, what I am wondering is how do I make sure this isn't being linked to the static lib? I do not want to link to the static lib because of potential licensing issues. I want to dynamically load the DLLs that are installed in Windows, and was hoping DelayLoad could help me do this without having to resort to LoadLibrary and GetProcAddress function calls.
Any information about all the different library usage/linking options would be greatly appreciated!
Thanks.
There is no static .lib for these. The SDK libraries are always import libraries, not static .libs because the corresponding Windows API lives in a DLL. No need to worry about this.
Delay loading doesn't free you from having to link to the lib file. Normally, DLLs are loaded as soon as your application starts. Delay loading just delays this until the first time you call a function from that DLL. Either way, you need to link to the lib file so that the linker can verify that the functions you are calling are actually present in the DLL.
If you don't want to link to the lib files, your only way out is to use LoadLibrary and GetProcAddress.
One tool that can help you determine if things are being linked as you expect is DependecyWalker: http://www.dependencywalker.com/ - specifically, in the case of delay-loads it marks them with a special symbol.
You may want to look at the Win32 API methods LoadLibrary and GetProcAddress.
I'm in the process of porting a large C++ application from Linux (gcc) to Windows (Visual C++ 2008) and am having linker issues with plugins. On Linux this wasn't an issue, as .so supports runtime symbol lookup, but dll does not seem to support this.
Some background information:
The application (the host), which hosts a scripting environment, provides interfaces to plugins (shared libraries that are loaded at runtime by script API calls), allowing the host and the scripting API to be extended without recompiling the host application. On Linux this is just a matter of including the host application's headers in the plugin source, but on Windows I'm receiving linker errors. I'm not sure exactly what I need to link with for Visual C++ to resolve these symbols.
One of our dependencies (open source, LGPL) has preprocessor declarations that it uses to insert __declspec(dllexport) and __declspec(dllimport) into it's headers. Some prior research indicates that I may have to do this as well, but I'd like to be sure before I go modifying a whole bunch of core headers. (I was previously able to get this working on MinGW, but we've decided that supporting Visual Studio is a requirement for this sort of commercial project.)
My question, in a nutshell: How do I link runtime-loaded dlls against a host exe in Visual C++?
Edit: To clarify the problem with an example, I have a class in my host application, Object, which represents the base type of an object that may be accessed by a script. In my plugins I have a number of classes which extend Object to perform other functions, such as integrating networking support or new visual elements. This means that my dll must link with symbols in the host exe, and I am not sure how to do that.
What do you mean by "runtime symbol lookup"? Do you mean dynamically loading libraries using dlopen and dlsym and so on? The equivalents in Windows are called LoadLibrary and GetProcAddress.
In windows, you don't export symbols from a executable. You should only export them from a dll. The right way to solve your problem is to rearchitect so that the exported symbols are in a dll that the executable and other plugin dlls can link against.
You can't, easily. The windows loader isn't designed to export symbols out of an EXE and bind them to symbols in a DLL.
One pattern that I have seen is the DLL export a certain function that the EXE calls. It takes as a parameter a structure which contains addresses of functions in the EXE for the DLL to call.
I have been implementing the same, constructing a plugin library to build under both Linux and Windows.
The solution under Linux is to use the -rdynamic option in the gcc command line. This exports all of the symbols in the main executable, so that a plugin can find them on loading.
Under Windows, the solution is to add __declspec(dllexport) in front of the definition of those functions in the exe that you want the dlls to use. Compilation will create a .lib file for the dlls to link to. Certainly works under Visual studio 2008.
Related post: https://stackoverflow.com/a/3756083/1486836
As 1800 INFORMATION says, don't do it like that. Move Object out of the executable and into a "third" DLL. Link the plugins and the executable against that.