Chilkat ActiveX Object Creation in VB6 (Visual Basic 6.0)

Most ActiveX objects, including Chilkat, provide what is called a “dual interface”.   A dual interface allows for programs to bind at compile-time (early binding) or at runtime (late binding).

The type of binding is determined by how the object is created.  For example, compile-time binding in VB6 looks like this:

Dim cert As New ChilkatCert

Runtime binding looks like this:

Set cert = CreateObject(“Chilkat_9_5_0.Cert”)

An ActiveX class (such as ChilkatCert) has a set of properties and methods.  In the underlying COM object, these are contained in a “vTable”, which is an array of function pointers.  Each method or property (i.e. entry) is a function pointer occupying a particular position in the vTable.  For example, the function LoadPem might be the function pointer at index 12.

When compile-time binding is used, the indexes of the entries are hard-coded into  your VB6 executable.  When runtime binding is used, the entry is called by name.  The name is converted to the correct vTable index at runtime.  This means that if the positions of entries change, the application that uses runtime binding will not break.  The application that uses compile time binding must be recompiled to use the updated ActiveX.

For many years, the positions of the entries in the Chilkat ActiveX classes mostly did not change.  This was not by a deliberate action.  Recently, with the introduction of the Async versions of methods, and especially with the latest v9.5.0.64 release, the order of entries in the vTable has unintentionally changed.  This only affects programs that use compile-time (early) binding.  Most languages that provide the ability to use ActiveX classes, such as classic ASP, SQL Server, etc. only provide the ability to create objects via CreateObject (i.e. runtime/late binding), and are thus unaffected.

This leaves VB6 programs using compile-time binding in a difficult position.  If a new version of the ActiveX is registered, then the VB6 application must be recompiled.  It’s not possible to simply install the new ActiveX *if* the vtbl has changed.  Unfortunately, there is no way to fix the versions of Chilkat that have already been released.  In addition, there is no way to make the next version of Chilkat have the same vTable ordering as previous versions.  For example, if v9.5.0.59 has order A, and v9.5.0.64 has order B, then v9.5.0.65 cannot have and order that matches both A and B.

The solution is to have a scheme in place that works going forward.  The proposed scheme is this:

1. Starting with v9.5.0.65, the vtbl order will become established.  Future versions of Chilkat (where the CLSID is the same) will have vTables with the order of entries matching v9.5.0.65.
2. When Chilkat releases an entirely new ActiveX, where the CLSID changes and the version, for example, becomes 10.0.0, then the vTable order can change.  This is OK because effectively it’s an entirely new ActiveX.  In other words, the CreateObject statement becomes:  CreateObject(“Chilkat_10_0.Cert”) instead of CreateObject(“Chilkat_9_5_0.Cert”).  When the CLSID changes, and the names of the objects change, then it’s a new ActiveX that can be registered and coexist with the older Chilkat ActiveX.  To use the entirely new ActiveX, a VB6 program would have to remove it’s reference from the old, and add a reference to the new. (When adding a reference in VB6, you would see BOTH “Chilkat_10_0” and “Chilkat_9_5_0” and you could choose either.