-2

I have a C++ DLL with some exported functions. One of the exported functions is a function which builds and returns a pointer to an instance of a class. I have the header (.h) of this class so I know exactly what are its methods. However, the methods of this class are not exported in the DLL.

My goal is to build a wrapper DLL which will use some functions from the other DLL. This new DLL should be able to be called from Java with JNA or C# with P/Invoke.

Is it possible to call the methods of this object ? And if it is, how should I proceed ?

I tried to simply do this:

MyObject* myObject = GetMyObject();
myObject->callMethod();

I'm able to compile my DLL, however, it crashes when I use it in a program (the callMethod() crashes, not the GetMyObject()).

Edit: I have checked that myObject is not null, and my DLL and the other are both built with MSVC, though the versions may not be same.

Fitz
  • 570
  • 1
  • 5
  • 23
  • 1
    1. Did you check that `myObject != NULL`? 2. Is your DLL built using the same compiler and same version as the other one? – dxiv Feb 15 '16 at 19:01

1 Answers1

0

I guess you speak about Windows. Now it depends, if the MyObject is a concrete object, or a pure virtual interface. With pure virtual interface, chances are high that it will work even between different compilers (technically UB, but uniform implementation of virtual table is a precondition for Windows COM to work, so every compiler actually needs to implement it the same way if it wants to support COM). The pure virtual interface does not need to be exported (just make sure that you do not pass any C++ exception over the library boundary, because that would blow the stack if used between different compilers). And it actually works quite similar in Linux. See my answer here for an example: Providing SDK for my C++ Application

On the other side, if the interface is not pure virtual, the compiler will look for the implementation of the called method. And if the method is not exported from the DLL, it will not be able to find it. And that is even if it is the same compiler - the compiler will simply not know how to call the method from the DLL (i.e. the "address" of the method to be called).

So if you are in control of the DLL and you can change it to provide a pure virtual interface (if it isn't the case now), then it can work.

Community
  • 1
  • 1
EmDroid
  • 5,918
  • 18
  • 18