All of the previous discussion has to do with calling methods and accessing properties through IDispatch. If you have a controller that understands enough about type information to generate arbitrary calls to IDispatch, then it will probably also be sophisticated enough to generate calls to vtable-based functions in either custom or dual interfaces. This is a bit trickier, of course, because calling these functions requires you to build a stack frame and process return values from registers—operations that are usually machine dependent.
I can't say that I've actually tried to make a generic vtable calling routine, but I suspect that it could be done with an assembly language function that took the interface pointer to call, the offset in the vtable of the function to call, the calling convention to use, and an array of VARIANTARG structures. This function would push each VARIANTARG onto the stack in the order appropriate for the calling convention, make the actual call, clean up the stack as necessary (for the cdecl calls, for example), and put the return value in the correct registers. This would be the only machine-dependent piece of code in the whole application.
I also suspect that you could get away with a similar scheme involving the use of a variable argument C function with some in-line assembly. The act of calling this function would possibly generate most of the stack frame automatically, whereas the function itself would tweak the stack, make the call, do some cleanup, and return.
In either of these cases, it's possible to call vtable functions in custom and dual interfaces without having machine-dependent assembly invade your source code.