>>>I don't think you have that strong a position on 64bit version: MS might argue that to be intended and not a bug...
>>
>>I don't think it was intended, it was presented to us as an impossible task, and a solid reason to drop VFP out of VS. Check the threads 2001-2003.
>
>On 32-bit NT-based platform: Sold as? Compiled to ? Planned for?

They said recompiling VFP into 64 would be impossible even with M$'s resources, yet Chen did it alone. They said VFP can't switch to managed code (newspeak for dot net, as if all the rest of code in the universe is unmanaged or mismanaged) or else it would have to lose the cursor engine and its own tables, again Christof Lange and Etechnica (or what was the name of that outfit, some guy Solomon David aka Salvador Davilla) proved that it can be done.

IOW, the fabled "M$'s resources" should always be read as "as many programmers as they are ready to allocate for the task", which always meant zero of those for VFP. VFP was prey, to be chopped and as many resources extracted out of it - some technology, and as many programmers using it as possible, to be corralled into dot net pen. At some point, I think M$ devoted more manpower to luring programmers away from VFP than into developing it.

>FPD/FPW coming from DOS had 16 bit OS heritage, even if some versions targeted 386 specialities.
>AFAIR vfp 3 still had ability to call into 16-bit compiled dll, as there were special calls in foxtools to load these.

Yup, remember the regfn() calls.

>With EU High courts another level is added where biased me sees a tendency to decide against prosumer in matters of state vs. prosumer and sometimes slightly pro consumer in matters company vs. consumer.

Irrelevant to me, I'm using VFP under wine for pure hobby, and I'm willing to share the profits with M$... I think a check to zero dollars doesn't have to be issued by any bank, I can make my own, right?