I have a application and two Dlls. Both libraries are loaded by the application. I don't have the source of the application, but the source of the libs. I want to instantiate a class in lib A and want to use this instance also in lib B.
How do I do this? I'm not sure, but I think that both libs are used in different threads of the application.
I have no idea where I have to search for a solution.
No. Think about DLL as just normal library. Both can be used in a single thread.
If you want to use a class A in library X, you must pass a pointer/reference to it. The same applies to library Y. This way both libraries can work with same class/data.
Two dll's loaded into the same process is a fairly simple setup.
You just need to be careful with module scope, which will be the same as dll scope.
e.g. each dll will have its own set of static instances for any static objects.
Next you need to understand how to reference functions/classes across the boundary and what sort of types are safe to use as arguments.
Have a look on any documentation for dllexport and dllimport - there are several useful questions on this site if you search with those terms.
You have to realize that even though your DLLs are used by the host application nothing prevents you (that is your DLLs) from using your DLLs as well. So in your DLL A you could load and use your DLL B and call functions and stuff. When DLL A is unloaded, free DLL B as well. DLLs are reference counted, so your DLL A will have a reference of 1 (the host application) and your DLL B 2 (the host application and DLL A). You will not have two instances of DLL B loaded in the same process.
Named pipes might be the solution to your problems.
If you're targetting windows, you can check this reference
[EDIT] Didnt see you wanted to work on the same instance. In that case you need shared memory spaces, however, you really have to know what you're doing as it's quite dangerous :)
A better solution could be to apply OO Networking principles to your libs and communicate with, say CORBA, using interprocess middleware or the 127.0.0.1 loopback interface (firewalls will need to allow this).
Seems the simple solution would be to include in some initialization function of library A (or in DllMain if needed) a simple call to a function in library B passing a pointer to the common object. The only caveat is that you must ensure the object is deleted by the same DLL that newed it to avoid problems with the heap manager.
If these DLL's are in fact used in different threads you may have to protect access to said data structure using some kind of mutex.
Related
I'd like my Windows application to be able to reference an extensive set of classes and functions wrapped inside a DLL, but I need to be able to guide the application into choosing the correct version of this DLL before it's loaded. I'm familiar with using dllexport / dllimport and generating import libraries to accomplish load-time dynamic linking, but I cannot seem to find any information on the interwebs with regard to possibly finding some kind of entry point function into the import library itself, so I can, specifically, use CPUID to detect the host CPU configuration, and make a decision to load a paricular DLL based on that information. Even more specifically, I'd like to build 2 versions of a DLL, one that is built with /ARCH:AVX and takes full advantage of SSE - AVX instructions, and another that assumes nothing is available newer than SSE2.
One requirement: Either the DLL must be linked at load-time, or there needs to be a super easy way of manually binding the functions referenced from outside the DLL, and there are many, mostly wrapped inside classes.
Bonus question: Since my libraries will be cross-platform, is there an equivalent for Linux based shared objects?
I recommend that you avoid dynamic resolution of your DLL from your executable if at all possible, since it is just going to make your life hard, especially since you have a lot of exposed interfaces and they are not pure C.
Possible Workaround
Create a "chooser" process that presents the necessary UI for deciding which DLL you need, or maybe it can even determine it automatically. Let that process move whatever DLL has been decided on into the standard location (and name) that your main executable is expecting. Then have the chooser process launch your main executable; it will pick up its DLL from your standard location without having to know which version of the DLL is there. No delay loading, no wonkiness, no extra coding; very easy.
If this just isn't an option for you, then here are your starting points for delay loading DLLs. Its a much rockier road.
Windows
LoadLibrary() to get the DLL in memory: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
GetProcAddress() to get pointer to a function: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
OR possibly special delay-loaded DLL functionality using a custom helper function, although there are limitations and potential behavior changes.. never tried this myself: https://msdn.microsoft.com/en-us/library/151kt790.aspx (suggested by Igor Tandetnik and seems reasonable).
Linux
dlopen() to get the SO in memory: http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html
dladdr() to get pointer to a function: http://man7.org/linux/man-pages/man3/dladdr.3.html
To add to qexyn's answer, one can mimic delay loading on Linux by generating a small static stub library which would dlopen on first call to any of it's functions and then forward actual execution to shared library. Generation of such stub library can be automatically generated by custom project-specific script or Implib.so:
# Generate stub
$ implib-gen.py libxyz.so
# Link it instead of -lxyz
$ gcc myapp.c libxyz.tramp.S libxyz.init.c
Good time of day, everyone!
I have some questions about .dll programming in C++, it's rather new for me.
1) If I want to create DLL with a multiple classes, but I still want to create abstract interface for each class, should I create one header file for interfaces, or create separate multiple headers for each abstract class? And what should I do with .cpp implementation of factory functions?
2) If I create object and factory function, and gets a pointer to instance, can I just call "delete" in program when I want to free that memory? I think, that object is placed in dll's pages and there may be some problems. What should I do to properly free memory in this case?
3) I read, that if more than one process binds .dll - dll creates separate individual instances of global variables for each project. Does it right? Then I have two questions if it is true:
3.1) What happens with static members in dll? What if I want to create a singleton manager, can I place it in dll?
3.2) If I have Core.dll and Graphics.dll, Sound.dll and Physics.dll. Core.dll has a global variable (or a singleton manager in my real case). Will the other dlls work with one instance of singleton, or other? (each dll uses Core.dll)
I apologize for my weak English and many questions in one topic :)
Thank you for your attention and answers.
1: Mostly this is up to you and depends on the scale of the project. On something small it matters little, so keep it simple and have a single header. On larger projects it is best to reduce unnecessary interdependencies as much as possible - so put them in seperate files. You can alwasy create "all.h" which just includes the other things.
2: Yes, if the DLL and the EXE are both linked to the multithreaded DLL CRT. Unless you know what you are doing, always use this as it is the safest and will do what you expect - it results in the exe and dll(s) being able to share the heap as if they were a single executable. You can "new Object()" in the dll and "delete obj" in the exe freely.
NOTE: Mixing different versions of your EXE and your DLL can introduce incredibly subtle bugs (if, say, a class/struct definition changes), so don't do that.
3: Every process has its own independent memory space (unless you specifically do certain things to try to get some shared memory). Processes are not allowed to get to memory of other processes.
3.1: I strongly recommend you avoid global state. (Global static-const is OK). Global variables lead to many unexpected and difficult problems, and globals in Windows DLL have a number of additional complexities. It is far better in the long run for you to have explicit "Initialize/Deinitialze" functions in the DLL that the EXE must call.
But, global statics in a dll are not much different than in an executable ... they get initialized in pretty much the same way when the DLL is loaded. (THings get more complicated when you dynamically load DLLs, but lets ignore that here).
3.2: Yes, they would work with the single instance - but don't do it anyways, you will eventually regret it. Much better to make the initialization explicit because you cannot control the order in which global variables are constructed, and this can quickly lead to very difficult initialization problems.
I've snooped around a little bit in MS-Office DLLs, and I noticed that some of the DLLs don't have any exported functions. What I don't quite understand, how an application can use these DLLs without any functions exported ?!
I mean, the dllmain() does get executed on LoadLibrary(), but whats the point? Why would anyone create a DLL without exported functions?
thanks! :-)
One way of dealing with versions of a program destined for different languages is to put all of the resources into a language DLL. The DLL doesn't contain any code, just resources that have been translated to a target language. When the main program starts up, all it needs to do is load the proper language DLL.
I haven't looked at the DLLs in question; but it's possible in something like MSOffice Microsoft have done this to obfuscate the DLL to make it more difficult to debug / reverse engineer.
However, as you ask how would you use such a DLL? Well if the application knows the layout of the DLL then it can create a function pointer with the address of a known function and call it.
If you really want to dig further you could objdump the DLL and look for standard C / C++ ABI function prologues & epilogues and possibly work out where the functions start.
When you call LoadLibrary the DLL gets call of its DllMain.
That is DLL entry point. It is called on process attach and thread attach.
So you do have entry point.
As soon as it has at least one entry point then it can create instance of some interface (e.g. factory) an set it in e.g. TLS variables where other modules will pickup them.
So you can can have COM alike system of interfaces that are not exposed outside except to the application. Something like that - many over variations are possible.
Resources
The DLL likely has resources, like string tables, images, icons, etc., used by the rest of Office.
Always possible that they just don't export them as C interfaces. A DLL isn't magic, it's just bits and bytes, and nothing says that you can't get code out of a DLL if you don't ask Windows for it. I believe that .NET takes this approach- they save metadata in the DLL that tells the CLR what's in it, instead of making .NET functions available by the normal GetProcAddress approach. Unless you explicitly ask for it.
i have have a program/project in vs2008 that uses a third party static lib. Now, it has come to my attention that i need to offer some api's via a dll. Apparently a thrid party program will use my dll via the apis i will provide.
Can anyone give me some direction as to what I need to do? would i need to just create a dll in vs2008 and just copy and paste my method logic in the apis that i provide?
are there any potential issues i need to worry about?
thank you
I suggest you check out this MSDN tutorial on creating & using DLLs.
There are unfortunately many potential issues to think about. A very brief and by no means complete list of the ones that pop in to my head:
You need to be aware of potential errors passing CRT objects across DLL boundaries
If you allocate objects in one module and deallocate them in the other, your DLL and the client code must link to the same CRT
It is very important that you keep the interface seperate from the implementation in your DLLs header files. This means you often can't do thing like use std::string as function parameters, or even as private member variables.
If I think of more or find more links, I'll add them.
I have a C++ class I'm writing now that will be used all over a project I'm working on. I have the option to put it in a static library, or export the class from a dll. What are the benefits/penalties for each approach. The only one I can think of is compiled code size which I don't really care about. Thanks!
Advantages of a DLL:
You can have multiple different exe's that access this functionality, so you will have a smaller project size overall.
You can dynamically update your component without replacing the whole exe. If you do this though be careful that the interface remains the same.
Sometimes like in the case of LGPL you are forced into using a DLL.
You could have some components as C#, Python or other languages that tie into your DLL.
You can build programs that consume your DLL that work with different versions of the DLL. For example you could check if a function exists in a certain operating system DLL and only call it if it exists, and otherwise do some other processing.
Advantages of Static library:
You cannot have dll verisoning problems that way
Less to distribute, you aren't forced into a full installer if you only have a small application.
You don't have to worry about anyone else tying into your code that would have been accessible if it was a DLL.
Easier to develop a static library as you don't need to worry about exports and imports.
Memory management is easier.
One of the most significant and often unnoted features of dynamic libraries on Windows is that DLLs have their own heap. This can be an advantage or a disadvantage depending on your point of view but you need to be aware of it. For example, a global variable in a DLL will be shared among all the processes attaching to that library which can be a useful form of de facto interprocess communication or the source of an obscure run time error.