>Doug,
>
>>What if Calvin extracts that portion of the VFP compiler and allows VS7 to use it when it detects VFP code? The thing is is that either way you go the code still has to be the same. In this case isn't this just a case of packaging?
>
>The VFP compiler would of course be used to compile VFP code. My question is whether we will see special compile options that allow generating Microsoft Intermediate Language (MSIL), which the CLR will then JIT-compile. That would mean the VFP runtime would not be needed -- but would probably mean that certain features not supported by the MSIL (like Macro expansion and the data manipulation commands, perhaps) would not be available for that specific compile option.
>
>Just thinking out loud here...

David,

Hmmm.. I can see what you're getting at. My guess would be that we'd get the compile stuff. Thing is... When you create a COM object the VBR (Visual Basic Resourece??) file is in fact a VB file. Or at least it has a VB header string in it. Again, just wondering out loud here but perhaps with that file you could get to where you want to go.

I think no matter what that it's pretty obvious we'll have some sort of common standard there and whether or not VFP is a sub/super-set remains to be seen.

After watching this product migrate from FoxBase 1.02 to VFP 6.00 I have been very impressed at how the developers have been able to keep backward compatibility and at the same time include state-of-the-art functionality like COM objects. That is where I get my optimism from.

Best,

DD