Using an existing DLL with a Visual C++ project

[glitch003]

Hi, I'm trying to use a DLL from another program in my code. The DLL is a Microsoft Visual C++ 7.1 DLL and I want to call functions from it in my new project. I've been able to load the DLL with LoadLibrary and it's my understanding that I can then get the address of the function I want to call using GetProcAddress(). My problem is that the function I want to call is inside a C++ class in the DLL, so I need to create an instance of that class and then call one of it's member functions. Since the function I want to call is inside a class, I can't get the function address with GetProcAddress. When I check what functions I can access with GetProcAddress (using dumpbin.exe /exports), I see a function called "DllGetClassObject".

From this I have assumed that I can use DllGetClassObject to get the class from the DLL so that I can create an instance of that class and then call it's member functions. How do I do this? Is my assumption correct or is there a different way to get a class object so that I can call it's members?


Is there an easier way to import the .dll, maybe not using LoadLibrary but instead using Visual Studio to handle the library importing? I'm used to the C# world where I can just add the dll to the project and then use all the dll's functions. Is there some equivilant way of doing that in Visual C++?

Thank You

[VictorN]

Is there an easier way to import the .dll, maybe not using LoadLibrary but instead using Visual Studio to handle the library importing? I'm used to the C# world where I can just add the dll to the project and then use all the dll's functions. Is there some equivilant way of doing that in Visual C++?

Yes, if you have .lib file for this dll - just add it to the list of object/library modules for the linker and then you will be able to call dll functions (and create class instances) directly.

[GCDEF]

Nobody here can tell you how to get an instance of the class without seeing at least the interface of the DLL. That function sounds promising though.

When a DLL is built, an import library is built along with it. If you have a header file and the import library, you can #include the header and link the .lib then you don't need to call LoadLibrary and GetProcAddress.

[glitch003]

Nobody here can tell you how to get an instance of the class without seeing at least the interface of the DLL. That function sounds promising though.

When a DLL is built, an import library is built along with it. If you have a header file and the import library, you can #include the header and link the .lib then you don't need to call LoadLibrary and GetProcAddress.

I don't have the .lib file unfortunately. I can post the DLL if it will help. I know the class name I want to access and the function I want to call. The forum won't let me post a .dll but it will let me post .zip so I zipped the DLL and attached it to this message.

[cilu]

