How do I add some external executable to a Borland C++ Builder 2010 project? - c++

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.

Related

Problem with DLL which depend on another DLLs

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.

JNI for dummies

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.

Need help building a DLL for JNI call. Unresolved external references. Borland Compiler

I need to build a DLL that can then be loaded with JNI from a java program. I was able to do this last year and it worked fine. I'm trying to recompile my same .cpp file now though that I make the dll with and it is failing because of an included dll dependency that gets brought in.
I have a c++ program that calls about 5 functions from some existing C++ code here. These functions are part of a huge codebase that are normally all linked together to build a set of 5 dlls.
I use dependency walker to view my dll and last year it compiled with just 2 dependent system dlls being put in my dll. Today I'm trying to recompile the same dll, but it brings in a 3rd dll file if I link with the .lib file from our existing codebase that contains the functions I use.
Basically I know my dll will work fine with JNI if I can avoid that 3rd dll showing up in my program. The problem is I don't know how to reference the functions I need in my code from our existing code base without linking to the lib file.
I can get this to work with standard c++ files and methods. This problem only happens when I reference this preexisting code from our huge codebase.
If I do not link my .obj file with a .lib file from our code I get unresolved reference messages from my Borland 5.5 compiler I have to use.
The overall issue is that my dll file works fine when I call it from a c++ exe file, but Java cannot handle something in it. Also, if I compile my code into a .so file in unix instead of a windows dll, Java JNI works fine and can load it. I know the problem is related to how Windows uses dlls, and I know if this 3rd dll doesn't load as part of my dll it will also work. I just have no idea what I did last year to build my dll without this 3rd one showing as a dependency.
If I comment out the functions from our existing code it compiles fine and loads because the 3rd dll dependency doesn't get put in my dll.
More Details
I had a message about missing _strcopy, so I linked in the cw32mti.lib file and that went away, but then that cw32mti.dll shows up in my dll file. How do I prevent the missing reference message for something like that and prevent it from putting the dll in my dll?
My link command looks like this.
ilink32 mydll.obj, mydll.dll,,cw32mti
The only way I get the other missing references to work is adding the other dll to my link command like:
ilink32 mydll.obj, mydll.dll,,cw32mti.lib other.lib
Where other.dll contains functions I call from mydll.dll such as calculate(int a, int b), so my code has a link it in like calculate(num1, num2); The problem is when I use the lib that contains the calculate method, it also brings in other dlls linked to the other.dll that I do not want to load. I need to be able to call calculate(num1, num2) without adding other.dll to mydll.dll. This worked before without dynamically calling calculate and using the getprocaddress type of coding.
Update - I eventually had to give up on getting the windows dll to work with the smartheap memory manager. Since this code was deployed in unix, I was able to just build the .so files and get those to work with JNI. For the Windows dll compile, I put some conditional compiler statements around the JNI code that was causing the smartheap dll to be loaded, so then when it compiles in windows it does not use that code. Instead I just had it print out a statement saying it was not executing in windows.
We also ran into issues later with getting our 64 bit JBoss server to run and load these 32 bit .so files. I ended up running a parallel JBoss server next to the 64bit one and called the methods that referenced the 32 bit library on the 32 bit instance of JBoss.
It may evolve into more later, but for now this task is working for us after months of trying many different things. I appreciate all of the help and input here.
If you can get your hands on the application DLL built from last year, use TDUMP to see what the module dependencies are. (You might have to analyze all the DLLs to get a good picture.) Then endeavor to reproduce that in the new DLL, probably by adjusting the linker's configuration .DEF file.
Without any code or .DEF file shown in your question, it is very difficult to be more specific.

How to call a unmanaged C++ exe from managed c++ exe

Please tell me how to call a unmanaged c++ exe functions from managed c++ exe or dll? help with code example would be more useful.
Thank you
You need to link against the library that contains the function you want to call, include a header that defines the function and then just call it.
Without a more specific question you're not going to get much more than that.
I think you should have a look at P/Invoke. Using this tech you could call any unmanged function exported in a DLL or EXE from a managed function.
For example:
http://www.codeproject.com/KB/cs/essentialpinvoke.aspx
The managed/unmanaged is a red herring. When you have some code you want to call, it should be in a lib, a DLL, or a COM exe. A regular double-click-it-to-run-it exe that doesn't implement any COM interfaces doesn't expose any of its code to outside callers. If you just want to run it, you can use Process.Start to launch the whole exe. Otherwise you're going to need to re-architect a bit (this will involve having the source code to the other exe.) Generally I pull most of the functionality into a lib or dll, have the original exe call into that library to get its work done, and have the new exe also call into the same library.
Since you're in C++/CLI, do not go COM Interop or P/Invoke. IJW is way easier (it just works, right?) Include the header, link to the lib. Done! But as you now see, getting the lib can be the big first step.

DLL EXE Hybrid C++ Windows

I am currently working with DLL injection and need to have a single hybrid binary that could act as both an executable and a DLL. I thought of maybe writing a DllMain and WinMain function and then compiling it as an executable but I don't know what would happen if I did that. I know that it is posssible to combine a dll and exe by using something like thinstall or extracting the dll to a temporary location then going from there but I don't want to mess with any of that stuff. So basically, is it possible to define a WinMain and Dll Main and then use the resulting executable as both, and if not, is this even possible? Thanks in advance!
No.
Both a DLL and an EXE have a PE (Portable Executable) header. That header has a field IMAGE_FILE_HEADER::Characteristics. Bit 14 of that field is either 0 (for an EXE) or 1 (for a DLL).
Why don't you put all the common code into a static library (.lib) and have both DLL project and EXE project as a very thin wrapper around the static library?
You could create a temporary copy of your executable, patch the PE header and inject this copy. Another way is to put the DLL as binary resource to the executable. On runtime you can write this binary resource to a temporary file and use this for injection.
It is possible to export functions from a exe too. So you should be able to LoadLibrary("foo.exe") followed by GetProcAddress(hFoo,"bar")