>You can improve security storing also the time the user launch/quit the app.
>at startup if the actual time is < the the time stored for this day you add
>a day because user as set back the clock.

Yes, that's basicly what I would do, however there will have to be buffers to allow
normal time-correction and summer/winter-time changes.

Anyway it's quite a lot of handling stuff. And You will additionally have to write it
to a file that is not easy to identify or at a hidden place in the registry, Not knowing
whether the actual user as administrator or just "guest" rights on the machine.
Would be much more easy if I simply could make an api-call to an internal system clock
that cannot be changed.

>
>but now the question is: what kind of users do you have? hackers? :))
>

Actually no. I think they are just normal users. However changing the system time
is an idea that even the greatest computer-dummy might have.
My application is not expensive, and I can easily live with a few hackers that
use it for free, but I'd like at least some security.

>
>What about an internal clock? (at the end should be the only way). Don't say to clients
"test it for 30 day" but: "test it for 100 hours". Create an app timer, every timer.interval
(let me say 1 minute) add the spent time to the global timing. This way I don't have to worry
about the calendar. I don't think this would take to much cpu time, isn't it?

Actually that's not a bad idea. It does not have to be a timer at all. I could write a
small custom class that when instantiated catches the current time and holds this in a property.
I'd add the control to _screen uppon application startup. In the destroy I'd catch the time
again and automatically add the elapsed time to an entry somewhere. Even using a timer would
barely use any resources when firing once in a while and simply adding a certain amount to
a property. So I could internally check 30 days or 30 x 5 = 150 hours (assuming that the
application in average runs maximum 5 hours per day). That would at least one day terminate usability.

The question for any of these solutions is, where to store it safely. I'm not a friend of
adding rubbish to other's people registry. And if You want to make this work even with reinstalling
the software You will have to leave it in the registry forever or until the user buys the software.
Same is true for a file that You hide somewhere on the system. However if You put it in Your
installation-directory, the user might simply delete the whole application-dir and the information
is gone.