MTXSDK.dll only exports 4 methods: DllCanUnloadNow, DllGetClassObject, DllRegisterServer and DllUnregisterServer. Thus this is not a "regular" DLL, it is a COM server. Therefore you need to access those objects (these ones http://www.infraredtraining.com/comm...thread/11403/?) through COM. If you are not familiar with COM I suggest these readings:
http://www.codeproject.com/Articles/...-How-to-Use-It
http://www.codeproject.com/Articles/...he-Scenes-of-a

[Igor Vartanov]

Hi, I'm trying to use a DLL from another program in my code. The DLL is a Microsoft Visual C++ 7.1 DLL and I want to call functions from it in my new project. I've been able to load the DLL with LoadLibrary and it's my understanding that I can then get the address of the function I want to call using GetProcAddress().

The fact that you're able to load a DLL with LoadLibrary means literally nothing. To be able to use the internal code the appropriate functions must be exposed for external calls. The way how those get exposed actually depends on the DLL type. Regular DLL exposes its functions by means of export table. COM DLL exposes its classes by means of type library and COM runtime. Everything that appears not exposed, this or that way, will remain inaccessible for other modules disregarding how desperately they would need it be accessed.

My problem is that the function I want to call is inside a C++ class in the DLL, so I need to create an instance of that class and then call one of it's member functions. Since the function I want to call is inside a class, I can't get the function address with GetProcAddress. When I check what functions I can access with GetProcAddress (using dumpbin.exe /exports), I see a function called "DllGetClassObject".

DllGetClassObject presence is the first sign that the DLL is COM DLL (though it never guarantees that it exposes that what you need). Therefore, GetProcAddress hardly could help. With COM DLL you should follow standard COM way.

From this I have assumed that I can use DllGetClassObject to get the class from the DLL so that I can create an instance of that class and then call it's member functions. How do I do this? Is my assumption correct or is there a different way to get a class object so that I can call it's members?

From this I can suppose that you never made it to read about DllGetClassObject API.

From MSDN:

Notes to Callers

You should not call DllGetClassObject directly. When an object is defined in a DLL, CoGetClassObject calls the CoLoadLibrary function to load the DLL, which, in turn, calls DllGetClassObject.

Is there an easier way to import the .dll, maybe not using LoadLibrary but instead using Visual Studio to handle the library importing? I'm used to the C# world where I can just add the dll to the project and then use all the dll's functions. Is there some equivilant way of doing that in Visual C++?

The easiest way is the way recommended in the documentation to your DLL.

[glitch003]

Thanks for the info Igor, I'll try to use CoGetClassObject

The easiest way is the way recommended in the documentation to your DLL.

My DLL has no documentation. It boggles my mind that it's so much easier to use this Visual C++ DLL with C# than it is with C++. With C#, I just used the tlbimp.exe on the DLL and then added the DLL directly to the project. I can then see all the classes and functions as if it were a native C# DLL. Intellisense will autocomplete functions from the DLL, for example.

Why is there no way to do this with Visual C++? I shouldn't need documentation for the DLL, I should just be able to import the DLL and use it's functions. I'm not saying that Visual Studio HAS this feature or this ability for C++, but I am saying that it certainly SHOULD have this functionality. /end rant

[Paul McKenzie]

Thanks for the info Igor, I'll try to use CoGetClassObject

My DLL has no documentation.

No documentation whatsoever? Unless you or someone from your company or programming team built the DLL, then how do you know what the functions do, what parameters to use, what return values are supposed to denote, etc.? What if a function erases a directory or files on your system, opens up a port, etc., and you had no indication that it did such a thing?

Also, how do you know you're allowed to use such DLL, i.e. it's a commercial DLL and you must be licensed to use it or is really part of a larger set of DLL's that require you to be a licensed user to use? A DLL with absolutely no documentation whatsoever (no online docs, no website for the author, etc.) is very rare. If you did a google for that DLL name, what comes up?

It boggles my mind that it's so much easier to use this Visual C++ DLL with C# than it is with C++. With C#, I just used the tlbimp.exe on the DLL and then added the DLL directly to the project. I can then see all the classes and functions as if it were a native C# DLL. Intellisense will autocomplete functions from the DLL, for example.

The DLL is a COM DLL. Therefore it needs a language that has COM awareness built into it or into the basic libraries that the language uses. C++ is not a COM-aware language, as COM is not part of C++, either in the language or the language library. COM and COM awareness is part of the C# environment.

To use a COM DLL with C++ requires you to add this ability, and that is what Igor mentioned.

Secondly, if that DLL were not a COM DLL, but a regular old non-COM DLL with exported functions (as most DLL's are), then you would see that to use the DLL in C# would be more difficult than for C++. For C#, you would then need to set up pinvokes for the functions, while for C++, all you would need is LoadLibrary / GetProcAddress or a .lib file to use the DLL right out of the box.

Regards,

Paul McKenzie

[Igor Vartanov]

My DLL has no documentation. It boggles my mind that it's so much easier to use this Visual C++ DLL with C# than it is with C++.

Maybe this is just because C++ is not C#? Or C++ is much older than C#? Or C++ is more versatile language? Or you just have no experience in C++/COM/DLL?

With C#, I just used the tlbimp.exe on the DLL and then added the DLL directly to the project. I can then see all the classes and functions as if it were a native C# DLL. Intellisense will autocomplete functions from the DLL, for example

Same thing in C++. You #import your DLL and then can see "classes and functions" in .tlh file. But this is applicable only to COM DLLs. Or better say, DLL's COM part, as it may be a hybrid DLL alright, exposing some COM interfaces as well as plain exports, which depends on DLL developers fancy. Poor thing C# may even have no idea about this possible, right?

Why is there no way to do this with Visual C++? I shouldn't need documentation for the DLL, I should just be able to import the DLL and use it's functions. I'm not saying that Visual Studio HAS this feature or this ability for C++, but I am saying that it certainly SHOULD have this functionality.

A very common mistake. You always need some knowledge about the way how the DLL should be used to do that properly, as designed and licensed. And it's a pity that DLL providers neglect this aspect quite often.

[glitch003]

Maybe this is just because C++ is not C#? Or C++ is much older than C#? Or C++ is more versatile language? Or you just have no experience in C++/COM/DLL?

I agree with you, it's definitely a combination of those things. I just wish MS would make it easier for someone with "just" a dll.

Same thing in C++. You #import your DLL and then can see "classes and functions" in .tlh file. But this is applicable only to COM DLLs. Or better say, DLL's COM part, as it may be a hybrid DLL alright, exposing some COM interfaces as well as plain exports, which depends on DLL developers fancy. Poor thing C# may even have no idea about this possible, right?

Ha you're definitely right, C++ is way more versatile than C#. Is there any way to generate the .tlh file from just a dll?

A very common mistake. You always need some knowledge about the way how the DLL should be used to do that properly, as designed and licensed. And it's a pity that DLL providers neglect this aspect quite often.

In some senses it's my fault that there's no documentation since I'm reverse engineering this DLL from being used in an existing application. Luckily C# made that a snap by showing me all the functions and classes I can use, and I got everything working in C#. And since it was so easy in C# logically I just thought "Well it must be even easier to use this DLL in it's native language" but I understand now that C++ has a bunch of different ways you can store code in a DLL which is a more powerful paradigm but makes it harder for people like me that just have a dll.

Thanks for your help!

[glitch003]

Is there any way to generate the .tlh file from just a dll?

Whoops, just found out that all I have to do is build the project to generate the .tlh file. Intellisense was underlining the import in red but it looks like it's just a limitation of intellisense: http://connect.microsoft.com/VisualS...rt-progid-in-c

Thanks again man.

[Igor Vartanov]

And since it was so easy in C# logically I just thought "Well it must be even easier to use this DLL in it's native language"

In fact, for the DLL which is properly designed to be used in multiple languages it ultimately doesn't matter what the "DLL native language" is.

[Paul McKenzie]

Well it must be even easier to use this DLL in it's native language

The Windows operating system is made up of DLL's and EXE's. So how can programs written in any language eventually run on Windows? Those languages have to use the Windows OS somehow (creation of windows, menus, dialogs, etc.).

A DLL can be created in any language that allows DLL's to be created. This not only includes C and C++, but other languages. What ends up is that the DLL is nothing more than an executable file with exported functions, and no indication of what language created the DLL.

powerful paradigm but makes it harder for people like me that just have a dll.

As I stated, if you were given a non-COM DLL, you will see that using such a DLL is more difficult in C#. The "luxury" of a COM DLL in C# is what you're experiencing, but a vast majority of the DLL's that are created are not COM DLL's. You would have to set up the correct pInvoke calls in C# to call the DLL's functions properly, you don't get a list of all of the functions, etc.

In some senses it's my fault that there's no documentation since I'm reverse engineering this DLL from being used in an existing application.

And you have the rights to reverse engineer this DLL? Many EULA's state that reverse engineering a software author's DLL or other components is in violation of the license agreement. Since you never stated what this DLL is, where it comes from, who the authors were, etc. I'm just giving you fair warning that what you are doing may not be legal.

Regards,

Paul McKenzie

[glitch003]

Okay so you guys will probably think I'm an idiot because I'm missing something obvious here, but I'm kind of stuck. I used #import to bring in the DLL and generate a .tlh file for it in a new win32 console application. Now, in C# I could just do ClassName irv; to declare a new object of type ClassName, for example. When I try it in C++, I get this error: "'irv' uses undefined struct 'ClassName'". I replaced the actual class name with the word "ClassName" for this forum post, just to be clear.

Why is this happening? I know that ClassName is an actual class and not just a struct. I can see in the .tlh file that that class is declared as a struct which is obviously the reason for my error. But then how do I create an object of type ClassName?

I can post the code, the .tlh, and the .dll or whatever else is needed.

Oh and I don't worry about licensing issues. My country has no extradition treaty with the US so I'm pretty safe to do whatever I want with intellectual property from the US. Thanks for the concern though.

Thank you everyone for all your help so far!

[Paul McKenzie]

Oh and I don't worry about licensing issues. My country has no extradition treaty with the US so I'm pretty safe to do whatever I want with intellectual property from the US. Thanks for the concern though.

You may be new here, but you need to realize that many participants here on CodeGuru are software authors who publish commercial software -- we're not a "script-kiddie" site.

How do we know you're not tinkering around with something developed by someone here, in violation of their EULA? EULA's aren't only created by US companies or individuals. My company sells DLL's, and COM versions of our software is sold by another developer outside of our company. That other person is based in Europe, not the US.

Regards,

Paul McKenzie