I need to implement a minimalistic osgi-like modularization framework in C++ on Windows. Similar to Java, I want to ship modules as self-contained units, as dynamic link libraries. While .jar files are actually containers, .dll file are really some chunks of compiled code. Is it therefore even possible to store metadata inside a .dll file and access it in a C++ program?
The simplest way to do this is to store metadata as resources inside DLLs. You can then use the Windows API resource functions to extract the metadata. You don't even need to load the DLL as a code module, you can just load it as a data module, and then extract the metadata resources.
Use LoadLibrary to, well, load a library. Then you can use FindResource and LoadResource to extract your metadata.
Related
I created GUI in C# as gui.dll and create C++/CLI interop interop.dll for C++ project. That means (*.exe call --> interop.dll and interop.dll call --> gui.dll) I test it with C++ console application which is working wintout any problem, because in the end consoleApp.exe and all dlls are in same folder.
What I did:
interop is c++/cli code with reference to C# dll. I created class and export it for use it inside plugin.vst3. C# dll is dynamicaly linked
inside plugin.vst3 project I includeLibrary for interop project to use class and add interop.lib to Linker. interop.dll is dynamicaly linked
What I want:
Now I want use those dlls (gui.dll and interop.dll) inside c++ project as another "dll" myPlugin.vst3 (audio plugin). For those who don't know, audio plugins are located on different location as program which use it. That means, if audio program load plugin, it is different scenario as my consoleApp.exe call dll on same location.
The Problem:
When I run host program which load my vst3, unfortunately vst3 start search for my dlls from AudioHost.exe view not from vst3 view where is my vst3 file located.
For example, if myPlugin.vst3 is inside D:\VstiPlugins\MyTest\, interop.dll is on D:\VstiPlugins\interop.dll and gui.dll next to C:\ProgramFiles\Reaper\Reaper.exe, my plugin is loaded. All files myPlugin.vst3, interop.dll and gui.dll must be on same location D:\VstiPlugins\MyTest.
The questions:
Simple question is "How to load those dlls from vst3" as I describe it in "What I want" and "The Problem"?
What come to mind as firstly was load plugin with code (like LoadLibrary(...)) instead use *.lib. But all examples and solutions, are for dlls which export only C functions and not as my scenario where I use class. Can be dll loaded from code and use class?
Another idea was DLL redirection with manifest file, but there is no documentation for that scenario or I can't find it. And I am not sure if it will be working.
I'm using a third party component in my application that is distributed either as a COM component, or can be referenced using a .manifest file. Either way it is loaded using CoCreateInstance(). The files needed for the third party component reside in a subfolder. The component developer told me to include a .manifest file in the Visual Studio 2010 settings (in the "Manifest" section) of the executable, and loading the component works without problems.
Now I'm using the third party component from a DLL only, to encapsulate the features used from the third party component. I'm loading the DLL dynamically, using LoadLibrary(). Using the component still works, I can use the component from within the DLL that is loaded by the EXE that has the manifest file referenced.
To further separate the EXE from the third pary component, I'd like to move the manifest to the DLL, too, where is the only place the component is used. In this way every new EXE I'd like to write can use the DLL and indirectly use the features. For now, I have to add the mainfest to every new EXE, but I don't want to do that.
Is there a way to move the manifest used by the EXE to a DLL?
You can put the manifest in the DLL, but it may not be activated automatically. You may need to do that manually using the activation context API. I think a lot depends on what the manifest is being used for. I suspect you are trying to use registration free COM, but that's only a guess.
Anyway, these links may well be useful to you:
RT_MANIFEST resource, and ISOLATION_AWARE_ENABLED (Junfeng Zhang)
Isolating Components (MSDN)
I have just started reading up on the JNI and guy from the C++ side of our project has just pointed me towards 2 files, the Java Interface and the DLL file.
With the DLL in hand do I need to have any other knowledge of what is going on on the C++ side. Do I now just put the DLL in the class path and access it via the Java interface he has given me? He created a header file using the Java interface and this is included in the .cpp file. From that I assume the DLL was generated.
The following is some of the code I have
System.loadLibrary("PredictionService");
JNIPrediction predictor = new JNIPrediction();
predictor.getPredictions("test");
I don't get any errors so does this mean it is loading the DLL successfully and calling the getPredictions() method inside the DLL?
Basically I was needing to know is this how you use JNI typically.
A 'Java Interface File' is not a commonly defined term. You need at least a C header file or some documentation to indicate how the functions in your DLL need to be called. The only information you're likely to get from the DLL itself is the names of the available methods.
While it is possible to embed debug information in the DLL which describes the DLL method signatures, it's not likely that you have such in your DLL, and you need additional tools to be able to make use of it.
This is a newbie request. I'm looking for materials on .dll creation. Specifially, i want to create a .dll out of a simple 3D engine i've made to learn about the process. I need information on dynamic link libraries that go deeper than the wikipedia page, how are they created, what's necessary, how to create different .dll files for "debug" and "release", how to create a PDB file for it and how to create a header file that'll allow for easy usage of the library from a, f.e., C++ program. Material with strong theoretical side (not as much, "how to create a dynamic link library in visual studio") would be great.
Please share good materials on the subject, all i can find is some information here and there and it doesn't paint the picture for me.
Reading between the lines, I think you really want to know about libraries in general rather than dll's specifically. A library is simply a handy package of object (compiled) code, along with some information about how to call into it. In C++, this usually takes the form of a .h file.
With static libraries (.lib), the linker pulls in the code it needs in exactly the same way as it does with all the rest of your classes. A normal class will get compiled to object code (MyClass.obj), and when they're all done the linker sticks them all together and wires up any inter-object calls with the appropriate addresses. It's the identical process with .lib library files. You end up with a big ball of executable code which includes both your classes, and the library functions within it.
With a dynamic library (.dll), the only difference is that the linking (wiring) happens at runtime instead of at compile time, and the library object code remains in a separate ball - the dll file. When you compile your exe, all calls that use functions in the library are mapped to a stub function. When Windows loads the dll for you, it will stick the dll code into the same memory area as your process, and wire up the stub functions to the real functions that are now available.
The only other difference is that a dll must expose a function that Windows can call when it loads or unloads the dll, in case the dll wants to do any initial setting up / clearing down. This is traditionally called DllMain().
If you want to learn about libraries, I would concentrate on creating a static .lib first before worrying about dll's. This is where most of the work is. Once you have a lib it is child's play to turn it into a dll.
The main thing you need to think about when creating a library is how you are going to expose your API (Application Programming Interface). This is just which functions/classes you are going to expose to the people using your library. You don't have to expose them all, but you do have to decide WHAT to expose. Are you just going to expose some C style functions, or are you going to expose entire objects? This is the real challenge when designing a library. You should try and make your API as easy to use, and obvious as possible if people (and you!) are going to find your library useful.
As for pdb files, differently named release/debug modules, and creating .h files. These are identical to when doing so in an exe.
1) Create a new DLL project, using VS wizard.
2) Add your existing source files to it.
3) Put into *.def file (which should have been created by the wizard) the names of the functions that you want to export from your DLL, as described here.
Basically, that's it. Debug and release configurations are automatically created by the wizard, but if you want the 2 variants to be named differently, you can change their output names: go to Project Properities -> Configuration Properties -> General -> Target name.
So the question is how to add to c++ builder 2010 some external .exe file? Let's say that i made some program in visual basic and have the exe file, so that does not need to make the same code in c++ i want to just include that exe in my project? Is it possible to make portable application one exe that have inside him self another exe file (maybe in resource path)?
How to call it in code if it is one exe in other? I know to call it by system function, or other by putting direction to the exe, but how to do that if it is on same address as are main exe?
I don't understand exactly what you're trying to accomplish. If you want to use the functionality of a given program, you're going to have to know things about how that program works.
If you want to take a given executable, and call it as you would a shell script, then you would need to start the given program with it's standard input and standard output redirected to a pipe. An example of how to do that is available on MSDN. If you want to be able to just look at the Visual Basic classes and methods in the target EXE, as you could do with Visual Basic .NET, you are out of luck, as an arbitrary executable does not understand the concept of a class or method.
Use the Project > Resources dialog to add the VB .exe file to your project and give it an ID. At runtime, your C++ code can then extract the resource data for that ID to a temporary file, such as with TResourceStream and TFileStream, and then use CreateProcess() to run it. Don't forget to delete the file when you are done using it.
Otherwise, re-write the VB code into a DLL instead, and then the C++ app can simply call the DLL's exported functions when needed. If you want to ship a single self-contained .exe (which is generally not how DLLs are used), then you will have to use the same resource approach, just use LoadLibrary() and GetProcAddress(), instead of CreateProcess(), to access the DLL functions dynamically.