Wrapping an existing COM object
-
Hi, I'm not sure if this is possible, or whether it's been answered before but I've reached meltdown trying to guess the key phrase to get information on this. What I have is: - an existing COM DLL + idl etc which is installed in location A What I'd like to do is: write a new version of the DLL supporting the same interfaces as A so it is a complete replacement for A. However, I actually want to use the original DLL to do all the work. All the new DLL is for is to journal calls in and events out of the original and forward responses back to the client application. It may eventually multiplex information elsewhere, but that's the future. Any help would be greatly appreciated. I've been staring at MSDN too long to actually read the COM API clearly :sigh: Thanks. Kev
-
Hi, I'm not sure if this is possible, or whether it's been answered before but I've reached meltdown trying to guess the key phrase to get information on this. What I have is: - an existing COM DLL + idl etc which is installed in location A What I'd like to do is: write a new version of the DLL supporting the same interfaces as A so it is a complete replacement for A. However, I actually want to use the original DLL to do all the work. All the new DLL is for is to journal calls in and events out of the original and forward responses back to the client application. It may eventually multiplex information elsewhere, but that's the future. Any help would be greatly appreciated. I've been staring at MSDN too long to actually read the COM API clearly :sigh: Thanks. Kev
You can import the idl file in your new idl file to get the interface information from the old file. Please see the MIDL statement
import. Note that the compiled DLL will not depend on the old DLL. You can opt to install only the new DLL on the target system. Another way to do it is to#import(VC++ feature) the DLL and its associated type library into your C++ code. A third way to do it is to grab the header file generated by the compilation of the IDL file beloning to the old DLL, and#includeit in your new sources. Personally, I importimportin the IDL file. Please note that by doing so, the corresponding header file of the imported IDL file, must also be accessible to the C++ compiler. At work I have an include files in one directory and IDL files in another (you can have them in one directory if you're not so anal about order it as I am :rolleyes:). I have added those two directories to the include search path in the IDE. That way MIDL finds the idl-file, and the C++ compiler finds the corresponding header file. -- Arigato gozaimashita! -
You can import the idl file in your new idl file to get the interface information from the old file. Please see the MIDL statement
import. Note that the compiled DLL will not depend on the old DLL. You can opt to install only the new DLL on the target system. Another way to do it is to#import(VC++ feature) the DLL and its associated type library into your C++ code. A third way to do it is to grab the header file generated by the compilation of the IDL file beloning to the old DLL, and#includeit in your new sources. Personally, I importimportin the IDL file. Please note that by doing so, the corresponding header file of the imported IDL file, must also be accessible to the C++ compiler. At work I have an include files in one directory and IDL files in another (you can have them in one directory if you're not so anal about order it as I am :rolleyes:). I have added those two directories to the include search path in the IDE. That way MIDL finds the idl-file, and the C++ compiler finds the corresponding header file. -- Arigato gozaimashita!Hi, thanks for replying - all useful information. However, I don't think I made my question clear enough. What I am trying to achieve is to be able to install my binary-compatible version of an exisiting DLL onto a pre-existing system containing the original DLL. My new DLL would register itself and be the DLL loaded by clients of the original DLL. My DLL, because it knows that there is an existing DLL in a known location would be able to the original to provide the clients with identical functionality. If I was using plain DLL's I'd simply be able to install the new version so that it was found earlier in the path and load in the original DLL using LoadLibrary(). Since I know exactly what the interfaces are, I could do this with the COM DLL. However, I'm looking for an "official" COM way of short-circuiting the registry lookup. Kev
-
Hi, thanks for replying - all useful information. However, I don't think I made my question clear enough. What I am trying to achieve is to be able to install my binary-compatible version of an exisiting DLL onto a pre-existing system containing the original DLL. My new DLL would register itself and be the DLL loaded by clients of the original DLL. My DLL, because it knows that there is an existing DLL in a known location would be able to the original to provide the clients with identical functionality. If I was using plain DLL's I'd simply be able to install the new version so that it was found earlier in the path and load in the original DLL using LoadLibrary(). Since I know exactly what the interfaces are, I could do this with the COM DLL. However, I'm looking for an "official" COM way of short-circuiting the registry lookup. Kev
Aha! My foggy brain finally seems to be kicking into gear again. I believe the answer is to: 1) Call CoLoadLibrary() to load the specific DLL into memory 2) Call GetProcAddress() to get the original's DllGetClassObject() function. 3) Call DllGetClassObject() to get the original DLL's class-factory, then off-we-go! Pretty obvious really. Oh well :doh: I'll try this out later on today when shipping-hell lets me. Kev