WinRT gets around it because it doesn't really export C++ the way you're thinking. What it exports are basically COM objects with a bunch of extra CLR-style me

WinRT gets around it because it doesn't really export C++ the way you're thinking. What it exports are basically COM objects with a bunch of extra CLR-style metadata. COM avoids the C++ issue because it only allows you to consume interfaces, and, for all Windows compilers when COM was invented (and obviously since), vtables are always in a set location. So the trick is: 1. Never change existing interfaces 2. Always add new interfaces to the end of the vtables When you want a COM object, you instantiate it, but you don't work with it directly; you ask for the interface you want to use to talk to the object. As long as the object vendor maintains the old virtual methods, the worst that happens is you ask for the old interface and everything works as normal. This works very well with only a minor speed hit. I think right after //build, I could tell you how they used CLR metadata to extend the system out to supporting subclassing, but I just honestly don't remember. Similar general idea, though; they still avoid the problem by not actually hitting it.