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.
Related
I currently have a C# project that uses a 32 bit dll. What I am trying to do is to use the dll in a C++ project , unfortunately the dll referenced in the project does not come with a .h or .lib file so I am confused on how I could access the classes in the dll or use the dll file in my project in C++ (Visual Studio 2010) . I read here that if a dll file contains classes its a good chance it might be a COM component.Any suggestions on what I should be looking at in order to integrate and consume methods and objects in that dll.
Update:
I checked if it was a COM by doing an import statement. However I get a "cannot find .tlb file". Then I decided to use dependency walker to check for any exported methods (objects)it seems there are none. I clicked on the main file (which has been highlighted) and couldn't see any exported functions. Any hints on what I should check for next ?. Here is what I get from dependency walker.
With only a .dll and without a corresponding .h or .exp, one place that you might try looking would be the exports table. Tools such as Dependency Walker can show you this information.
One caveat with Dependency Walker is that you'll want to use the right version (x86 or x86_64) for the binary (your DLL). If you're not sure, pick one version and try loading it. Under the CPU column, middle panel, look to see if it says "x64" or "x86" to determine which one you should be using.
With the provided screenshot of Dependency Walker (indicating a dependency on MSCOREE.DLL), I agree with Eugene - this is most likely a .NET library, not a COM library. You will want to check one of the other questions about calling .NET managed code from C/C++.
The dll is most likely a .Net assembly (seeing that it imports mscoree.dll), so you probably want this: How do I call a .NET assembly from C/C++?
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.
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