Visual basic code to setup your program to expire after 30 days

JD2369

Member
Joined
Jan 12, 2011
Messages
19
Programming Experience
Beginner
Is there code in visual basic 2008 where i can set my program to expire every 30 days ?

Thank You
 
No.. It is Too hard to Discribe...
But I Recomend the Software Named "Setup Factory"
you Can Setup Your Software with Setup Factory and It can expire your proggrame after someone Installes your app.
That is the Easyest Way.
 
Last edited:
Set up an sql server. Set up a download link, and when the user opens a program for the first time, the user sends out the current date to the sql server. Then, after that, every time the program opens, simply send an sql query like: "Select * from ExpDatesTbl WHERE ProgID = @ProgParameter". Compare the two dates, and if the user has gone over the limit, msgbox and terminate the program. Simples. :)
 
The problem with having everything run online is that the user won't necessarily be online every time they want to run the program. It also requires you to maintain a dedicated server and sufficient bandwidth to check the program.

Alternatively create a file and/or registry entry on the local machine when you install the program. That holds the installation date. Every time it opens check the current date against that date, if it's more than 30 days ago refuse to load anything except the purchase dialogue or explanation.
To avoid the user simply changing the date or time on the system clock, refuse to open the program if the current date is earlier than the last used date (assuming that The Doctor is not among your clientèle). Every time the program opens record the current date as the last opening date. In order to keep these time records safe from tampering you could implement a basic encryption or checksum system.

Suggestion pinched from the Mods here.
I know this is an old thread, but it makes sense to keep information balanced for future inquirers.
 
Set up an sql server. Set up a download link, and when the user opens a program for the first time, the user sends out the current date to the sql server. Then, after that, every time the program opens, simply send an sql query like: "Select * from ExpDatesTbl WHERE ProgID = @ProgParameter". Compare the two dates, and if the user has gone over the limit, msgbox and terminate the program. Simples. :)

This is definitely a good way to do it. :)
 
The problem with having everything run online is that the user won't necessarily be online every time they want to run the program. It also requires you to maintain a dedicated server and sufficient bandwidth to check the program.

Alternatively create a file and/or registry entry on the local machine when you install the program. That holds the installation date. Every time it opens check the current date against that date, if it's more than 30 days ago refuse to load anything except the purchase dialogue or explanation.
To avoid the user simply changing the date or time on the system clock, refuse to open the program if the current date is earlier than the last used date (assuming that The Doctor is not among your clientèle). Every time the program opens record the current date as the last opening date. In order to keep these time records safe from tampering you could implement a basic encryption or checksum system.

Suggestion pinched from the Mods here.
I know this is an old thread, but it makes sense to keep information balanced for future inquirers.

Aye agreed. But I don't know if it should really be "Simple". If he's writing a program he intends to make money on,
I doubt he can afford the risk of a crack that simply updates the registry entries by breaking the encryption. I think the most secure way of storing a date in a registry would be as follows.

1) On first run, calculate the date in 30..N days time. Hash that value. run it through some function S.
2) So the message digest of N days after first run is passed to S, and what is stored is S(N).
3) Every time the program is ran, You hash the current date, and encrypt it, and compare it with S(N).

S(N) should be some function that can reduce a message digest down to a date.
Dry run could be as follows:

EXPDATE <- 11/11/11
MD5(EXPDATE) <- 70108758dce15b25a6c5e552f73235b6
S(MD5(EXPDATE)) <- 15/10/11

Store that. In your code, you can even openly represent this, although I would recommend obfuscating the code so it's not completely obvious, but this method doesn't require you to even decipher anything, and if you wanted to be
completely secure you could even have an RSA keypair. Only store the public key for encryption, before you run it
through S() and you've got a very secure system!

I do apologise. I am a crypto-geek x)
 
Back
Top