Nim binds with importc, which is part of the language, and resolves the library at run time through dynlib — so there are no dependencies and nothing to link. If you chose Nim to ship a small self-contained native binary, the licensing does not change that.
Reading a license
import keynub_licdongle
let ctx = newContext()
defer: ctx.close()
let dongle = ctx.open() # first dongle, or ctx.open("serial")
discard dongle.verifyGenuine() # raises unless genuine
defer: dongle.close()
let session = dongle.openSession()
defer: session.close()
let license = session.readRecord("license")Code language: Nim (formerly Nimrod) (nimrod)defer does the work that a destructor does elsewhere: each resource is released when its scope ends, including when an exception unwinds, and the cleanup sits next to the acquisition where you can see it is there.
The library name is a compile-time define
Which library the binding loads is set with -d:keynubLib=..., so a test build can point at the in-process software dongle while your shipping code knows nothing about it:
nim c -d:keynubLib=keynub_licdongle_sim -r tests/my_licence_test.nim
nim c -d:release myapp.nim # ships against the real libraryCode language: Bash (bash)That is worth having: it means your own test suite can exercise the licensing path in CI with no dongle attached, and there is no code path in the release build that exists only for testing.
The rule that holds in every language: do not branch on a boolean. Encrypt data your program genuinely needs with appEncrypt when you build the product, decrypt it through the dongle at run time, and removing the check leaves the program with nothing to compute rather than a working unlicensed copy.
Code
Runnable sample: nim/verify_and_read.nim. Binding source: bindings/nim. Both are Apache-2.0, in the public SDK repository; the prebuilt native library is attached to each release.
All supported languages · All industries · Buy a KeyNub · Ask us something
