ActiveX Binary Compatability

Author: Dave
Date: 03.01.20 - 8:35am

Apparently there are some unspoken truths about the finer points of COM binary compatibility that I never realized even after 20 years of extensive use!

This all started the other day when I added a new enum value to a project and didnt realize I had binary compatibility already set. The project compiled fine. When it dawned on me what had just happened, it made me realize the rules to binary compatibility may not be as strict as I had ~~assumed~~ been told.

Early on in my career it was an annoyance not being able to update prototypes and I learned just to not transition to ActiveX to early. Whenever I really wanted a new interface into a library, I would create a whole new MyClass2 and retool it as needed. Occasionally I would just simply break compatibility and recompile/redistribute everything that used that lib if it was still early enough along but that kinda sucks.

What I had always been told about binary compatibility was that once you created a public interface in an ActiveX dll, it was a binary contract and could not be changed no matter what.

This is true, but apparently it is not the whole story. While you cant change what has already been published, you CAN add new stuff to the interface. Below are some tests to explore the limits:

Fails:

changing arg of existing function to byval
adding optional args to existing function
change existing arg to optional
change prototype of a function for implemented class
change a prototype in a not creatable implemented class

Ok additions:

adding new enum values
adding a new function at end of class
adding a new function at start of class
add implements to existing class (not creatable)
return private class from public class as object
change any prototype in this private class

One thing i had been thinking of for a while was to always include a generic prototype into my binary compatibly classes like:

 function futureProof(operation as long, arg1, arg2, arg3)

but this is no longer necessary with the ability to freely add new functions to published classes.

I have been using vb6 for 20 years and ActiveX dlls extensively for this entire time and never realized this finer point.

Another idea I had, in terms of being able to return a private class with no limitations, how do you self document that classes prototypes since VB does not support reflection? Simple answer..vb can support reflection...if we do it ourselves.

We could easily have a self.describe() method that returns a collection of all of the prototypes of the public members in the class along with their help string. It would be a simple task to write a tool or addin which extracts prototypes and auto generates the describe method. The classView addin already has the logic for this. It could even be done automatically on compilation.

With a unified format for this, you could easily integrate it into code completion tools for scripts or build out a .Call() function to then execute the functions "through reflection" from other vb6 code. Its not a common need, but its not beyond our capability to add to the language with CallByName and variants. As a bonus, we get to choose who can reach into our classes rather than having all of our metadata automatically published by a shitty bloated power grabbing framework language like Java or .NET...but i digress...