COM and CLR RRS feed

  • Question

  • Hi all,

          I read that COM is having contract specification and implementation in binary format and CLR has contract specification in the form of Metadata and Implementation as IL.

    What are the disadvantages of COM having things in binary format??




    Tuesday, May 16, 2006 6:15 PM


  • Your definitions of COM and CLR are reasonable but the issues with COM do not necessarily derive from how they are specified.  COM promised interoperability irrelevant of language.  However in order for this to work you had to limit yourself to a specific subset of types and/or use IDL to fully describe your custom types.  This was necessary because IDL provided the binary compatibility between languages.  However binary compatibility simply means that if you format a call in the correct binary layout that some other language (the COM client) can then use that binary data to invoke a function.  Technically true but language differences caused binary layout to be an important aspect of developing a COM interface.  VB treated strings differently than C++.  Booleans were supported differently as well.  On top of that generalized error handling, array management and memory pointers were all different.  This made COM difficult to get right.  And just forget about lifetime management like C++ had.  Finally since COM was built on top of the existing binary formats there was no way to suck out the needed COM information from a binary so you had to use the registry to identify the COM objects and their interfaces.

    CLR is different.  It actually defines the lowest common denominator from which all languages must derive.  Therefore the CLR can dictate how long objects live, how they are interpreted and how they are marshalled across to other languages.  Using the metadata we still have binary compatibility.  The difference is that the metadata is the same across all languages.  Although there are some features that are not supported by all languages the features that are (CLS-compliant) can be used irrespective of language.  The CLR eliminates the need to define a custom marshalling type (in IDL) for your types, control the lifetime of your objects, implement custom error handling, or even use special marshalling types to share data.  Through the CLR you can use any type that you want and the CLR will deal with the issues behind the scenes.  Note that the CLR doesn't truly eliminate all the issues involved in language interop but it eliminates the ones that caused problems in COM.  The CLR is currently the utopia of compatibility between languages but I suspect that as time goes on we will find limitations in the model and eventually switch to some newer mechanism that solves the CLR compatibility issues and the cycle will continue.


    Michael Taylor - 5/17/06

    Wednesday, May 17, 2006 12:20 PM