>>>It's a personal guess that VFP will be 64 bit when the rest of VS (with the exception of VC++ which already can produce 64 bit code) is, not before or after. Remember that VB (4.0 I think) also had an intermediate product capable of producing either 16 or 32 bit code just as VFP 3.0 could.
>>
>>And as afterthought... VFP3.0 was so messy and buggy, that if any of that was due to being able to compile both 16 & 32 bit, I can definitely live without an intermediate product that can do both next time around.
>
>Some of that I think was due to a pretty radical change between the way the two OSs ran. Win16 was a co-operative multi-tasking OS, Win32 is pre-emptive. Further, a lot of other stuff changed as well. Don't forget also that VFP 3.0 was, in reality VFP 1.0 in that it was totally different from the product that preceeded it.
>
>If it's of any comfort, here are a couple of quotes from the Platform SDK: Win64 Programming Preview in the MSDN Library:
>
>"Include Files
>
>The Win32 and Win64 API elements are virtually identical. The Windows header files have been modified so that you can use them for both Win32 and Win64 code. The Win64-specific types and macros are defined in a new header file, Basetsd.h, which is in the set of header files included by Windows.h. Basetsd.h includes the new data-type definitions you'll use to make your application word-size independent."
>
>"64-bit Compiler
>
>Starting with Windows 2000 beta 2, the Platform SDK will include a 64-bit compiler that you can use to identify pointer truncation, improper type casts, and other 64-bit-specific problems. Better tools will be available, but this tool will get you started."
>
>So you can see, it's a lot closer than many might think.

According to Calvin, all existing code would break. There would be no backwards compability.