auto expire code
Can anyone point me in the right direction for information that will help me code a demo that will expire after 30 days?
Thanks
First of all, this is not an OpenGL question.
Second, don''t do that, it tends to annoy people, and, if someone wants to go trough that limitation, s/he can crack the program.
Anywya, if you REALLY want to do that, then I suggest you to do something like this:
Get the current date/time, write it somewhere (file, registry, or even an existing file timestamp, to be harder to detect), then, whenever someone opens the program again, check to see if the current date >30 days+ the saved date.
If it is, then abort. Of course, that is the simple way to do it. You might want to research more, in order to block attempts such as changing the system date, etc.
Second, don''t do that, it tends to annoy people, and, if someone wants to go trough that limitation, s/he can crack the program.
Anywya, if you REALLY want to do that, then I suggest you to do something like this:
Get the current date/time, write it somewhere (file, registry, or even an existing file timestamp, to be harder to detect), then, whenever someone opens the program again, check to see if the current date >30 days+ the saved date.
If it is, then abort. Of course, that is the simple way to do it. You might want to research more, in order to block attempts such as changing the system date, etc.
Well there would another way :
1. At first execution get time and store it in the exe...(right after the file ends... write somehow with "a+")
2. Read the last 10-15 bytes check time-date if >30 days....Quit
But instead of storing it in the exe you could store it like in c:\Windows\System\Msvcrt.dll (with "a+")
You can store that anywhere without affecting the exe...
Or you can save files in many places on the CPU (Win,Sys,C
adn check that or registry as posted earlyer
Or
Make a system with (Let`s say)a limit of 3-5 executions(So you don`t get compilcated with the time because it can be changed...) and store that...(Anywhere) check limit exec and Voila!
1. At first execution get time and store it in the exe...(right after the file ends... write somehow with "a+")
2. Read the last 10-15 bytes check time-date if >30 days....Quit
But instead of storing it in the exe you could store it like in c:\Windows\System\Msvcrt.dll (with "a+")
You can store that anywhere without affecting the exe...
Or you can save files in many places on the CPU (Win,Sys,C

Or
Make a system with (Let`s say)a limit of 3-5 executions(So you don`t get compilcated with the time because it can be changed...) and store that...(Anywhere) check limit exec and Voila!
Relative Games - My apps
Writting in an exe is a BAD idea:
1. It can corrupt that exe
2. it will trigger a lot of negative reaction, from antiviruses.
3. You would just replace the exe, with the original one, so you would have another full month of ''evaluation''.
1. It can corrupt that exe
2. it will trigger a lot of negative reaction, from antiviruses.
3. You would just replace the exe, with the original one, so you would have another full month of ''evaluation''.
and for *** sake, don''t write to files that don''t "belong" to you, eg. c:\Windows\System\Msvcrt.dll as suggested... now THAT will annoy people (besides, on Win2k / XP the user might not have rights to write to that file)
There are several different ways you could go about it - each with it''s own downfalls.
1) Counting number of executions to determine expiration.
Replacing the executable circumvents this.
2) Using the installation time to determine expiration. (time.install + time.evaluation_length = expiration)
Uninstalling the application (and it''s corresponding windows registry entries) and re-installing circumvents this technique.
3) Using a set date to expire (aka time bomb)
Rolling back the system time circumvents this. Given, this will also create problems on the host PC. Many users are aware of this, thus causing the user to simply not use your software. (the preceding contains an orthodox, as a user cannot be a user without having used the software...hehe...)
Of course, any technique can be simply hacked...
Bottom line (IMO): Don''t use expiration techniques on demo software. If you feel inclined to do so, don''t be surprised when a) someone circumvents it and emails you proof that he/she did it b) your software is simply ignored.
1) Counting number of executions to determine expiration.
Replacing the executable circumvents this.
2) Using the installation time to determine expiration. (time.install + time.evaluation_length = expiration)
Uninstalling the application (and it''s corresponding windows registry entries) and re-installing circumvents this technique.
3) Using a set date to expire (aka time bomb)
Rolling back the system time circumvents this. Given, this will also create problems on the host PC. Many users are aware of this, thus causing the user to simply not use your software. (the preceding contains an orthodox, as a user cannot be a user without having used the software...hehe...)
Of course, any technique can be simply hacked...
Bottom line (IMO): Don''t use expiration techniques on demo software. If you feel inclined to do so, don''t be surprised when a) someone circumvents it and emails you proof that he/she did it b) your software is simply ignored.
I''d just like to add that I think the vast majority of casual users will not try to find their way around expired evaluation copies that still don''t run after an uninstall and install.
However, it would proabably be a better idea to give the evaluation copy limited functionally compared to the full version.
However, it would proabably be a better idea to give the evaluation copy limited functionally compared to the full version.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement