My client wants his software protected from theft (perhaps by an employee selling a copy to a competitor) by blocking it from running unless it is being run from the User’s computer that it is currently running on. I have the logic all worked out, but when tying it by referencing the CPU ID, some of my client’s machines returned the same ID as first stored (encrypted) in a dbf, and on a following run, returned a different ID … so the valid user computer (in some cases) failed to allow the program to run. I’ve since read that CPU ID can do this, and so to avoid it.

I’m now looking at tying to the Serial Number of the motherboard, and found some nice code samples for motherboard S/N, CPU ID, and Hard Disk S/N at http://www.foxite.com/archives/cpuid-and-motherboardid-0000396340.htm by Pete “the IceMan”, but others say it’s better to call the Windows API (working across all Windows versions) rather than the WinMgmts that he uses (but I don’t have any sample API approach code for motherboard S/N to work with anyway). Still others say that BIOS settings can block the motherboard S/N from even being available to me.

I’m almost there, but still just a little short on picking my route. I’m hoping to have a solution that works across all current platforms, including Windows 10, and in both 32 and 64 bit environments. Any thoughts.

Bob