>Actually, Cobol for .Net is available. http://www.netcobol.com/products/windows/netcobol.html is just one of them. There is apparently a Pascal version in development: http://www.tmt.com/net.htm. And of course there is Delphi: http://www.borland.com/us/products/delphi/index.html
>
>Originally MS had a valid reason for not porting VFP: no one had demonstrated that dynamic languages could be integrated into the CLR. That ability is now demonstrated in a released product (IronPython 1.0, under continuing development). The reason given now is resources, but of course in a company that added 10K employees last year, that's laughable. The reason is a marketing decision, made by those who want to protect their little fiefdoms within MS, a phenomenon noted for years in the local MS offices, who on some reported occasions declared that VFP was dead -- 2 or 3 versions before VFP9.

When this first came up, it was the developer community that begged MS not to move VFP to dotnet, and my understanding is that it mostly was because it would likely have entailed theloss of the data capabilities of native vfp. VFP would have had to move from the current data system to ado.net, and nobody wanted that.

>
>Hank
>
>>Hi Joel
>>
>>>but the last I heard VFP will not work with Dot Net because of the CLR.
>>
>>Aren't VFP apps supposed to work in the OS, namely Windows, which it does, and will even in Vista, I believe.
>>
>>I don't think that C or C++ code can be compiled in VFP. VFP code cannot be compiled in PASCAL, and so on, so isn't it obvious that a compiler will compile only stuff that it is supposed to compile. Is this a discussion point? If so, then we should be complaining that my old COBOL code too is not being compile in Dot Net becuase of the CLR.