🚀 go-pugleaf

Christophe MINETTI <cminetti@ulb.ac.be> wrote:

>In fact, it does not matter if it is the processor. What I would like is a
>simple way to get the  ID (a uniwue ID) of the computer on which my software
>is running. My idea was to get the SN of the processor but it can be the
>motherboard or anything else.

Ah, I thought so.

This is an often-asked question, and the answer tends to descend into
philosophy. What is the computer? Does it change when I do a processor
upgrade? A drive upgrade? A motherboard upgrade? A network card change?

The closest to unique tends to be the MAC on a network interface. But
you may or may not have a network interface, and you may have multiple
ones. And though MACs are supposed to be unique, than can be
reprogrammed.

Now, if you aren't after software protection, but just trying to prevent
multiple machines on a network getting confused, writing an entry into
the registry on installation would work. Use CoCreateGUID() to generate
your GUID, and you should have something

  "To a very high degree of certainty, this function returns a unique
   value � no other invocation, on the same or any other system
  (networked or not), should return the same value."

This value should then hang around on that machine's registry until such
time as you do an OS rebuild.

If you wish to prevent the same software being installed more than once,
that's a different problem. There may be a unique UID somewhere in the
registry, but I don't know of one.

Alan Bellingham
-- 
ACCU Conference: 11-14 April 2007 - Paramount Oxford Hotel