views:

219

answers:

2

Is it possible to find all interfaces (classes, parameters, ect..) normally registered with Component Object Model's (COM) TypeLib even though the TypeLib is completely empty? If so how would you go about doing this? I believe another term for this is an "Anonymous COM". I am sure that accessible interfaces exist for this COM because i have an application that is using a class that isn't listed in the TypeLib.

+3  A: 

If the type library is blank, then there is no way that you can find information about the types in a COM library.

You need at least a coclass entry in the typelib to find an implementation of IUnknown.

If you have that, then you can actually create instances of the class and then call QueryInterface on IUnknown for the IDispatch implementation (if one exists).

If an IDispatch interface exists, you can then call GetTypeInfo to get information about the interfaces that are implemented.

If you need to make late-bound calls to IDispatch, then you will need to call the Invoke method.

Note, you mention the type library, but it is common practice for in-process COM servers to embed the type library in the dll that is the implementation of the types represented in the library. Are you sure that you haven't checked that as well? Or are you sure you have the type library and it is indeed blank?

If the type lib is indeed blank and the dll doesn't contain it, it's completely possible that the type lib was "private" in the sense that other clients were compiled against it. COM doesn't need a type-lib at runtime necessarily. The pattern for exposing IClassFactory interface implementations is to export a standard DLL function with a well-known signature.

One could easily call LoadLibrary, then call GetProcAddress and cast the result to IClassFactory. From there, they would use the private GUID and IID that they know (not from the type library) as well as the COM interfaces that they have defined privately and work from there.

The only reasoning I can think of for something like this is a form of obfuscation and/or addressing privacy/security concerns, only allowing clients the producer of the server approves of to call it.

It doesn't help you, but could explain why you are seeing a type library with no information in it and at the same time, see other clients consume the library.

casperOne
Thanks for the quick answer, I'll have to do some more digging. But yes I am sure that the TypeLib is incomplete because I have a program that is accessing a class in the COM that isn't in the TypeLib.
Rook
@The Rook: I've updated my answer to reflect the reasons why you might be seeing this behavior.
casperOne
+3  A: 

Not using a type library in COM programming is fairly common. Any scripting language does, it uses IDispatch to discover supported methods and properties at runtime. IDispatch::GetIDsOfNames() or IDispatch::GetTypeInfo() gets that ball rolling. This is called late-binding. It is slow, but that doesn't matter in a scripting language.

Another standard way is through header files generated by MIDL from a .idl file that describes the interfaces and coclasses. You'll find many of them in the Windows SDK include directory, mshtml.h for example. But this is suitable only to unmanaged C/C++ code.

Using COM without a type library in a managed language like C# is difficult but not impossible. VB.NET is the better language, it supports late binding out of the box. C# will get better when version 4.0 arrives, it has a new "dynamic" keyword.

Hans Passant