>Agora me diga, qual o principal motivo do VFP não suportar o .Net FrameWork, parece que até o jurásico cobol terá um versão para o .NET e CLR ?

Sim, já existe Cobol.NET há um bom tempo. Entretanto, praticamente é só o mesmo nome da jurássica linguagem, e a sintaxe dos comandos. Se tentar compilar um programa jurássico, não vai conseguir, porque é incompatível com o código em .NET. Se compilar no VFP 8 um programa escrito no VFP 3, salvo pequenas incompatibilidades, você praticamente não precisa mudar nada no código. Se houvesse um VFP.NET, pode esquecer esta compatibilidade. É o mesmo que acontece para os programadores em VB 6 que vão para o VB.NET.


>Me diga o seguinte o que aconteceria se um outro produtor de xbase fizer isto ? ( www.xbase.com, www.dbase.com, etc.. )

Cairia no mesmo problema do VFP; não existiria compatibilidade com código legado, além dos problemas técnicos que vou citar mais ao final desta mensagem.

>Não que eu queira ficar presso a uma ferramenta. Mas gostaria de saber os motivos técnicos para isto.

Existem vários, que já foram explicados inúmeras vezes nos últimos anos:

1. VFP não é de tipagem-forte. .NET é. Fazer o VFP passar a ser de tipagem forte significa quebrar uns 95% de código já escrito usando versões anteriores do VFP. Quantos desenvolvedores declaram o tipo de uma variável quando estão escrendo código? E mesmo os que declaram, sabemos que no VFP você pode declarar uma variável de um tipo e então armazenar qualquer outro tipo naquela variável. Isso é impossível em .NET (não vale considerar o OPTION STRICT OFF do VB que está lá para "compatibilidade retroativa" - leia-se, para "não matar os VBzeiros com uma porrada só"). :)

2. Macro-substituição: impossível em .NET. É possível escrever código que será compilado e executado em runtime através de Reflection, mas é muito mais complicado do que usar um &Comando (como fazemos no VFP).

3. DML (Data Manipulation Language): leia-se, comandos USE, Replace, Locate, SCAN, Append, Copy to, etc etc etc... todos estes comandos seria retirados do VFP pois em .NET a tecnologia para acesso e manipulação de dados é o ADO.NET. Desta forma, se não tirar estes comandos do VFP, seria impossível, por exemplo, escrever classes em "VFP.NET" e utilizá-las em outras linguagens .NET (sendo esta umas das grandes vantagens do .NET).

4. Banco de dados nativo: também iria para o lixo, pois nenhuma outra linguagem .NET saberia o que fazer com ele (sim, eu sei que com ADO.NET pode-se acessar o banco... mas nada mais do que isso, sem falar do problemas já encontrados no OLEDB provider do VFP).

5. Gerador de Relatórios: outro que vai para o lixo (e a esta altura não preciso mais dizer o porquê).

6. No VFP, quando lemos isto: Cliente.Telefone, isto pode ser uma refêrencia ao campo Telefone do cursor/tabela Cliente, ou uma referência à propriedade Telefone do objeto Cliente. Isso é inaceitável no .NET. Cliente.Telefone *sempre* será um objeto.propriedade. Ou seja, os cursores do VFP também seriam removidos da linguagem.

No final das contas, o que sobraria então no VFP? Apenas as estruturas simples da linguagem, como IF, DO CASE, etc... Oras, para ter apenas isto, é mais fácil ir para o VB.NET... Sinceramente, não teria sentido nenhum a existência de um VFP nestas condições, pois a Microsoft teria que suportar duas linguagens de nome diferente, mas de sintaxes muito similares, e isso é fora de questão.

Se parar um pouco mais pra pensar, dá pra se listar ainda mais considerações, mas acho que isso já dá pra te dar uma idéia do pepino. :)