>So, instead of asking MS for a native compiler, better of asking for VFP runtimes to be shipped with windows?

Jess,

Be careful of what you wish for, you may get it. If VFP ships with windows it is then forced to comply with a multitude of windows requirements and testing. That means the development cycle for each new version is occupied with a bunch of red tape thus reducing the amount of new functionality that can be added. VB and VC++ suffer this situation, VFP does not currently.

The idea of a native compiler is highly over rated. VB does NOT have a native compiler like those used to be in the DOS days. Every application that runs on windows does some degree of dynamic linking at runtime, the differences are the amount of dynamic linking not whether there is any or not.

VFP has great functionality in late resolution of expressions (macro expansion, named expressions, and other things) that are a direct result of the interpreted environment within which it functions. Remove the interpreter and you lose that functionality. VFP is loosely typed and any native compiler would need to be more highly typed in order for the compiler to resolve the variable references without the luxury of an interpreted environment.

If VFP was to allow us to interactively run source code, as we can, and then it was to build a native compiled EXE we would need to retest everything in the exe because it is not running in the same environment the source was tested in. If to get around that problem the exact same libraries were used in linking the object code to native executable code you would save absolutely nothing in exe size or performance.