>I see a lot of messages, faqs, articles, etc. devoted to problems registering OCX controls for VFP applications in Windows. What I have been unable to find is a single statement that explains WHY we should be required to register OCX's in the first place. Having to register everything certainly complicates life if you are developing an application for use on a network. If we want to develop a totally self contained application where we provide all of the necessary files and control access to them in folders that we specify, it seems like we should be entitled to do so.
>
>Therefore, my questions are:
>
>1. Why is it necessary to register anything for an application to run in windows?
>

It is necessary only when using automation/COM, as is the case with ActiveX controls. When your program does ox=CreateObject("Crystal.Application"), the OS has to have information on the registry in order to create an instance of the control. When you register, the regsvr32 (or installation routine) writes the appropriate info to the registry database.

>2. Is there an alternative to registration for those of us who don't care to play stupid games?
>

Write your app so it includes all the functionality required in the exe. No automation servers / ActiveX / COM allowed. Copy the VFP runtime files to \system32\ and the executable and necessary startup / database files to a directory of your choice.

>Any enlightenment would be appreciated, because so far a logical explanation escapes me.

It can be done, but you will miss on all of the advantages of component based applications.