>Makes me wonder... if at the time of VFP7 we were forced to decide "in VStudio or out of it",
to be honest, I can follow some of MS arguments.
i.e. "dot net XOR VFP as we know it",

here my take is that vfp is so tightly coupled to itself for instance in screen designer, control base classes and so on that supporting a "vfp screen designer" as before would make no sense.

>it was presented as "VFP would have to lose its native data engine etc etc".
Here my take was the danger of loosing "late/runtime binding" between table fields and memvars. That is possible now, but perhaps was not clear back then or an intended feature of .Net.

>It was a big, 28-pixel XOR for the last five years at least, just like the story that "crossing the 2GIG boundary would require a major rewrite of VFP's core"...

Here I think it would make sense to wholly port VFP to X64 code. For instance low-level file access is also 32bit - but perhaps pointing to 64-bit routines would work there as well. Doubtful, as they are probably used from inside vfp's C engine.

>now if you guys, slightly less rich and probably a few megabytes shorter in other resources then Microsoft, managed to do that all (have both native VFP and CLR in the same compiler, and cross the 2Gig boundary), I have only one question: was Microsoft Fox team unable or forbidden to do the same thing?

I asked J.Koziol a similar question and NDA came into play <bg>. My guess is they compiled in X64 at least to find some hidden type bugs and were not allowed to enter official testing circle - as there probably is a high cost attached to it, which would stay high if they supported 32 and 64 bit versions. And that might make a sizable dent in the budget.

regards

thomas