Thomas:

When we find out who is leaking you our Top Secret Information, I'll swear We... :-)

Now seriouly, having VFP code compiled to CIL is a big enabler. From there you can:

1. Turn it to native code. Example, http://www.xenocode.com/Products/Postbuild/

2. Turn it to JVM bytecodes. See http://dev.mainsoft.com/. The J2EE scenario you mention sounds very interesting, specially if you know what I know and what almost everyone here knows: VFP beats any other language / environment when dealing with Data and in extensibility. Data Binding and Data Handling is very tedious in J2EE or .NET so we really have and edge here.

Our runtime will ship with a license that let you use it in any environment you want. So the compiler for .NET is a enabler, from there you can make run the Fox where no Fox ran before ...



Our runtime will ship with a license that

>Hi YAG,
>
>>Given that, and the fact that everything in .NET compiles to a common representation (MSIL) it shouldn't matter what language you write the language syntax in (in fact, I believe that he said earlier that they could be written in any of their supported languages). So, given that, and given that I'm a business and process wonk <g> I don't understand why they would spend extra time on the language syntax (given a limit to the resource time) so that they can focus on the first two. IOW, just state that the following 200+ functions in the syntax already work and go from there.
>
>I wondered about that as well. I have not checked all of the vfp toolkit, but just upon source reading I was sure there were differences between the vfp toolkit and actual vfp behaviour. Nothing earth shattering, but for a compiler marketed as an implementation of vfp for .Net (my words for techniucal reason, no trademark issues meant/implied) they would have to be rechecked. But for alines() for instance I am sure that Kamal's base idea is solid, it just has to be put more in line with the actual vfp working. Could the preference for vfp code be connected with an attempt to create a group from the current vfp pool: sure, and evangelists help spread the word. Last but not least: debugging might be easier if stepping through vfp code for the majority of potential users.
>
>But I were to take a wild guess: Samuel posted that they are partially reusing java tools AFAIR. Assuming that ETec has strong vfp streaks, at least more than a passing knowledge of java and .Net, why should they restrict their vfp compiler to dotnet ? Speaking mainly from the point of a contractor for large clients in germany, vfp compatible code running inside a JVM (with the data engine and the scripting like feeling) would be more than double (doubly ?) worth the price of a .Net version to me - just from the "business" side.
>
>So how could they achieve this ? Either create parallel implementations in C# and java, use J# and java (as J# is also a dead end for future releases this might turn people away, but might work for a lot of runtime functions, especially with a clearly defined signature), or use a bootstrap approach and get a vfp version to port to other environments as well.
>
>Talking about such an idea "officially" at this time without also a working model might put some people off...
>
>@Samuel: Hope I am not again spilling any secret long range plans you already formulated behind closed doors<g>
>
>@YAG: Please don't take that as a MS bashing sour grape reaction. While there are definitely some things I disagree with (10 GB for the OS ? All those Windows-Update-backup folders and logs right inside the uppermost OS directory ? DRM mandatory ? No local cursor/database engine in VS <bg>?) I have also quite a few points to argue with blind java lovers *and* view MS developer still tools to be better than the java counterparts. But MS is not years ahead any more - and currently java is much more accepted over here for large projects.
>
>regards
>
>thomas