Software License Dongle for Visual Basic 6 (VB6)

Visual Basic 6 applications are still shipping, still selling, and still worth protecting. KeyNub supports VB6 through a COM server — not a set of Declare statements — and the reason is worth understanding before you integrate anything.

Why a COM object and not Declare statements

The KeyNub core library exposes a flat C API using the cdecl calling convention. VB6’s Declare statement emits stdcall. In a 64-bit process this distinction does not exist, which is why the VBA binding works fine in 64-bit Office. In a 32-bit process — and VB6 is always 32-bit — neither side pops the arguments off the stack, so the stack pointer drifts a little with every call until something falls over, somewhere else, much later.

VB6 has a CDecl keyword, but it is documented as Macintosh-only and is ignored on Windows. So there is no correct way to call a cdecl library from VB6 with Declare. COM removes the problem entirely: the type library describes the contract, and the marshaller handles the call.

You also get three things worth having:

• The object owns the dongle. If an early Exit Sub skips your Close call, releasing the reference closes it anyway. No leaked handles.
• Real error messages. Failures raise with Err.Description carrying the SDK’s own diagnostic text, not “Automation error”.
• Byte arrays are just Byte arrays. The interface uses SAFEARRAYs, which is what a VB6 Byte() already is. No pointer arithmetic, no CopyMemory.

Installing

Register the DLL once, using the regsvr32 that matches its architecture. VB6 is 32-bit, so on 64-bit Windows that is the one in SysWOW64:

C:\Windows\SysWOW64\regsvr32.exe KeyNub.dllCode language: Bash (bash)

The type library is embedded in the DLL as a resource, so there is one file to deploy and registration-free (side-by-side) activation also works if you would rather not touch the registry on customer machines. An unelevated regsvr32 falls back to a per-user registration instead of failing.

A wrong-bitness DLL reports “class not registered”, which reads like a registry fault and is not. If you see that, check the architecture first.

Reading a license

Late binding, so it runs with no project references configured:

Dim dongle As Object
Set dongle = CreateObject("KeyNub.Dongle")

' No dongle plugged in is a normal situation, not an error. Ask first.
If dongle.DeviceCount = 0 Then
    MsgBox "Please plug in your KeyNub license dongle."
    Exit Sub
End If

dongle.Open ""                  ' first dongle found; pass a serial to pick one

If Not dongle.IsGenuine Then
    MsgBox "This dongle is not a genuine KeyNub."
    Exit Sub
End If

dongle.SessionOpen              ' encrypted session, required before records

Dim license() As Byte
license = dongle.RecordRead("license")

dongle.CloseCode language: VB.NET (vbnet)

For early binding, add the KeyNub License Dongle reference to your project and declare Dim dongle As New KeyNub.Dongle. You then get IntelliSense and the object browser, because every member carries a help string.

Handling errors

Failures raise. The numbering is stable and documented, so you can branch on it:

On Error GoTo Failed
    dongle.SessionOpen
    Exit Sub

Failed:
    ' Err.Number is vbObjectError + 5000 + the SDK status code.
    MsgBox "KeyNub error " & (Err.Number - vbObjectError) & _
           ": " & Err.DescriptionCode language: VB.NET (vbnet)

The one deliberate exception is IsGenuine, which returns False rather than raising when no dongle is present — a license gate should fail closed, not blow up.

Do not gate on a boolean

This is the part that decides whether the dongle is worth anything to you:

' Weak -- one patched jump defeats it.
If dongle.IsGenuine Then EnableFeature

' Strong -- the data your program needs only exists with the dongle present.
Dim coefficients() As Byte
coefficients = dongle.AppDecrypt(EncryptedBlobFromYourInstaller)Code language: VB.NET (vbnet)

Encrypt the constants, tables, thresholds or key material your application genuinely cannot compute, ship them encrypted, and decrypt them through the dongle at runtime. Scope them to keynubScopeDevice so only that one physical dongle can decrypt, or keynubScopeDeveloper so any dongle from your batch can.

twinBASIC

twinBASIC opens a VB6 .vbp directly and consumes the same COM server, so the code above is unchanged. Two differences: twinBASIC can build 64-bit, so register the 64-bit DLL for a 64-bit build; and twinBASIC implements CDecl properly, so you could call the flat C API directly. The SDK documents that route with its trade-offs — you lose the automatic close and Err.Description, and it no longer compiles in VB6.

Honest status

The COM interface, its type library, the marshalling and the error numbering are tested on every change to the SDK, on both 32-bit and 64-bit, through both the vtable and IDispatch. What we cannot automate is the VB6 IDE itself — Microsoft no longer supplies it, so no build server can legally run it. The VB6 sample project ships with the SDK and is intended as bring-up on your machine. If anything in it does not behave, we want to hear about it.

Sample project: SDK/samples/vb6/KeyNubDemo.vbp. See all supported languages or ask us a question.