Permanent ID function (same as FileMaker Pro)

[bogs]

I see, I think we have a matter of interpretation here, concerning the word 'backup' and it's context in this situation.

Your interpretation appears to be that the backup being restored contains the value and it doesn't change.

My interpretation is that the function is still called, even in that case, and that is why you'd get a different value on a different device. I think that is the only way it makes any sense.

Otherwise, you wouldn't see the 1st part of that sentence,

If a FileMaker Go user restores an iOS backup to a different device, the value returned by Get(PersistentID) changes.

I believe backup or no, the program calls that function and, if the hardware is the same, you get the same ID. From what is written there, I'm not sure how you come to any other conclusion.

Further, it says as much in the part you apparently didn't see in my original post above Ax's, which is -

On an iOS device, Get (PersistentID) will return the MD5 hash value of the Mac address of the device.
On Macs, Get (PersistentID) returns the MD5 hash value of the Hardware UUID as seen from "About this Mac -> More Info -> System Report -> Hardware"
On Windows, Get (PersistentID) returns the MD5 hash value of the UUID when you type the command line:
wmic path win32_computersystemproduct get uuid

...so it is blatantly obvious that it is, indeed, using a hardware based hash.

If you truly must have a motherboard-ID-based UUID-like ID, go for it.

I just think it is an option that makes good sense to have. You obviously don't. No harm, no foul in my court, hopefully not in yours either.

In fact, Joan hasn't returned since the original post. Everything written after that beyond a handful of questions for Joan is based solely on conjecture about the true requirements of the use case. We'll see how it pans out when Joan returns.

True that, I was waiting as I mentioned when replying to Ax's post, that post just made me curious, same as your responses. Good thing I'm not a cat, eh?

[FourthWorld]

UUIDs based on RFC 4122 Version 1 use MAC address as a component of the derived value. Perhaps FMP's implementation does that; being closed-source we can't read the code, though I suppose we could ask their Support and see what they share.

Either way, it doesn't seem to be specifically motherboard-ID-based, so if that turns out to be a requirement we'll need to learn from Joan how FMP's implementation is suitable but LC's is not.

I just think it is an option that makes good sense to have. You obviously don't. No harm, no foul in my court, hopefully not in yours either.

Note that I expressed no opinion about the utility of a specific form of a UUID for all possible use cases. All I wrote was that most use cases are well satisfied by the RFC 4122 v3-5 implementations; of course "most" is a subset of "all. I explicitly acknowledged that without knowing the specifics of Joan's requirements everything written here is conjecture.

The limitations with FMP's implementation do not seem dramatically different from LC's, so it's at least worth knowing about. For most app devs in most languages, RFC 4122 suffices quite well, where uniqueness is provided by the algo and persistence is provided by the file system.

If you have an app that truly needs hardware-bound UUIDs, and the caveats listed in the link AxWald provided about MS' implementation don't apply, I've already encouraged you to pursue it and will continue to do so. When it comes to options for devs, more is better. Go for it.

For this thread it might be what's truly needed. Or not at all. We can't know until Joan returns.

[jacque]

I think the short answer is that you can't reliably obtain the hardware ID on a mobile device. Apple restricts this on iOS. It looks like Android does too sometimes but that may be based on either the system version or the manufacturer. On my Huawei tablet running Android 9 I get a result. On my Pixel running Android 10 I get "unknown".

[AxWald]

Hi,

Again, how often do you suspect average people are changing out hardware in their systems?

Depends of the definition of "average people" ;-) Lemme give you some use cases where the hardware changes:

• It's common even for small companies to lease their computers. These are exchanged then every 2 or 3 years, often w/o extensive prior warning (for the user & YOU).
• When a mobile gadget cracks, it's rarely repaired these days - it's replaced with a refurbished one. Some producers design their mobiles, and prime their legal departments, especially to rule out any 3rd party repair. You know who I'm talking of ;-)
• One of the brood gets a new computer. Pa gets brood's old one. Ma gets Pa's old one. Ma's old one is sold to the prehistoric museum.
• Last but not least: There's things like thunder & lightning, blackouts with voltage surges, exploding UPS', burglaries. Companies will often have service agreements & will get replacements very fast - I've seen Compaq (RIP!) arrive within 3 hours, with 2 vans full of hardware and 6 emergency technicians, after a power spike that grilled every computer in a house. Within 3 more hours the company was functional again. Because the software wasn't locked down to the hardware.

You see, depending on where your program runs, hardware changes. Not everyday, but every so often.
And there are other cases where a "hardware lock down" will fail miserably:

