>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

I used some coded written in VFP, but these were had handicaps:
-cpu serial finder was working so slowly at some computers, I couldn't found why.
-Mac ID has also different problems; some ethernets were disabling at notebook computers sometimes, that was a trouble.

I'm using this small and cheap dll. It works good for me:

https://www.levelextreme.com/ViewPageNewDownload.aspx?ID=38468