>You're assuming that the user has a working knowledge of file i/o, in which case there is very little you can do. It would be too easy to expend a great deal of time in combatting this, when infact many large companies do not protect their software in any fashion.
>
>If we were really that way inclined, we could simply decompile the .EXE and there would be no way of protecting the application.
>

There are a half-dozen freeware utilities that'll do this, like TOUCH.EXE which could be downloaded from places like shareware.com

I tend to agree that there is really no way to completely protect a time-limited demo; I've done a couple of dozen things, like embedding an encrypted value in a data file or the .EXE itself or writing obscure registry keys. If I'm smart enough to come up with a protection scheme, there's someone else out there enough smarter that they can beat me given enough time and resources.

The trick behind protection schemes is not to make an invulnerable scheme, but to make one whose cost to 'defuse' is so high that the customer realizes it's cheaper to buy it for real. Encrypted date/time stamping embedded in a file works for me since I deal with data that's only valid for short periods of time and where the system date is critical to ensuring the validity of the data in use (the logistics and shipping industries.) That's not the case for the majority of applications on the market.