> 
> I highly recommend that you do not time bomb your software if you want
> people to use it and pay you for it.
> 

This may be true, but there are also valid reasons to time out
software. When I release beta software to my clients, I don't want
that software running forever. I generally find it's not a good idea
to have known buggy software running endlessly within a client
company.

I use an effective method of timing out software that isn't vulnerable
to turning back the system date and doesn't rely on a data file. I
check a system directory that is updated by access to the web (e.g. a
directory that's a repository for internet cookies). In most companies
these days, people access the interenet every day. Thus, there is
almost always a file that's been created in that directory each day. I
check the creation date of the latest file as my check file for the
current date and compare that against the timeout date.

Occasionally, the timeout will be off by a day or two but that isn't
really an issue. Unless the person never connects to the internet,
this method is effective.
-- 
Regards,

Howard Bornstein
-----------------------
www.designeq.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to