>>I personally think those 3 files should be installed by default in all Microsoft OS's. <bg>
>
>I've heard this before, but that would mean VFP would have to be released only when new versions of Windows are released, and I'm sure you don't want that. Microsoft wants to release new versions of Visual FoxPro more often than before (much less time than was between VFP6 and VFP7). Part of this ability comes from the fact that VFP is no longer bundled and scheduled with Visual Studio. As you know, shipping is a feature. :)

Ken,

Thanks for your input and response.

I have absolutely no knowledge or experience with inter-team procedures at Microsoft, and I understand that to be a huge consideration.

From a purely technical and practical standpoint, would it be impossible to keep those files updated through periodic OS-related downloads and updates, much like the Windows Media Player, DirectX, XMLDOM, OLEDB and ADO services. Are all of these components controlled by the Windows team, or are some of them separate, small units who coordinate efforts with the Windows team?

The benefit lies in the .NET future. Rich-client applications that depend upon the VB and/or VFP runtimes would be practical for Internet (not just intranet) applications IF the user did not first have to figure out how to download and install the runtimes, and that over a slow connection. I think rich-client apps and web services will be a hot ticket, but adoption will be limited if users have to do more than is required to download a "plug-in".

Actually, maybe the best scenario would be to keep the VFP runtimes separate from the OS, but allow for auto-download/installation like plug-ins. That would not solve the slow-download problem, but it might eliminate some of the "ties" to the Windows team and schedules, which sound, from comments by you and Mike Stewart, to be impractical from a management standpoint.

Please feel free to correct me when my assumptions and/or "facts" are wrong.

I'd like to see VFP app installation become much easier than it has ever been, to the point of making it practical for "anonymous" users on the web to quickly download and run a rich-client, web-enabled VFP app without having any particular "know-how."

I believe this kind of technology could play a positive role in Microsoft's .NET plans, as well as helping VFP developers and our end-users.