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.
Related
I have my program (.exe) and it depends on 3 DLLs to work, but, I want to hide these DLLs, is there any way for me to "put them in .exe" these dlls? Only have the .exe,is there any method to do this?
Info:
Program's ling: C++
DLLs: {libcrypto-1_1-x64, libcurl-x64, libssl-1_1-x64}
If you use the static versions of the libraries, their code will be compiled directly into your EXE, and then you won't need DLLs at all.
But, if you need to use DLLs, then you can compile them into your EXE's resources, and then extract them at runtime to temp files before using them. You won't be able to statically link to any of the DLL functions at compile-time, or else your app won't run at all. But you can dynamically load them at runtime using LoadLibrary() and GetProcAddress() (or, if you compiler supports it, use delay-loading), which will allow you to extract the DLLs before calling their functions.
I have a relatively complex lua environment and I'm trying to understand how the following would/could work. The starting setup includes the following two modules:
Main application (no lua environment)
DLL (statically linked to lua lib, including interpreter)
The dll is loaded into the main application and runs a lua console interpreter and a lua API accessible from the console.
Now, let's say I want to expand this setup to include another dll that would extend that lua API, luasql for example. The new dll needs to link against lua in order to build, and my understanding is that I cannot link against lua statically since there would now be two unshared copies of the lua code in process when I load the extension dll. However, even if I built the lua core lib as a dll and linked against it with the extension dll, that lua core dll would not be loaded at runtime by the main application or the primary dll. So my questions are:
What happens if I load that extension dll from the lua intepreter in the primary dll, considering that the lua core dll will not be loaded?
If I loaded the lua core dll at runtime, how would that conflict with the statically linked lua lib?
Would both scenarios (linking statically in extension dll and dynamically linking/loading the lua dll) result in having two copies of the lua core code in process?
In that event, what would happen if I tried to call an API function from the primary dll's lua environment/interpreter that was built/loaded in the extension dll?
OR does lua have some kind of special mechanism for loading native dlls that provide new C API functions that allows it to bypass normal linking rules?
Hopefully I have provided enough details to make the questions specific, if not I will be happy to refine the scenario/questions further.
Edit: I have looked at Bundling additional Lua libraries for embedded and statically linked Lua runtime and I believe it may be helpful in providing a solution ultimately but I'd like to understand it at the linker level.
You can't have the situation when you load one interpreter (let's say it's linked statically) and load a module X that is linked against a dll with a Lua interpreter, which loads another copy of the interpreter. This is likely to cause an application crash. You need to make the loaded dll to use the interpreter that is already loaded, either by linking against that dll with the interpreter or by using a proxy dll (see below).
You have two main options: (1) make dllA that is loaded by the main application that in turn depends on Lua dll; you can then link all other lua modules against Lua dll without any issues; or (2) include Lua dll into dllA, but keep Lua methods exposed so that lua modules can be linked against that dllA.
I think the first option is much simpler and likely not to require any changes to the Lua modules (as long as you can keep the name of the Lua dll the same as the one that the modules are compiled against).
Another option I should mention is that you can still use Lua modules compiled against a Lua DLL even with applications that have the Lua interpreter statically compiled. You need to use a proxy DLL; see this maillist thread for the solution and related discussion.
The answer boils down to this:
Don't try to load any Lua extensions from a dll linked against a different Lua-core. Doing so will cause utter chaos.
As long as any Lua extension loaded resolves all its dependencies to the proper Lua core, it does not matter (aside from bloat) how many Lua cores you use.
Keep in mind that windows always resolves symbols according their name and their providing dll.
I'm using Code::Blocks and hate manually linking DLLs. I found the LoadLibrary() function, and am wondering if it works like a .a or .lib file would. Does this function work like that? If not, what can I do programming-wise (if anything) to link a DLL without having to link a DLL by doing the Project < Build options < Linker settings < add < ... method?
LoadLibrary loads the requested library (and all the libraries it needs) into your process' address space. In order to access any of the code/data in that library, you need to find out the code or data address in the newly loaded region of memory. You need to use GetProcAddress.
The difference between this process and adding a library during build time is that for build-time library the compiler prepares a list of locations that refer to a given function, linker puts that list into .exe, and run-time linker loads the library, does the equivalent of GetProcAddress for the function name and places the address into all locations that the compiler marked.
When you don't have this automated support, you have to declare a pointer to function, call GetProcAddress yourself, and assign the returned value to your pointer to function. You can then call the function like any other C function (note "C" part - the above process is complicated by name mangling when you use C++, so make use of extern "C")
LoadLibrary() loads a DLL at runtime. Normaly you link when you compile the EXE, and link the DLLs like a static library at this time. If you need to load libraries dynamically at runtime, you use LoadLibrary().
For example when you implement a pluginsystem, is this usefull, as you don't know the libraries beforehand.
Not how it works at all. LoadLibrary is used to load a "at compile time unknown" DLL - such as program extensions/plugins or "This DLL for SSE, that DLL for non-SSE" based on "what can the hardware do - one could also consider having a DLL per connection type to email servers or something like that, so that the email program doesn't have to "carry" all the different variants, when only one is used for any particular email address.
Further, to use a DLL that has been loaded this way, you need to use GetProcAddress to get the address of the functions in the DLL. This is very different from linking the DLL into the project at buildtime, where functions simply appear "automagically" by help of the system loader functions that load the DLL's that are added to the project at build-time.
Contrary to static or dynamic library linking, LoadLibrary doesn't make the library's symbols directly available to your program. You need to call GetProcAddress at runtime to get a pointer to the functions you want to call.
As #Devolus mentioned, this is a good way to implement plugin systems and/or to access optional components. However, since the symbols are not available to your program in a transparent way, this is not really practical for ordinary usage.
This program's stdafx.h is a little like this below.
// ...
#import "./lib/64/msado15.dll" rename("EOF", "EndOfFile") no_namespace
// ...
The program works okay and there are no problems.
I was curious about what would happen if I deleted msado15.dll.
So, I deleted it, and the program still works fine.
I assumed that why the program works without msado15.dll in the same directory must be the dll file is loaded somewhere else.
To make sure exactly where the dll is loaded, I used "Dependancy Walker", and I found out this program is not loading msado15.dll at all.
I would be glad if I could figure out what I'm missing.
Thanks in advance.
Dependency Walker can only see static DLL dependencies (where there's a reference in the EXE's imports table). If a DLL is loaded at runtime via LoadLibrary (or by delay loading -- using /delayload), Dependency Walker will not be able to see this.
#import doesn't actually impose a static dependency on the DLL. It loads the COM typelibrary information from the DLL at compile time. This is transformed into C++ bindings for the COM classes and interfaces defined in the typelibrary. You can see these as .tli and .tlh files in your Debug or Release directory. You might be able to remove the DLL file, and -- as long as these files still exist -- VS might continue to build your project successfully.
Similarly, at runtime, since #import doesn't actually impose a static dependency on the DLL (that is: it won't add it to the imports table in the EXE), Dependency Walker will be unable to see this dependency.
At runtime, however, the EXE will call (indirectly) LoadLibrary, and (if the DLL is missing) this will cause a failure at runtime, which your program might deal with appropriately, or which might cause your program to crash.
Even with all that said, #import merely imports a COM typelibrary. The COM typelibrary defines the interfaces used in the COM objects, along with the CLSID values of those objects. In order to find the code that implements the COM objects, the CLSID values are resolved using the registry (in HKEY_CLASSES_ROOT\CLSID. The code implementing the COM objects may not actually be in the same binary as the original typelibrary.
This means that the DLL may not even be required at runtime. I think that this is rare, however.
Moreover, the COM objects may be implemented as out-of-process objects (meaning that another EXE is loaded). In this case, all that's loaded into your process will be the proxy/stub DLL configured for the relevant interfaces. Often, these will be defined using the TLB (in which case, your #import-ed DLL will be loaded); but they may be implemented in a completely different DLL. Either way, the DLL will be loaded dynamically, which means that Dependency Walker won't see it.
To see which DLLs are loaded by the process, you will need something like SysInternals Process Monitor or Process Explorer.
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.