I.m not as tech savy as most of you, so this might be wrong. But.... I keep wondering how VFP will run in new operating systems and two and four core CPUs in the future. Will a technical upgrade leave us behind? When will that upgrade occur, and when?

>The point here is not that new code could be written in whatever language with only minor syntactical differences, the real attempt here is to not lose the entire value of the millions of lines of existing code. This is something that Microsoft seems to "forget" at every level when a new version of their products are brought out. Ever have Excel or Word macros that broke between versions? And how about even their versions of the C compiler and MASM? VFP has been very good maintaining a pretty solid "backwards compatibility" considering the very different philosophy of Windows programming vs. DOS programming. Is 100% of the code transportable? Of course not, but it all wasn't disposable, either.
>
>
>>I hate to be a naysayer here, but 'what's the point?'
>>
>>Assume for a minute you could indeed duplicate the full language and make it more or less work the same as VFP. What do you gain?
>>
>>The real key and really the only feature that VFP has that .NET lacks is native data access language to run dynamic inline SQL and Data commands and access local cursors. Nearly all of the rest is just minor syntax (with the exception of evaluation and dynamic execution which likely wouldn't work without runtimes either).
>>
>>No matter what you do you are likely to loose that functionality with any compiler's/tricks/workarounds. Without that what do you really have? Just another language (JAL) in .NET that isn't any better suited to deal with everyday programming tasks than is C#/VB etc.
>>
>>Whether I use a function like your Between or overloaded versions written in C# code (which would be more code but not much) what does that buy me? Very little.
>>
>>To do this right a lot of work would need to be done along the lines of IronPython (dynamic language support for .NET) to provide the untyped/duck typing approach that VFP uses and more importantly it would require a local data engine and full SQL language parser to get the DDL stuff to run along with a local cursor engine.
>>
>>The latter is no trivial task as Microsoft is now finding out as they are building LINQ and DLINQ and trying to shoehorn a dynamic syntax into a static language. There are many, many gotchas and tweaks required to make this work and that is really the key feature that .NET has been missing IMHO.
>>
>>All the rest is negliable... VFP is a nice all around language but the only unique feature (to xBase) is the sql data language and local cursor engine. Take that away and you have an average environment that is not anything special over other tools and getting up to speed is a matter of syntax.
>>
>>VFP is a great tool - if you want to use it, continue to use it. It's not going to die out over night with official support way off in the future.