>>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.