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.
There is a consequence worth knowing if you maintain both: a green twinBASIC build does not prove the VB6 build works, precisely because twinBASIC gets CDecl right where VB6 silently 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.
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
