>We were talking about this at the bar here in Miami last night and talking about future enhancements. Which of these enhancements would you like to see in a future version? Keep in mind that all are major and all would require breaking things that work now.
>
>1. 64-bit VFP
>2. VFP running on Windows CE
>3. Remove the 2 Gig limitation
>4. Support for CLR

1. If VFP lasts that long, it will become 64-bit once MS's primary development language is 64-bit VC++.

2. Windows CE will eventually become powerful enough to run VFP, without VFP having to do anything (i.e. "lite-ing" itself).

3. If #1 happens, this will disappear as a side-effect. However, JohnK is right, that you don't want to use VFP to reliably store that much data (unless it gets a true fault-tolerant back end, which is unlikely with MS's other options in this area already). One area where there might be a niche for VFP-type data storage would be in multimedia, i.e. storing video or images; not too critical if it blows up, speed & simplicity of access (compared to a regimented SQL back end) might be real pluses.

4. A real two-edged sword, that one. To play with CLR increases VFP's compatibility with MS's stated direction, which can only help.

I don't know if this has been touched on already, but I'd be concerned about the "dumbing down" of VFP to wedge it into a lowest-common-denominator CLR. VFP is arguably the highest-level programming language that MS sells - for many people, it represents the fastest way to express their ideas. Markus Egger has it exactly right - "life is too short for C++". It's truly interesting that, with CLR, MS is moving to a runtime model that VFP has had for many years.

I think MS should license one of the better commercial VFP frameworks and include it in the VFP box. Alternately, they could study various frameworks and implement high-level language constructs that are common to most, if not all of them, and that are used by VFP programmers every day.

For the continued viability of VFP as a separate product, on balance I think new, advanced language constructs are more important than CLR compliance/compatibility. If the former is sacrificed for the latter, there will be decreasing incentive for new talent to take it up, and our best and brightest will move to where the market is.