I was wondering if there is any way to make something like plugin in Java, so main program loads sub-programs and execute their functions. I thought about set of small programs that return some value, but I want to make the plugins able to modify some of the main program objects (maybe pass the pointer somehow?).
Is there any way to do this?
Thanx for any replies.
It is possible to dynamically load code at run-time in the form of dynamically linked libraries (DLL:s in Windows).
The approach (when dealing with Windows at least) I use is about this:
Create a dll with some exported functions (declared with __declspec(dllexport))
Load the created file at run-time with the LoadLibrary function in the Windows-API
Get the function-pointer to a member function by its name with the function GetProcAddress-function using the name of the function.
The last part may be a little confusing sometimes as C++ uses name-mangling to keep track of return types and such things. This means that the name stored in the DLL is not the name of the function, but a name also containing descriptions of the function's parameter types and such things.
To prevent the name-mangling, you can declare the exported functions with extern "C", such as
extern "C" __declspec(dllexport) int myFunction(...);
However, this will not allow for classes in the function declaration.
An important thing to consider when passing pointers to data structures between the dynamically linked library and the "main program" is to make sure that the declaration of the type is the same in the two files (easily accomplished by sharing the header declaring the type), otherwise there will be severe errors when executing your program.
Again, this is probably Windows-specific, but it might give you a hint of the correct procedure on your system.
Related
I have inherited a large C++ project in which a multithreaded executable loads a few dozen DLLs. On Windows, the DLLs are loaded using LoadLibrary(), and the entry points to the DLLs are accessed using GetProcAddress().
One of the entry points in each DLL is a function called MyEntryPoint, declared like this on Windows:
extern "C" __declspec(dllexport) void MyEntryPoint()
MyEntryPoint() needs to call helper functions inside the DLL where it is defined. The helper functions do not need to be exported outside of the DLL in which they are declared because they are used only locally. However, several DLLs have functions with the same name. Example: in several DLLs, there is a function declared as:
void MyHelperFunction()
which is called by MyEntryPoint(). In some DLLs, MyHelperFunction() is declared static, but not in others. (Over the years, there have been many hands in the code, with varying levels of understanding and expertise.) Does declaring MyHelperFunction() as static avoid cluttering the global namespace, or is there another reason for doing it?
If library interface is defined via explicit __declspec((dllexport) annotations static won't cause any changes. If library interface is defined via .def file (which is unlikely), declaring function as static would preclude it's usage in .def file.
In addition to above, static would inform compiler that function is only accessible from current translation unit which allows more optimizations (e.g. inlining and cloning are done more aggressively) so it's always beneficial to use it.
I have declared some global variables to be _Cilk_shared. They are used in the functions that I want to offload They are used in some functions I do not want to be offloaded as well.
So initially I only declared those functions that I need to offload as _Cilk_shared and call those function using _Cilk_offload.
It compiles fine. And when I run it on host only it gives correct result.
Then I run it with MIC. it gives me runtime error about can not load library blablabla undefined symbol followed by function names that I did not declare as _cilk_shared. Those functions are not needed to be _cilk_shared as well.
So I have to change those functions to _cilk_shared. Run it again. This time MIC gives correct result.
And I checked whether those functions (which I did not want to offload and did not declare as _cilk_shared initially ) are offloaded or not, by Using
#ifdef __MIC__
printf(" Running on MIC\n");
#else
printf("No MIC\n");
#endif
The result is that they are not offloaded....
So I am wondering why it wants me to declare those functions as _Cilk_shared?
When a function is declared for offloading -
if the function is defined in that file, the compiler generates
object code that will run on the processor and object code that will
run on the coprocessor.
if the function is used in that file, it
generates object code that will call the processor version and code
that will call the coprocessor version (unless the call is inside an
area that is protected by '"ifdef MIC"
So why might the loader want a function to have been declared for offload even if you never call it in an offloaded region?
Well if the function is part of a class, then the entire class needs to be declared for offload because the class 'knows' what functions are part of it. When you load the object code for a class, you load in the whole class. In this case if you are going to share objects of that class, it should be declared as _Cilk_shared.
You can get into similar problems if the functions are in a dynamically linked library. The dynamically linked library 'knows' what functions are part of it and it 'knows' what functions are required by it. So, when you run your code, the loader wants to find all the files the library 'knows' it needs. In this case, the simplest thing is to just make offloaded versions of all the libraries. Other things you can try - try either statically linking the library containing those files or try creating libraries that don't 'know' they need things they really don't - break your library into pieces or try explicitly create separate host and coprocessor version of the library as you would for code you are going to run natively on the coprocessor.
If this doesn't explain what you are seeing, let me know.
I am trying to handle a project with multiple dynamic libraries, in the libraries some global objects are created and registered in a list so that the executable can use them to build other things. In the executable there's no reference to any function of any library, it just needs the objects, and then it knows what to do. These libraries are intended to work like plugins that are chosen at link time.
Ideally when compiling ExecutableProject I link LibraryA, an object of type A gets created (by some code that's compiled in the library) and ExecutableProject does things because of it, using functions in LibraryA. If instead I link LibraryB then an object of type B gets created and other things happen.
The problem is, since ExecutableProject does not directly use any function or class in the library, the library is not loaded, and objects are never created.
I have found some workarounds:
I can use /INCLUDE:symbol at link time when compiling ExecutableProject, where symbol is any symbol exported in LibraryA or LibraryB. I don't like this because I have to know the decorated name of a function in the library, which is not always available. Also, it's not elegant.
I can use a dummy variable. I could put __declspec(dllexport) int force_link_A_or_B; in LibraryA and LibraryB and __declspec(dllimport) extern int force_link_A_or_B; in ExecutableProject. I don't like this because if I had more libraries I'd have to add a variable for each of them. Basically although the code in ExecutableProject does not know which libraries will be linked, it still needs to know how many of them can be linked together.
On Linux, using gcc and ld, it's very easy to solve this problem, all it takes is a simple linker flag -Wl,--no-as-needed. Is there any way to do this using Visual Studio? I would be happy if there was something that worked like /INCLUDE but used entire libraries instead of symbols and did not need decorated names.
Thanks
EDIT: I have been asked to clarify how this design is intended to work. Ideally, when I compile ExecutableProject I link LibraryA or B and an object is created.
`ClassA A;`
This is placed outside all functions in a source file that is compiled in LibraryA. Same thing happens in LibraryB. The key here is that ClassA and ClassB inherit from a BaseClass that ExecutableProject knows well. When the object is created, the BaseClass constructor is run, and inside it a BaseClass* pointer pointing to this (therefore the derived object) is saved, and ExecutableProject uses that pointer. It does not need to know anything about the derived classes, because it uses only a BaseClass pointer, but when it calls virtual functions from it, different functions are executed depending on the actual type of the pointed object. If there were more objects instead that just two alternatives, I would save BaseClass pointers in a list or a map, and let ExecutableProject access it.
Don't try this. The design is fundamentally flawed.
In particular, since you are not making any explicit calls to the DLL, you would rely only on object A being created via an implicit call to DllMain.
But under Windows rules, you are barred from doing anything interesting in or from DllMain, so object A cannot be very useful.
I have compiled a library that I have created with MinGW into an existing application using Borland 6 (I know its old but that's what it was made with). I have used implib to create the .lib file and imported it into my project. I have also added the paths to the dll and necessary header files.
When I try to compile I get a pile of Unnresolved external type errors. Have I missed out any steps of the importing process? Assuming I haven't and the issue is something like name-mangling how do I go about writing the interface in such a way that name mangling won't matter. I know it involves extern C but thats about the limit of my knowledge. There are only two classes that need to be accessed from outside the dll the remainder are all only used internally. I'm not sure how to use extern C with something that is entirely built with classes. I'm stil hopeful that it's my importing with borland 6.
extern "C" cannot be used for classes, only for free functions. So you have an option of writing a "C" interface to your class, where each function takes a pointer to your class and you would probably have create and destroy functions.
This is a way it is typically done, and your class could be forwardly declared as struct, which is the same as class, and then could even be used by applications written in C. You would normally put extern "C" only when __cplusplus is defined so there are normally #ifdef guards around it.
There is another option, if you only want your class to be used by C++ and you don't want to have to write a C interface for all your class methods.
Users of the DLL use an abstract interface and still use Create and Destroy methods (with extern "C") to create a pointer to the abstract interface, but then use the pointer in the normal C++ way. Of course ideally you will wrap this pointer in a smart pointer, e.g. a boost shared_ptr with a custom deleter that calls the Destroy method. (Users of the library should do that but you can provide a headers-only interface to do it).
There are a few other issues you would need to beware of if doing this, e.g. anything to do with run-time type information is likely to not work on the user-side, including exceptions. And once again your library could provide "open-source" C++ wrappers (compiled on the client side) to handle this in a more C++ way. A sort-of pImpl.
The name mangling is not standardized across compilers. Only expose extern C functions so that they are not name mangled. But this has a limitation that you cannot use object orient programming.
Another option is to implement COM objects as they are binary compatible.
Wonder what the difference between:
static PROCESSWALK pProcess32First=(PROCESSWALK)GetProcAddress(hKernel,"Process32First");
...
pProcess32First(...);
what is hKernel? Look in here. You can replace with GetModuleHandle()
and
#include <Tlhelp32.h>
...
Process32First(...);
What are the differences, I wonder which I should use. Is there any difference in terms of best practices then?
NOTE: my answer assumes that the function is available either way, there are other things to consider if you are after non-exported functions.
If you use LoadLibrary and GetProcAddress, then you have the option running with reduced functionality if the required library isn't there. if you use the include and link directly the lib, and dll isn't there (or doesn't have the export due to wrong version) your app will simply fail to load.
It really only makes a difference if you want to use a function that isn't in all versions of a given dll.
In addition to what Evan said (which is correct), another important difference (IMHO) is that if you're dynamically loading functions, you need to have a typedef to cast the void* to in order to call the function once it's loaded. Unless the header files which defines the function prototype for static linkage has a mechanism for also defining the typedef for the function pointer from the same template function definition code, you're going to end up with a duplicate function definition, probably in your code. If the external header definitions are ever updated (for example, with new definitions for 64bit data types), you risk runtime errors in your application unless you update the other function prototypes (these will not be caught at compile time, because of the c-style cast to the function typedef).
It's a subtle issue, but an important one to consider. I would use implicit ("static") linking if you can because of that issue, and if you're using dynamic loading, be aware of the issue, and structure your code to avoid problems in the future as best you can.
See here for Microsoft's explanation.
Implicit linking (using *.lib) is simplier.
As for kernel libraries, there are no other difference.
I would take the first approach if I had optional plugin libraries that the user may or may not have. For necessary libraries I would use the second since it is a lot less code to get the functions.