Mi Mark,

I don't doubt what you say, but that must have more to do with the *physical size* of VFP than with its execution performance. Personally, I don't care what the physical size is, as long as it runs fast.

Cheers,

Jim N

>Some [most?] of the performance penalty we are paying is because MS has maintained so many features, functions and commands [obsolete or not] for backwards capability all the way back to dBase, FoxBase, FoxPlus, FoxPro, etc....
>
>I remember being invited to a MS "What do you think" lunch at DevCon 3 years ago where we were asked what we thought [among other things] about maintaining all the stuff for backwards compatibility. My opinion was to phase it out. I don't know if it is reasonably possibly to count how much is still there, but I still see a lot of stuff in the VFP help that has For Backward Compatibility. Please see some_other_topic.
>
>>On the other hand, there is absolutely no excuse at all for *any* product to get 'slower' in its application execution fromn version to version on the same OS and UI base, in my humble opinion. I can tolerate some (new) slowness in a newer version in its development environment provided that there is much improved functionality in the IDE.
>>
>>I can even accept some 'slowness' in in app execution for NEW features delivered in a new version.