>idea number 1
>
>I want to sell a vfp designed .exe over the web. The user comes to the web site to download the demo version. Someplace in the .exe is a string that says "DEMO VERSION" or "Demo limit 22".
>
>When the .exe starts can it go out to its own folder and open the .exe with low level commands and reduce "Demo limit to 21".

a. Windows may not let you modify an .EXE that's "in use" - i.e. open. You could test this by building a small non-"encrypted" VFP .EXE with an embedded string, and try to modify it.

b. Trying to do something like that with the in-memory (as opposed to on-disk) executable might fall foul of antivirus software and/or the OS itself: http://en.wikipedia.org/wiki/Self-modifying_code

c. Finally, the above are moot because this idea is easily defeated:
- Suppose the program executable is installed in a WORKING folder
- Copy the executable to a BACKUP folder
- Run the executable from WORKING: demo count is decremented to 21
- Copy the executable from BACKUP back to WORKING: demo count is back up to 22
- The above could easily be automated with a batch file

>
>
>idea number 2
>
>I want to sell a vfp designed .exe over the web. Can the .exe make contact with the web sight to do automatic registration?
>
>
>
>idea number 3
>
>I want to sell a vfp designed .exe over the web. Can the .exe have an embedded or random serial number.

You are a PUTM, you can search the many threads that have been created here regarding copy protection. For a general discussion see http://en.wikipedia.org/wiki/Copy_protection#Copy_protection_for_computer_software

Regarding VFP in particular, my understanding of the issue:

1. If your executable is given to users, they can attempt to decompile it. Once decompiled, the source code can be modified to remove or bypass any licensing mechanism it contains within itself.

2. An unprotected VFP executable is trivially easy to decompile, with commercial tools or even some free utilities. The so-called .EXE "encryption" feature when building a VFP executable does not help at all.

3. The various copy protection products available recognize the above, and try to prevent decompilation. There is continuous war between these products and hackers who attempt to break them. However, it's safe to say that any VFP executable protection product can be defeated with enough applied effort. So, if you distribute a VFP executable, you are effectively distributing your source code and it's a good idea to plan your business taking the possible consequences of that into account.

4. For example, a hacker may decompile your executable, modify it to remove copy protection, further modify any copyright or authorship information and post it for sale (or free download) on her own website, claiming to be the author. This hacker and/or site may be in a country with weak or no copyright laws, leaving you with no recourse.

So, given this doom-and-gloom scenario, what can you do?

1. Avoid distributing your executable. If you don't distribute it, it can't be decompiled and pirated by others. You can do this by creating a web service rather than an executable, and host it on your own website; you then sign users up to some sort of subscription. Another option is to use something like Terminal Services, with controlled access. These days this sort of scheme is called "software-as-a-service" (SaaS).

2. If you must distribute an executable, rewrite it to use unmanaged C or C++ code. My understanding is that such executables (usually created by modern, highly-optimizing compilers) can't be decompiled. From time to time you hear news of Ph.D students making progress against certain portions of certain C/C++ compilers under some conditions but as far as I know there is no general decompilation tool for unmanaged C/C++ and it's thought that in the general case it may not be possible to create one.

3. If you must distribute a VFP executable, you could force it to rely on something you control. For example, maybe your app could be split so it depends on data that are stored in a SQL Server you control. An example of this would be a so-called "thick-client" app, giving users a rich VFP (non-browser) front end while storing their data in a Web-accessed SQL backend.

4. You could copy-protect your app, then sell it for a low price. This may make it not worth breaking the copy protection. Bear in mind that there are technically astute people in countries with low wages; their idea of "not worthwhile" may differ from yours. Then there are hackers who will do it for free just for the challenge.

5. At the other end, your app may be large and complex, and require significant setup and configuration before it can be used (e.g. ERP systems). This can make piracy effectively impossible, because in order to use your product, they must contact you for initial setup and/or ongoing support.

Of course, what you end up doing depends mostly on your current circumstances and business plan.