Permanent ID function (same as FileMaker Pro)

[mwieder]

Richmond-

All that (and more) is available with a one-line shell command.

[richmond62]

I wouldn't doubt it for a minute.

But it would be very nice indeed if one could do everything from inwith a single programming language.

[FourthWorld]

Not everything needs to be written in C++.

What has that got to do with the price of fish?

You had written: "This is the sort of info that it would be useful for a standalone to have access to."

We already do, via a shell call. If you want it built-in, the LC engine is written (mostly) in C++.

[mwieder]

But it would be very nice indeed if one could do everything from inwith a single programming language.

Ah, there I disagree.
My working definition of "programming" is getting a language to do something that isn't already built in.
You don't need to write a "print" command (in most cases) because the language already has one.
For the things you *do* need to write, the language gives you the tools to start being creative.

And here LiveCode gives you the hooks to do what you want, but only if you need it. And that avoids bloat because you're not carrying around the weight of lots of things that *could* be built in to the language but aren't always needed.

[richmond62]

[/quote]
via a shell call.
[/quote]

But, aren't shell calls different for different operating systems and architectures
which rather begs the question?

[mwieder]

It doesn't really. Use the builtin calls to figure out what operating system you're running on, then make the appropriate shell call.

[bogs]

It may be time to check the level of the sand

[FourthWorld]

It may be time to check the OP: while system profiles, OS integration, and philosophies about the appropriate boundaries of a scripting language are fun and useful, the OP is seeking a way to identify a specific device ID for the purpose of software security.

Should I move the bulk of these three pages unrelated to this thread's support request to a new thread?

[bogs]

Works for me.

[mtalluto]

I would be interested to learn more about the specifics of a scenario where hardware identification is truly needed.

We do this for our visual acuity testing system and medical records system. The reason was that we were experiencing a high level of theft. I am one of those rare people that do not view software piracy as beneficial. I get enough marketing value in more traditional ways.

Building a unique fingerprint for the hardware is not complicated. Making it so that your protection system does not get in the way of a legitimate end-user is where you will spend some time.

We solved the details, and we are happy with it. Our customers for this particular software are very vertical. It is a specialized software that is a bit expensive as most clients need to buy anywhere from 1 to hundreds of licenses.

• A customer can install the software again on the same hardware, and it will just work.

• A customer can replace their hardware and run it in a trial mode for 30 days. They send us the new fingerprint, and we turn off the old system and transfer the license to the new unit.

• The customer can choose to get a license that does not require any internet check-ins. This model comes with a fee should the customer want to change hardware without giving our licensing system access to the internet. The typical story is that the equipment died and they already trashed it. We still turn off the old license. It may take a few years, but some IT person will eventually connect that *dead* unit back into the internet and you can guess what happens next. A sheepish phone call, credit card please, and everyone is back in business.

• The customer may optionally decide to accept our free internet licensing model. This model allows them to change hardware as often as they like without fees.

• The system weights the various hardware pieces we gather when making the fingerprint. Should one piece get changed out, our system can allow it. We get notified and make a rational choice on the matter. Usually, they are changing out their harddrive our NICs. No harm, no foul

• Sometimes they try going offline and change their clock back in time to trick the license. That does not work. Going back online will auto-correct everything.

We built a CRM around our licensing system. When a customer calls, they give us this their fingerprint, and we can look up their order. The CRM provides us a lot of data about the customer. We can see their hardware, memory, CPU, OS version, etc. It allows us to get the details that are otherwise difficult for some users to gather. Tech supporting a customer with data like this makes it a pleasure.

All of our mobile software is free in the sense that it is a helper app to the core product. Thus, we only use a UUID for identification purposes. There is no way to over-install our software on those platforms. It only means they are happy with the core product and are still paying their monthly fees.

[FourthWorld]

Thanks, Mark. It sounds like you're deriving an identifier from a variety of elements, rather than depending on a MAC address or motherboard serial number alone, yes?

[mtalluto]

Correct. We capture memory, graphics card, hd, motherboard, MAC address and a few other tidbits about the user.

[FourthWorld]

Correct. We capture memory, graphics card, hd, motherboard, MAC address and a few other tidbits about the user.

Can you share how you obtained the motherboard ID?

[bogs]

Mark, I'm actually curious about the rest of the points brought up as to why this type of thing shouldn't be included in Lc, so (I hate to burden you with time consuming questions but...)
1. How many Os'es supported by Lc do you deploy too ?
2. How much time (if you remember and the answer to 1 is > 1) did you spend looking up the information to get the parts you needed from each Os?

@Richard - you seem to be focused on just the MB and MAC of the nic, and in the case of this OP's question that is sufficient, but what Richmond, I, and all the others in the previous posting were looking for was more along the lines of what Mark figured out, how to get real information about (ALL) the real hardware on a system.

Mark's case is for licensing, which I STILL think is probably the predominant way the information is used is reason enough, but there are other test cases such as I brought up previously, like benchmarking, platform ability, compatibility, etc.

For all those and others, you can't take the least accurate view the Os itself provides, you need to know what the Os is running on.

Now, you can say "Well, if you need it it is easy and you should be able to just shell out (in each instance of different Os) and get it", however it isn't that easy even to shell out on every Os. Even the better supported ones like OSX the shell doesn't always connect, for one thing. The other way to put that is, if it is sooooooo easy to get, why is it soooooooo hard to just include it in the language?

[AxWald]

Hi,

if it is sooooooo easy to get, why is it soooooooo hard to just include it in the language?

Lemme guess:

It's not in the language 'cause every OS provides a way to obtain this information quite easily (or not at all).
But these ways are different, 'cause every OS cooks it's own soup. Each provides different information in more or less small, different packets, and LC would need to create a "common denominator" to have a single cross-platform function, condensing these.
This would require several OS function calls, so would be relatively slow (try "systeminfo" on Win ...), and still wouldn't provide all relevant info, 'cause some OS may simply not give it. Better no LC function than a slow & sloppy one.

The very few that need such specialized data can already obtain their information via simple shell calls.

Have fun ;-)