> > 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