>>>So, I can assume that a managed C++ version of VFP can even run faster that the actual one and runtimes can be small compared with what are today ?
>>
>>Hi Dorin,
>>
>>I think so in that case we will needed a .NET runtime plus VFP.
>
>Hi.
>Even so, all talks about losing its "data centric" possibilities are not true. Only that the Xbase interpreter can be built on .NET platform using all platform features instead hard coding all controls and features.
>
>I've seen Quake 2 built on .NET managed code and processor use is optimized compared with native version. So is possible, just that we will never see something like this.
>
>>Instead of that, a VFP.NET compiler will be a more intelligent solution. We will needed a .NET Runtime but We won't needed a VFP runtime anymore.
>
>And who is going to do something like this ? ;-)
>Maybe if the source will be opened.

The difficulty is VFPs weakly typed nature. Consider the following snippet:

LOCAL lcName
lcName = Customer.Name

What is Customer.Name? A table with a name field, I suppose, but that can not be verified during compilation. It could also be an object with that property name.

That is the real difficulty when faced with a conversion of VFP to the managed platform. There are ways to get around this. For instance, one could use a lot of late bound technology, but that would be very slow. One could also change the language, but that would kinda defeat the purpose.

As far as Quake goes: Yes, that is a fairly straightforward story. DirectX is available on the managed platform. This allows .NET developers to send instructions straight to the graphics hardware. Performance results are almost identical between native C++ DirectX and .NET DirectX. Also, GPUs use a secondary language called "the shader language for the programmable pipeline" or "HLSL". No matter what language you use to communicate with the graphics hardware, shaders are always written either in HLSL or in an assembler-like version of it. The shader is sent to the GPU, and there is no performance difference worth mentioning, no matter what language was used to send the shader to the card.

Markus

PS: I will be doing a session about this at the upcoming conference in Montreal.