Time limitation for standalone application

[vtrbojevic]

Hi,

Is there a way to limit the time a standalone application can be used. Something like a) limiting date, or b) number of times it can be executed, etc? I have tried with the date by testing along the lines: If CurrentDate > LimitDate then .. but it is ignored!

Regards,

Vladimir

[massung]

Not sure if any of these ideas will help you, but as a long-time developer of shareware and professional apps that have made use of copy protection schemes and demos (and I see this type of question frequently on the Rev forums)...

>> Putting "trivial" copy protection within the app itself is generally a very bad idea. It takes a novice hacker < 5 minutes to find and crack. I once worked with a shareware cracker who - quite literally - tore my app apart and would email me to gloat every time I put out a new version - just to tell me he did it. I decided to hire him and eventually came up with a protection scheme that he couldn't crack, but it took several months and many iterations to do. I can discuss it in more detail if anyone's interested, but it wasn't done in Rev.

>> With the current state of the "online" world, you have many, many more (and better) options available to limit or otherwise allow people to test your application during a trial period. Some common/good ones:

• Create a dumbed-down version of the app with a few features disabled. Make this your demo version. There's pros and cons to this. Paying users are directed to a (temporary) download URL where they can get _their_ copy of the application. Often times "their" copy is actually constructed by the system based on personal information provided by the user.
• Provide each user with a random UUID on download via email that they use to register their demo version. At launch, the user must be connected to the internet, submit their UUID, and the server returns an "ok" or "err,demo expired" string. Or any number of variations around that. While there are some users who aren't online 24/7, certainly they managed to get your app somehow, so chances are a user is connected and won't even notice. Note: an astute user can packet sniff and man-in-the-middle attack this scheme, but there's things you can do to prevent that as well.
• With Rev (if your app fits this bill) just compile a web version of it and let people try it out online as much as they want. If they like what they see, they download it. It also easily let's you limit what the user can do by testing the environment to see if it's "browser".
• Use a third party vendor for copy protection (like http://www.siliconrealms.com/), where this is their entire business. The general scheme used by these parties is to encrypt your executable and compress it, and at launch it will decompress it and run. They also handle generation of registration keys, white lists, black lists, etc. This is more expensive, but I have several friends who have done this and had fairly decent results.

>> You aren't going to defeat crackers 100%. Don't even try. The goal isn't to make your app crack proof. Instead, it's simply a time/cost war. You want to price your app such that the time it would take to crack or the "penalty" of downloading a cracked version would exceed the cost of just buying the app. So think about copy protection in terms of that math equation as opposed to thinking of it as a way of preventing people from getting free copies of your app.

Hope this helps,

Jeff M.

[vtrbojevic]

Hi Jeff,

Thanks for your thoughts and a tip off for Siliconrealms!

In the meantime I have come up with a simple solution by which the number of the month ( 1, 2,.. 12) is multiplied by 100 and the day number added and then such current value compared with the expiry date value (obviously not valid next year!). I just want to show something to a group of people and I wanted them to be able to play with it say 10 times, but that was far above my very basic knowledge of Rev.

By the way, is there a way we can set up some value wich would be saved after quiting the application. In that way I could specify the number of times the application can be used and have a counter updated each tome it is used and that will do.

Regards,

Vladimir

[Mark]

Hi Vladimir,

You can use the seconds and have this value updated automacally when you build your standalone.

In the script of your mainstack, add:

Code: Select all

on savingStandalone
  set the cExpirationDate of this stack to (the seconds + 2678400)
  pass savingStandalone
end savingStandalone

on expired
  return (the seconds > the cExpirationDate of this stack)
end expired

In the script that checks the expiration date, which could be in your mainstack but it could also be in a registration window or somewhere else, you can write:

Code: Select all

on preOpenStack
  if expired() then
    beep
    answer error "This programme expired and must quit. Please, download a new copy." with "OK"
    quit
  end if
  pass preOpenStack
end preOpenStack

Note that on Windows, you can't simply issue the quit command. Instead, you should use a script like this.

Best regards,

Mark

[vtrbojevic]

Hello Mark,

Very many thanks! That was exactly what I wanted.

Best regards,

Vladimir

[vtrbojevic]

Hello Mark,

Thanks again! I have manmaged to make something like it work, but being an old Fortran user, there are things I do not understand! In my case the "on savingStandalone" is in the main stack, and test for the expiry time in the substack. I had problems in transfering the value of cExpirationDate to the substack and other cards. I made it property of the main stack, then a global variable, etc., but without success. Finally, I have put it intoi another variable, then in the substack placed it into a fiels, then in a button where thr test is, read it from the field. So my questions are:

1. is cExpirationDate some prespecified propertry of a stack, or just a variable?
2. what is the mechanism to pass variables across stacks and objects; up to now "global" seemed to have worked (like "common" in Fortran", but not in this case, as I could not pass to the button as a global variable.

Best regards,

Vladimir

[Mark]

Hi Vladimir,

The cExpirationDate is just a custom property. You can get it's value using the name of your mainstack:

if the seconds > the cExpirationData of stack "This is the name of the mainstack" then...

However, I provided you with scripts that you don't need to change. You can call the expired() function from any substack without a problem. Apparently, there is something else going on. Are you sure that your substack is really a substack of the stack that contains the expired() function? Another possibility is that "this stack" is causing problems. You might want to try the following alternative:

Code: Select all

on savingStandalone
  set the cExpirationDate of me to (the seconds + 2678400)
  pass savingStandalone
end savingStandalone

on expired
  return (the seconds > the cExpirationDate of me)
end expired

Note that this script must be in the stack script of mainstack an nowhere else.

Best,

Mark