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.
Related
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.
I want to emulate an unmanaged dll in c++. Is there a good tool to open and view it's interface?
Thanks
The most commonly used tool is Dependency Walker. This shows the list of exported symbols.
However, it does not show the function prototypes because they are not contained in the DLL meta data. To get that information you need a header file for the DLL. The exception to this statement are DLLs containing a COM/ActiveX component with a type library.
And even if you do have the prototypes, that's not enough to know how to emulate the DLL. You need full documentation for the DLL. And then you probably still have a lot of reverse engineering to do.
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.
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.
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