I saw a demo lock solution that was simple and worked something like this:
A file with an expiration date in a character field, with the format:

cExpireDate="08.01.2001"
if !"."$cExpireDate
   * quit
endif

When the demo opens it determines that the "dots" are still in place, then;
dExpireDate=ctod(strtran(cExpireDate,".","/"))
if dExpireDate>=date()
   repl cExpireDate with strtran(cExpireDate,".","/")
endif
subsequent re-opens will notice the dots have been replaced with slashes, and
not allow the demo to run. I someone hacks the Exiration date field, they
will most likely leave the dashes in place, which means the demo will not
execute

>>I think I'm understand the way you just explain in your letter. These days I will try to do it.
>>I have been thinking that such "mechanism" could be used for protection, like I could put inside source some variable or even string visible to the some hexeditor and also my EXE. Always when this EXE starts he search for some secret place and decrease for 1. When a counter is 0, program won't work!? That is idee because I don't like to use some commercial solution for making demo based on date or counter. With my way it could be easy to "unlock" such demos and transform in "working version".
>
>Hi Elvir,
>
>I thought that you might be thinking of something like that.
>
>You might also want to consider placing some of your "date" and "counter" information in a couple of other places; eg. another file and/or the Windows Registry.
>
>You can then check that they are all "syncronized". This prevents a User from simply copying back/reinstalling the original EXE.