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.

 

Chilkat ActiveX MSI Installers

Chilkat may begin providing .msi installers for the 32-bit and 64-bit ActiveX components. Here are .msi installers for testing:

(version 9.5.0.56)

Chilkat 32-bit ActiveX MSI Installer
Chilkat 64-bit ActiveX MSI Installer

Installing the .msi should register the ActiveX. The .msi also includes the required MSM merge module for the VC++ 2008 runtime.

To check the registration, run the CheckChilkatActiveX.exe program that is located in the install directory
(such as at C:\Program Files (x86)\Chilkat Software, Inc\Chilkat 32-bit ActiveX\CheckChilkatActiveX.exe,
or at C:\Program Files\Chilkat Software, Inc\Chilkat 64-bit ActiveX\CheckChilkatActiveX.exe

How to Register an ActiveX DLL using regsvr32

The first step is to determine if you need to register the ActiveX DLL compiled for 32-bit or 64-bit.  If your computer is 32-bit, the choice is obviously 32-bit.  Let’s start with it:

How to Register a 32-bit DLL on a 32-bit Windows operating system

  1. Using a text editor, create a .bat file in the same directory as the 32-bit DLL.
  2. Insert this line in the .bat file:
    regsvr32 "%CD%"\myActiveX.dll
  3. Run the .bat “as Administrator”. regsvr32 will be trying to create entries in the Windows registry, so it may need administrative privileges.

    * On Windows 7, open an Administrator command prompt by going to the Start Menu, enter “cmd” in the search box and instead of pressing Enter, press Ctrl+Shift+Enter. Change directories to where the DLL’s and the batch script are located, and run the registration batch file from there.

regsvr32 on 64-bit Windows

If the computer is 64-bit Windows, it’s possible you still may need the 32-bit DLL.  It depends on whether your application runs as a 32-bit process or a 64-bit process.  If using the ActiveX from ASP, check to see if IIS is running in 32-bit mode or 64-bit mode.  If 32-bit, the 32-bit ActiveX needs to be registered.  Likewise, if IIS is running in 64-bit mode, register the 64-bit ActiveX DLL.   For VB6 apps, it will always be 32-bit because VB6 is older and there is no such thing as a 64-bit VB6 app.  This may also apply to older versions of other programming languages such as Delphi, FoxPro, etc.

If you are unsure, there is no harm in downloading and registering both 32-bit and 64-bit DLLs.  64-bit Windows has separate registries for 32-bit and 64-bit, so both may be registered.

How to Register a 32-bit DLL on a 64-bit Windows operating system

  1. Using a text editor, create a .bat file in the same directory as the 32-bit DLL.
  2. Insert this line in the .bat file:
    \windows\syswow64\regsvr32 "%CD%"\my_32_bit_ActiveX.dll

    It is the 32-bit version of regsvr32 that must be used to register the DLL in the 32-bit registry. We use the full path to regsvr32 to make sure we’re running the 32-bit version.

  3. Run the .bat “as Administrator”.

    * On Windows 7, open an Administrator command prompt by going to the Start Menu, enter “cmd” in the search box and instead of pressing Enter, press Ctrl+Shift+Enter. Change directories to where the DLL’s and the batch script are located, and run the registration batch file from there.

How to Register a 64-bit DLL on a 64-bit Windows operating system

  1. Using a text editor, create a .bat file in the same directory as the 64-bit DLL.
  2. Insert this line in the .bat file:
    \windows\system32\regsvr32 "%CD%"\my_64_bit_ActiveX.dll

    It is the 64-bit version of regsvr32 that must be used to register the DLL in the 64-bit registry. We use the full path to regsvr32 to make sure we’re running the 64-bit version.

  3. Run the .bat “as Administrator”.

    * On Windows 7, open an Administrator command prompt by going to the Start Menu, enter “cmd” in the search box and instead of pressing Enter, press Ctrl+Shift+Enter. Change directories to where the DLL’s and the batch script are located, and run the registration batch file from there.

Using regsvr32 to Register a 32-bit ActiveX or 64-bit ActiveX on Windows 64-bit System

A 64-bit Windows system has two separate registries — one for 32-bit processes, and one for 64-bit processes. The reason for this is simple: Let’s say your application instantiates an instance of an ActiveX component by calling CreateObject(“Chilkat.Ssh”). If your application is running in a 32-bit address space, the registry entries for “Chilkat.Ssh” should point to a 32-bit DLL in the filesystem. However, if your application is running in a 64-bit address space, the registry entries should point to a 64-bit DLL. The only possible way to do it is to have separate registries — one for 32-bit and one for 64-bit.

On a Windows 64-bit computer, the regsvr32 program (located in \windows\system32) is a 64-bit program that registers a 64-bit ActiveX DLL using the 64-bit registry. For example:

regsvr32 ChilkatSsh_x64.dll

On Windows x64, regsvr32 expects a 64-bit DLL and updates the 64-bit registry.

To register a 32-bit ActiveX DLL in the 32-bit registry, you’ll need to run the regsvr32 located in \windows\syswow32. For example:

cd \windows\syswow64
regsvr32 c:\ChilkatSsh.dll

It’s important to know whether the program that will be loading the ActiveX is 32-bit or 64-bit. For example, IIS on Windows 64-bit can run as either. If IIS is running in 32-bit mode, any ActiveX’s used in your ASP pages should be 32-bit DLL’s registered in the 32-bit registry. Likewise for 64-bit.

The same conditions apply for other environments, such as SQL Server 2008. Is the database server running as a 32-bit process or 64-bit process? If an ActiveX is used within a stored procedure, make sure the appropriate DLL is registered to the appropriate registry…

Error 0x8002801D when Instantiating Chilkat HTTP ActiveX

This error indicates that there is a
problem with the registry information for the ActiveX DLL. The registry
entry may be missing or contain incorrect information, or the user may
not have permission to read the registry entry.

In ASP, the error message may look like this: 
Server object error ‘ASP 0177 : 8002801d’

In applications, you may see an error message such as this: 
OLE error code 0x8002801d: Library not registered

First try unregistering and re-registering the DLL.  On the computer or server where the ChilkatHttp.dll is located, open a DOS prompt and “cd” to the directory where the DLL is located.  Then unregister by typing:

regsvr32 -u ChilkatHttp.dll

Next, register the ActiveX DLL by typing:

regsvr32 ChilkatHttp.dll

If it fails, then create a .bat file in the same directory as the DLL.  Type the “regsvr32 ChilkatHttp.dll” command into the .bat script.  Right-click on the .bat and select “Run as Administrator”.  This should register the DLL.   Check to see if the problem is resolved in your ASP page or application.

Finally, if the problem remains, it could be a permissions problem. (I have no idea why the permissions
might be different..) In any case, please see the information at this Microsoft
support knowledge-base article. It provides details about changing the
registry entry permissions so that your ASP code has permission to read
the registry entries:

http://support.microsoft.com/kb/274038