twinBASIC opens a VB6 .vbp directly and consumes the same COM server, so if you are migrating a VB6 project, the licensing code comes across unchanged. Start from the VB6 page — everything there applies.
The Two Differences That Matter
Bitness. twinBASIC can build 64-bit, so register the 64-bit KeyNub.dll for a 64-bit build. VB6 is 32-bit only, so a project that targets both needs both registered.
twinBASIC implements CDecl properly. That means you could skip COM and call the flat C API directly with Declare ... CDecl, which VB6 cannot do. The SDK documents that route with its trade-offs: you give up the automatic close on dropped reference, you give up Err.Description, you handle the two-call buffer convention yourself, and the code stops compiling in VB6.
If you maintain both: a green twinBASIC build does not prove the VB6 build works, because twinBASIC gets CDecl right where VB6 does not. Test the VB6 target in VB6.
Registering the Server
Copy the KeyNub.dll matching your application’s bitness next to your executable or anywhere on the PATH, then register it once with regsvr32. Elevation is not required: the server registers machine-wide when it can and falls back to the current user when it cannot, so an ordinary prompt works, and regsvr32 /u cleans both locations.
Use the SysWOW64 copy of regsvr32 for a 32-bit build and the System32 copy for a 64-bit one. A mismatch reports class not registered, which reads like a registry fault rather than the bitness problem it is – an in-process COM server can only be loaded by a host of its own architecture.
Shipping the COM Server with a twinBASIC Application
The binding is a COM server, KeyNub.dll, because VB6’s Declare statements emit stdcall calls and the SDK’s C API is cdecl; in a 32-bit process the two differ and the stack drifts on every call. Copy the DLL that matches your application’s bitness next to the executable or anywhere on PATH and register it once with the matching regsvr32: SysWOW64\regsvr32.exe for 32-bit hosts, System32\regsvr32.exe for 64-bit ones. It is self-contained, one file.
Registration does not need elevation: the server registers machine-wide when it can and falls back to the current user’s HKCU\Software\Classes when it cannot, so a per-user installer works. regsvr32 /u removes both. The COM server is Windows-only.
Questions twinBASIC Developers Ask
Which Build of the COM Server Does a twinBASIC Project Need?
The one matching the compiled target: x86 for a 32-bit build, x64 for a 64-bit build, each registered with the regsvr32 of that bitness. A project that ships both targets ships both DLLs.
Does a twinBASIC Application Need Administrator Rights to Talk to the Dongle?
No, and no driver either: the dongle is a USB HID device that the operating systems handle with their built-in class drivers. On Linux, install the shipped udev rule once so that ordinary users may open it; without the rule the SDK reports access denied and names the cause in its error detail.
Does a twinBASIC License Check Need an Internet Connection?
No. Verification is a local exchange between your program and the dongle over USB: the SDK checks the dongle’s certificate chain to KeyNub’s root and runs a live challenge-response. There is no activation server and no account, so the check works on air-gapped machines.
Who Can Read the License Records on a Dongle?
Anyone holding the dongle: a program opens a session and reads records, and can decrypt data sealed for that dongle. Writing records, erasing them and incrementing counters need your write key. What the dongle guarantees is that none of it is available without the dongle present.
What Are the Hardware Counters For?
Counting things that must not be reset: activations, runs, consumed units, exports. The dongle’s monotonic counters only go up, reading one needs a session and incrementing one needs the write role.
Can a License Written from twinBASIC Be Read by a Program in Another Language?
Yes. Every binding drives the same core library and the same dongle, and records and sealed data are language-neutral bytes. Your issuing tool can be written in one language and your product in another.
Code
Runnable sample: twinbasic/KeyNubDemo.twin. Binding source: bindings/com. Both are Apache-2.0, in the public SDK repository; the prebuilt native libraries are in the repository’s natives/ folder, one per platform.
All supported languages · All industries · Buy a KeyNub · Ask us something
