languages will have the same issues, e.g., Delphi, Ada. It can be illustrated by so-called unprecedented approach it took to produce Delphi 2006 binary compatible Delphi 2007 release: How to add a "published" property without breaking DCU compatibility Objective-C is the most promising competitor to SOM (although not being actively marketed as multi-language platform), and SOM should preferably be compared to Objective-C as opposed to COM as it happened historically. With non-fragile instance variables in Objective-C 2.0 it is the best alternative amongst actively supported. COM, XPCOM are being used actively, but they only manage interfaces, not implementations, and thus are not on the same level as SOM, GObject and Objective-C. Windows Runtime under closer look behaves much like COM. Its metadata description is based on .NET, but since WinRT does not contain special runtime to resolve RRBC issues, like in Objective-C or SOM, several restrictions had to be applied that limit WinRT on procedural level: Type System (C++/CX) A ref class that has a public constructor must be declared as sealed, to prevent further derivation. Windows Runtime Components - Windows Runtime Components in a .NET World Another restriction is that no generic public classes or interfaces can be exposed. Polymorphism isn’t available to WinRT types, and the closest you can come is implementing WinRT interfaces; you must declare as sealed any classes that are publicly exposed by your Windows Runtime Component. Comparison to COM SOM is similar in concept to COM. Both systems address the problem of producing a standard library format that can be called from more than one language. SOM can be considered more robust than COM. COM offers two methods of accessing methods onto an object, and an object can implement either one of them or both. The first one is dynamic and late binding (IDispatch), and is language-neutral similar to what is offered by SOM. The second, called a Custom Interface, is using a function table which can be built in C but is also directly compatible with the binary layout of the virtual table of C++ objects in Microsoft's C++ compiler. With compatible C++ compilers, Custom Interfaces can therefore be defined directly as pure virtual C++ classes. The resulting interface can then be called by languages that can call C functions through pointers. Custom Interfaces trade robustness for performance. Once an interface is published in a released product, it can not be changed, because