Hey Mike,

Cling to VFP? This won't be VFP it'll be VFP.net. This seems to bug many persons. Perhaps VFP.net should be the project code name. They should release it as DC (data centric) .net and it goes perfectly with my initials. I sure hope Etecnologia guys will read this 8->


>No, I haven't bought it, any more than I have put money down on a 2012 Chevy. Also, I have no desire to cling to VFP. I am a software developer who wants to make a living writing software. I understand the decision might be different for a company or vendor who wants to keep an existing VFP application alive and not have to rewrite it.
>
>>Well, if this was the very first statement made by Samuel David; I would agree. But since it is not, and since all his other (sometimes astonishing) technical statements turned out to be true, I do not understand your statement. Have you ordered the .Net extender so you could review the compiler?
>>
>>Although the compiler is clearly still deep in beta, it is clear Etecnologia is not turning out vaporware or any false promises.
>>
>>One can differ on whether the goal of a 100% VFP9-compatible .net compiler will be reached. Agreed.
>>But one cannot differ on that until now, Etec delivered what it promised.
>>
>>Lennert
>>
>>>Yes. I am skeptical about the claims being made by Mr. David.
>>>
>>>>Is that an irony? :)
>>>>
>>>>>Yes, exactly.
>>>>>
>>>>>>That's just like a dream.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Well the option to create native exe is not available in standard .NET. How we did this? We just take our .NET Assemblies (IL binary code as output by the VFPCompiler) and compiles them to Native, this is we don't do any conversion to C++. But I can tell you that the performance of the resulting exe is lot faster than the JIT (Net Interpreter) and really close to C++.
>>>>>>>
>>>>>>> With this capability you get the amazing productivity of VFP and the performance of C++, so for us it is the culmination of years wishing to build true natives from our VFP Code. And that will be the preferred way for us, as sellers of VFP coded products, to distribute our VFP apps to our customers, with that we get rid of the shortcoming in distribution of .NET.
>>>>>>>
>>>>>>>>>The native code generation will be just a switch in our Developer Studio that will generate instead of a .NET Assembly, just a true x86 / arm EXE or DLL or if you want and OBJ (linkable object).
>>>>>>>>
>>>>>>>>That's great news. I'm aware of .NET but if I understood true: "VFP Developer Studio can compile both true .EXE and .NET interpreter exe"? I didn't know there is an option for make true .EXE files with .NET. Are you convert applications to C++ and compile than or .NET supports native .EXE files too???