Hey Ken,

Maybe you should rephrase that a bit....

Point is that you CAN use all those technologies if you interface with .Net via COM. Since COM interop with .Net is quite easy all of the new features (except maybe Avalon interfaces) are within reach of VFP applications. Since the CLR will be a standard Windows those services and the ability to do COM interop will be there natively on the systems that run this software...

It's obviously not the ideal mechansim, but compared to what we always had to do with Fox anyway (ie. wait for OS services to be exposed via COM), this is hardly any different.

+++ Rick ---



>>What's the difference between working on Longhorn in a COM environment, and writing a "Longhorn-specific" application?
>>
>>My understanding is that some of the project names you mention, such as Avalon are critical in that they are the user-interface to Longhorn. Are you therefore saying that I can write a VFP application on Longhorn, but I can't make it look like an app written in C# for example? Are applications that do not take advantage of the Yukon/WinFS new disk system going to have to use a thunking layer and therefore run slower?
>
>You will be able to create and run a VFP application on Longhorn, but it will be a 32-bit COM based application only and not use the new WinFX APIs, Indigo, the Windows Framework (.NET Framework), Avalon (XAML UI), etc. Now, you may not need those things for the VFP app you are creating and using. For more details, you're probably best off reading about the technical details online of these technologies announced at PDC last week.