>Thanks for the additional info on this. It brings up a couple other questions.
>
>1. When compiling and linking in C/C++, is there any impact on execution speed of the FoxPro code. Better? Worse? Same?

As far as the FoxPro code, there is no difference; it still runs as its own process. You're basically just "hiding" the FoxPro EXE initially within the C/C++ EXE. The C/C++ EXE extracts the FoxPro EXE resource, decompresses/decrypts it and runs it ... not much different than running another program from withing FoxPro using the RUN command.

>2. How complex have your apps been where you've done this? What I'm really after is: Have you bumped into any side-effects by using this technique? Any langauge or feature limitations? For instance, if you go beyond the basic VFP tables, forms, and code, and ... let's say ... incorporate ActiveX controls and other COM functionality, do you know if anything breaks?

Embedding the EXE is just one technique.

You could even "hide" the EXE elsewhere; eg. in a custom packed/encrypted "data" file (ie. non-executable).

A "stub" program (in any language other than FoxPro) locates the file, unpacks and decrypts it, then runs it ... so not much different from the scenario that is often discussed re: using a "loader" to locate and run the latest version of an application (so, no ... there isn't any reason why something should break.).

It's this "2-step" execution process that Refox can't deal with (assuming step 1 isn't FoxPro code).

The bottom line is, once you implement a scenario like one of the above, you don't reveal the final details; the average "lamer" won't really know what's going on and "just" throwing Refox at it won't help them.