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.
nimble install keynub_licdongleCode language: Bash (bash)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 build can name the library explicitly when it is not on the default search path:
nim c -d:keynubLib=keynub_licdongle -r tests/my_licence_test.nim
nim c -d:release myapp.nimCode 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 libraries are in the repository’s natives/ folder, one per platform.
All supported languages · All industries · Buy a KeyNub · Ask us something
