I saw that the Mac addresses command:
SystemStats::getMACAddresses()
got removed lately …
I was using it for a quick check to make sure that key files had not changed computers (copy protection).
So … is there some other way I can get a system unique variable of some sort? Or is there another intended way to do app/key copy protection with juce?
Thanks -
a
I replaced it with the MACAddress class - I guess I should post that to the sticky thread…
Ah … great. I figured it would be something like that … thanks for the heads up.
Hi, it looks like I took my eye off the ball and missed the new MACAddress class. But in between the SystemStats::getMACAddress method and this class being introduced, getMACAddress turned into getMACAddresses, which returned a list of addresses. This is what I have in my current released builds.
So, my problem is, on some Mac machines this is returning lots of MAC addresses but only the one or two of them remain constant. The rest seem to change each time the program is run. One or two of my users are reporting problems that sound like all of their ‘MAC addresses’ could be changing each time they run.
Jules: do you recall any problems like these before you introduced the new MACAddress class? Did the introduction of the class fix anything like this? Can anybody tell me what all these MACAddresses actually relate to in terms of the hardware we’re running on.
Any help very gratefully received!
Thanks,
Bennie
Sorry to bump this but I really need to know why the values being returned from getMACAddresses are changing on each run and what this method actually returns. I have several customers at remote sites who are going to need refunds if I don’t fix this very soon and it’s hard to come up with a good fix if I don’t know what the API is returning.
If the hardware only has one network card (or even none at all) and I ask for the first ten MAC addresses what will I get? An array of zeros? Or some believable looking but constantly changing values?
I’d love to sync up to the tip but I need to get a fix out to these customers quickly so I don’t have time to sync up and re-test. I need to make this work with the version of Juce I released with.
Thanks and best wishes,
Bennie
As a work-around could you go back to the older version of Juce that worked, extract just the source code for the original MACAddress implementation that functioned as expected, rename it, and use that instead?
Which OS is it that you’re using?
@TheVinn: that’s a great idea. Not sure why I didn’t think of doing that but I didn’t! Thanks!
@Jules: The problem has been reported on both Mac OS 10.5, 10.6 and Windows XP. I’d still love to know the root cause of this just in case the old getMACAddress code doesn’t work consistently on these users’ systems.
MAC addresses are becoming a bit useless for copy-protection nowadays… In the old days a machine might have a couple of addresses that stayed constant, but these days you get things like VM software that generates lots of temporary fake addresses on the fly, making them much less reliable than they used to be.
I did change the way they were detected a few months ago, because the old methods I was using had become a bit out-of-date. The newer code will probably find more addresses than the old code did, but should still find all the old addresses that it used to.
Whenever I’ve used MAC addresses in my own copy-protection, I tend to keep a list of all the addresses, and then when checking, I’d consider it a positive match if at least 1 or 2 of them remain constant. Not very reliable, but there’s no way to tell the ‘fake’ ones from the real ones any more.
Ok, thanks for the info. I’ll try and come up with something. So do you think there’s any point rolling back the code I’m using to use the old getMACAddress Juce code? Or is it possible the value returned by this code may still change even when the hardware doesn’t change, when run on newer operating systems?
All I can say is that the newer code will find more of the mac addresses on your machine - I can’t tell you whether the extra ones it finds are “better” or “worse” than the others…
