How to check dll version?

Hi,

I have got a vc6.0 project from my coleague. There are many dlls in this
project and export many functions. So in the main application, there are
bunch of "GetProcAddrss". I don't this kind of style.

I have a little knowledge of COM but do not have many experience, so I don't
want to use COM.

I want to export a class for every dll. The code like below:

//public interface file
class IHardwareInterface{
public:
virtual DWORD GetHost()=0;
virtual DWORD AddHost()=0;
...
};

extern "C" __declsepc(dllexport) IHardwareInterface* CreateInstance();

//implement file
class CHarewareImpl : public IHardwareInterface
{
...
};

Now, if in main application, I only need to create an interface for every
dll. I don't have to write bunch of "GetProcAddess". If I want to add more
export functions, I should update the interface class. What I worried about
is if I use the old dll, main application will not report any errors when
call "CreateInstance". It will report an error when I call the new function.
Is there any method to check whether the dll is consistent with the
interface file?

Any advice is appreciated. Thanks in advanced.

Alex
Fri Jul 20 08:06:12 CDT 2007

"bucher" wrote:
[...]
> Now, if in main application, I only need to create an
> interface for every dll. I don't have to write bunch of
> "GetProcAddess". If I want to add more export functions, I
> should update the interface class. What I worried about is
> if I use the old dll, main application will not report any
> errors when call "CreateInstance". It will report an error
> when I call the new function. Is there any method to check
> whether the dll is consistent with the interface file?

I should warn you that exporting classes from DLL, besides
the advantages you mentiond, has following drawbacks:

1. Both DLL and its client must use C++.

2. Both DLL and its client must use the same version of the
compiler in order to be compatible. There is no binary
compatibility for C++ code.

Regarding your versioning problem there is no ultimate
solution. Usually, once interface is published, it cannot
change (like in COM). Interface is a contract that you
cannot breach unilaterally. If you need to add new methods,
then make new interface. For example,

class IHardwareInterface2
{
// all methods from IHardwareInterface
...

// new methods
virtual DWORD NewMethod() = 0;
...
};

So, old clients will continue to use `IHardwareInterface'
while new clients will be aware of new functionality and use
new interfaces.

Alex

Ben
Fri Jul 20 22:58:00 CDT 2007


"Alex Blekhman" <tkfx.REMOVE@yahoo.com> wrote in message
news:OPX6A7syHHA.5408@TK2MSFTNGP02.phx.gbl...
> "bucher" wrote:
> [...]
>> Now, if in main application, I only need to create an interface for every
>> dll. I don't have to write bunch of "GetProcAddess". If I want to add
>> more export functions, I should update the interface class. What I
>> worried about is if I use the old dll, main application will not report
>> any errors when call "CreateInstance". It will report an error when I
>> call the new function. Is there any method to check whether the dll is
>> consistent with the interface file?
>
> I should warn you that exporting classes from DLL, besides the advantages
> you mentiond, has following drawbacks:
>
> 1. Both DLL and its client must use C++.
>
> 2. Both DLL and its client must use the same version of the compiler in
> order to be compatible. There is no binary compatibility for C++ code.

That's only true of __declspec(dllexport) on a class, which isn't being used
here. What the OP is trying to do is actually the correct way to avoid
dllexport'ed classes.

>
> Regarding your versioning problem there is no ultimate solution. Usually,
> once interface is published, it cannot change (like in COM). Interface is
> a contract that you cannot breach unilaterally. If you need to add new
> methods, then make new interface. For example,
>
> class IHardwareInterface2
> {
> // all methods from IHardwareInterface
> ...
>
> // new methods
> virtual DWORD NewMethod() = 0;
> ...
> };
>
> So, old clients will continue to use `IHardwareInterface' while new
> clients will be aware of new functionality and use new interfaces.
>
> Alex

Alex
Sat Jul 21 03:16:28 CDT 2007

"Ben Voigt [C++ MVP]" wrote:
>> 2. Both DLL and its client must use the same version of
>> the compiler in order to be compatible. There is no
>> binary compatibility for C++ code.
>
> That's only true of __declspec(dllexport) on a class,
> which isn't being used here. What the OP is trying to do
> is actually the correct way to avoid dllexport'ed classes.


In any case, both DLL and its client rely on binary layout
of `IHardwareInterface' class. Without this restriction any
call to interface's method will lead to unpredictable
results. Having said that, `IHardwareInterface' is already
one little step before you can call it COM. So, making it
COM object is preferable if you don't like to export
classes. At least you will gain a guarantee of binary
compatibility between server and client.

Alex

Ben
Sat Jul 21 09:03:59 CDT 2007


"Alex Blekhman" <tkfx.REMOVE@yahoo.com> wrote in message
news:%2321sx92yHHA.748@TK2MSFTNGP04.phx.gbl...
> "Ben Voigt [C++ MVP]" wrote:
>>> 2. Both DLL and its client must use the same version of the compiler in
>>> order to be compatible. There is no binary compatibility for C++ code.
>>
>> That's only true of __declspec(dllexport) on a class, which isn't being
>> used here. What the OP is trying to do is actually the correct way to
>> avoid dllexport'ed classes.
>
>
> In any case, both DLL and its client rely on binary layout of
> `IHardwareInterface' class. Without this restriction any call to
> interface's method will lead to unpredictable results. Having said that,
> `IHardwareInterface' is already one little step before you can call it
> COM. So, making it COM object is preferable if you don't like to export
> classes. At least you will gain a guarantee of binary compatibility
> between server and client.

The compiler provides that guarantee here... it has to in order to support
COM, but it applies equally well to this code.

>
> Alex