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.
Related
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 develop a plug in dll, i.e. some other process loads my dll, C++ using VS...
I need to add xml parsing to my code and I use libxml2.
I have added that do my dll and now when the application tries to load my dll it fails to load. It is a dependency issue but I can not figure out what all other libs/dlls I need to add to my project.
Any ideas?
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.
How are DLLs created out of C++ source code, and how are they used in other sources?
The DLL is a 'Dynamic Link Library' which works a lot like other libraries but is not linked with your executable application. At run time you can call specific functions for loading your DLL and executing its exported methods.
You can try creating a DLL yourself- create a project using visual studio and specify a DLL. This will create some of the base constructs for your project such as settings for your project to compile the DLL and also some base code for exposing methods, objects, or variables.
There are many walk through's to help you at this point: check here.
So, to summarize:
A DLL is a library which you can be loaded at runtime. This is a very flexible 'plug-in' model. Example: You can programmatically select and load different DLL at runtime. Each DLL can be a 'plug-in' to provide different functionality.
A DLL Has an entry point. Just like your Main function of your command line executable is the entry point, the DLL has an entry point function which is called when different events occur on the DLL such as loading, unloading, and more.
To use a DLL you must use the exported objects or methods of the DLL.
When Calling these exported functions from another application it is very important that you match compatible types! Also, make sure the calling conventions are compatible