- Forum
- Windows Programming
- COM & IDL
COM & IDL
How COM uses IDL to make a component usable across variant systems?
I want to know how this works, for example if a vendor developed an algorithm (in C++) that they want to make usable across several programming languages, are the below steps correct?
1)If we assumed the algorithm is implemented in one class, the vendor will write interfaces for all public methods of this class in IDL & then use the MIDL compiler to generate a TLB or OLB file.
2)If a client wanted to use the algorithm logic in java, they would invoke QueryInterface supplying a GUID which is stored in registry or a local manifest file to locate where a particular interface is stored & use it.
3)The java application locates the actual implementation of the algorithm (which can be stored in a DLL) & uses the data types defined in the interface to cast parameters/return values to the local data types in java.
is this correct? & in step 2 how is the implementation located? does it use GUIDs internally as well?
Thank you.
I want to know how this works, for example if a vendor developed an algorithm (in C++) that they want to make usable across several programming languages, are the below steps correct?
1)If we assumed the algorithm is implemented in one class, the vendor will write interfaces for all public methods of this class in IDL & then use the MIDL compiler to generate a TLB or OLB file.
2)If a client wanted to use the algorithm logic in java, they would invoke QueryInterface supplying a GUID which is stored in registry or a local manifest file to locate where a particular interface is stored & use it.
3)The java application locates the actual implementation of the algorithm (which can be stored in a DLL) & uses the data types defined in the interface to cast parameters/return values to the local data types in java.
is this correct? & in step 2 how is the implementation located? does it use GUIDs internally as well?
Thank you.
You talk about Java, but the mechanism is the same in any COM-enabled language. It is basically correct.
The location of the implementation is given by the coclass' GUID. The type library defines the interfaces and optionally one or more coclasses that implement the said interfaces. But this only aids the discovery process. In reality, a type library is an optional item for at least C/C++. Other languages do need it, such as classic Visual Basic.
The COM mechanism searches de coclass' GUID in the registry (HKCU\Software\Classes or HKLM\Software\Classes) and then uses the information there to locate the in-process server or the out-of-process server, then instantiates it and returns a pointer to the object or to the proxy.
If there are incompatibilities with the COM type and the specific language's data types, yes, there's a conversion involved.
The location of the implementation is given by the coclass' GUID. The type library defines the interfaces and optionally one or more coclasses that implement the said interfaces. But this only aids the discovery process. In reality, a type library is an optional item for at least C/C++. Other languages do need it, such as classic Visual Basic.
The COM mechanism searches de coclass' GUID in the registry (HKCU\Software\Classes or HKLM\Software\Classes) and then uses the information there to locate the in-process server or the out-of-process server, then instantiates it and returns a pointer to the object or to the proxy.
If there are incompatibilities with the COM type and the specific language's data types, yes, there's a conversion involved.
Topic archived. No new replies allowed.