> [..any reason why Microsoft couldn't have done this..]

Because Microsoft would have had to build a fully backwardly compatible VFP.NET that somehow, simultaneously had every favourite feature from the VFP of old, and all the new cool features like Unicode support that would have made the port worthwhile. And if they screwed up in even the slightest way, the whining would have been intolerable.

eTecnologia has no such constraints. They could produce a product that implements less that half of VFP's features and runs like a snail, and they would still be praised to the sky. (I'm not saying they have, just that they could <g>). Anywhere they fail or decide not to implement some VFP feature, they'll get sympathy rather than criticism. Nobody expects a complete VFP from the start - I hope that noone expects to end up with one either!

Unfortunately there's a huge task ahead to implement all of VFP runtime features, and I think the compiler will succeed in niches rather than rescue the VFP die-hards who don't want to learn anything new. For example .NET doesn't have anything that can slice and dice data in the way VFP can, but System.Windows.Forms is quite adequate for building GUI front ends, so learn that, or WPF, rather than expect Samuel and Co to implement VFP form classes.

- Walter