• User profiles on a server, and changing workspaces - these hip bureaus where you don't have a fixed workspace anymore, where you sit down wherever it pleases you today. Or simply classical Windows domains in a company where you log in to your profile from where ever you need access to your programs & data. As long as this isn't done with RDP/ VNC/ Citrix (ouch), you're on a different machine, each time.
• Remote access & load balancing. You'll never know on which server your session/ program runs! And many serious remote access environments will have at least 2 servers.
• Any kind of virtualization, containers etc. You'll drown in the can of worms you opened when working with hardware UUDS on such systems, especially when you don't provide this environment yourself.

Have you read the link I provided about SMBIOS UUID FAILs in the wild, on Win machines? This is exactly what the FMs identifier uses.

As mentioned above, it all depends of the use case. If it's a puzzle app for the brood's iGadget, lock it down if it makes you happy. You'll not suffer much if the brat needs to live a weekend w/o your puzzle.

But if you write mission critical software for companies, where a 2-day blackout of your program can cost real $$$, think twice.
The PCs, or the server that got grilled by friday night's lightning may be replaced within hours, including the restore.
But if your program then refuses to start reclaiming "This isn't an authorized machine! NagNag!" on saturday morning, when the house is full of customers, you have a very, very angry client. And when you come back from your vacation on monday morning, be ready for very, very unpleasant surprise. Been there, seen that. And was very, very happy it wasn't me that got flattened.

My 2 cents: Hardware lock down is evil, and will come back to bite your privates. Avoid it.

Have fun!

[bogs]

Depends of the definition of "average people"

I certainly do not count businesses as 'average people'. Of course, I also have no idea who Joan is targeting either.

I did (and still do) think there are plenty of reasons to have hardware ID down, but that is just me.

My 2 cents: Hardware lock down is evil

I said the exact same thing when MS started using it to tie their operating system to, so it isn't like I don't get your point, but hardware ID can be useful for far more than just locking down software.

[richmond62]

I don't know about hardware IDs, but it is useful
to know the physical characteristics of any hardware one
might be running one's software on.

Code: Select all

on mouseUp
put the machine into fld "ff"
end mouseUp

-

-
The Documentation misses quite a bit:
-

-
I wonder if that can differentiate between x86, x86_64 and ARM?

[bogs]

I wonder if that can differentiate between x86, x86_64 and ARM?

It will only report what the OS is reporting as indicated in your previous thread on the topic, and apparently that is what is what is desired by every one else.

[mwieder]

I wonder if that can differentiate between x86, x86_64 and ARM?

put the processor

[bogs]

Sorry Mark, that line of thought was also pursued in the previously mentioned threads. In the one I directly linked too, you had an interesting idea about expanding one of the possible choices, but alas, it was still shot down.

Gee, my bios says amd 64 rana...

aPic_theProcessor.png (9.34 KiB) Viewed 5251 times

[mwieder]

Hmmm... I'd forgotten about the previous post, but I still think "the processor" answers Richmond's question. An ARM build will only run on an ARM processor, so a return value of "ARM" here will indicate both that the build was generated for ARM processors and that it's running in an ARM environment.

[bogs]

Dunno, he (and I) are looking for a cross platform solution to finding out the *real* actual physical hardware, as he said there and here -

I don't know about hardware IDs, but it is useful
to know the physical characteristics of any hardware one
might be running one's software on.

All of the available commands in Lc, regardless of what the dictionary says (which I was told I was misinterpreting the meaning of hehe) only report what the most generic part of the OS reports. In that thread, I pointed out your only ever going to get that, which isn't necessarily the real processor.

For instance, if your running on a 32 bit OS, your going to see a 32 bit cpu reported, regardless of what is actually powering your system. Off the top of my head, I don't know if ARM supplies 32 and 64 bit cpus (I suspect they do), but let us say they do not. At that point, what is the purpose of using anything to id it?

If they do, Lc will blindly tell you whatever the OS variant says your running on, but not the underlying hardware, just as it does on 'nix.

There are certainly ways (on most platforms) to get the actual hardware your running on from the CLI, but if you are going to start saying you should have to learn the arcanna of each and every platform, that seems a dark alley to go down.

[richmond62]

a dark alley to go down

I prefer the front door.

I would suppose that "someone clever at LiveCode central" might know how to roll stuff into LiveCode so one
did not have to dress up as Saruman to get at hardware details.

Yes: before you mention it, "someone clever at LiveCode central" was meant to be highly manipulative and coercive.

[richmond62]

-
This is the sort of info that it would be useful for a standalone to have access to.

This from: https://www.micromat.com/products/machineprofile

[FourthWorld]

Isn't there something in Michael Doub's Master Library for that?

LiveCode Script is a pretty good language. Not everything needs to be written in C++.

[richmond62]

Not everything needs to be written in C++.

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