How to tell if a library is COM or DCOM?

1.3k views Asked by At

I've been given the task of trying to recreate a DLL that has slight modifications to the original DLL, which will be executed if another program runs. Basically a mocked up version of the DLL for testing/simulating other parts of a larger system.

I've searching to see if there is any method to check if the library is COM or DCOM but have not found any. I am aware of the differences, but given a DLL library, how can I tell if it is a COM or DCOM library?

Additionally, is there any way to swap out a COM/DCOM library with a newer technology but not change parts of the code that call the COM/DCOM library?

2

There are 2 answers

2
sharptooth On BEST ANSWER

Having the executable code alone you cannot tell which it is except that if there're proxy/stub dll shipped with it you can assume it is DCOM.

The visible differences are in how the thing is registered. Digging into registration process can be easy or not so easy depending on how registration is implemented. If registration parameters are hand-glued inside code you'd have to reverse-engineer it the harder way. If registration uses a .rgs file which is stored in resources you can just extract it and see how registration is done. Anyway your best bet is to use a VM and export its registry, then register the component, export the registry again and see the difference - what was added.

2
Robert Moskal On

Wow, you are going old school here!

If I remember correctly any valid COM object is can also participate in DCOM. Isn't the wiring for the remote procedure calls done at the operating system level?

From https://msdn.microsoft.com/en-us/library/aa295360(v=vs.60).aspx:

Once COM was adapted to work across a network, then any interface that was not tied to a local execution model (some interfaces have inherent reliance on local machine facilities, such as those drawing interfaces whose methods have handles to device contexts as parameters) would have the capability of being distributed: An interface consumer would make a request for a given interface; that interface may be provided by an instance of an object running (or to be run) on a different machine. The distribution mechanism inside COM would connect the consumer to the provider in such a way that method calls made by the consumer would appear at the provider end, where they would be executed. Any return values would then be sent back to the consumer. To all intents and purposes, the act of distribution is transparent to both the consumer and the provider.

Such a variety of COM does now exist. DCOM (for ‘distributed COM’), is shipped with versions of Windows NT beginning with version 4.0. Since late 1996, it has also been available for Windows 95 and its derivatives. In both cases, DCOM comprises a set of replacement and additional DLLs, with some utilities, which provide both local and remote COM capabilities. It is therefore now an inherent part of Win32-based platforms, and will be made available on other platforms by other organizations over time.