>>Thirdly, because of macro substitution, if VFP did produce a native compiler, it would have to include the entire run-time library.
>
>George, et al,
>
>Years ago there was a product named FORCE that was a native compiler. It forced (no pun intended but I'll take it *g*) developers to make declarations and so forth and when compiled ran like a bat out of, well, you know where. This was in the early 286-386 days. Great product but it never caught on with xBase programmers because of the ability of p-code to do those pesky macro substitutions. Great product, no market. Our pals in Canada who wrote CodeBase have kept their product up to date - to their credit - but I'd sure like to see what percentage of their overall business is from FoxPro programmers who need the kind of product you'd get from a CodeBase.
>
>Turns out that there's a pretty strong market for p-code.
>
>Not only that, and this might start a whole new thread, but having the ability of the p-code functionality IMO goes a *LONG* way towards developing what I would consider the almost-perfect application. That would be the one where all application information is contained in tables and the engine just loads and executes. Hard to do w/o macro substitution.
>
Hi Doug,

Interesting points. Let me throw a couple of more out for general consumption.

1. The term "stand-alone executable" is, under Windows, a total misnomer. No application truly "stands alone" because it is heavily reliant on the OS to provide it with services. Under DOS this wasn't the case. The best analogy I've heard in comparing the two comes from Ivor Horton (the author of several computer related books). To paraphrase him, "Under DOS, your application was the dog and the operating system the tail. The OS wagged when told to. Under Windows, your application is the tail, and it wags when Windows (the OS/dog) tells it to." In my opinion, the reliance on Windows for services does take some of the edge that native code compilers had.

2. Performance related issues are hard to pin down (and getting harder). So many things other than the raw clock speed of the CPU can significantly impact it. These things range from the amount of available RAM, size and availability of the swap file, bus speed, video RAM, etc., etc. And all can have a positive or negative impact on performance.