>As far as I can tell, CLR is akin to a Windows extension that will be "there" in Windows by default and can be called on and shared by complying apps, just as Windows handles, API calls, standard ActiveX and fonts are now.

AFIAK, you're right here.

>So isn't the CLR sort of like a giant generic VFP runtime dll with calls to be used for common functions by lots of apps?

Yup.

>If so, then if MS included the VFP runtime in the system folder "by default" when windows is installed, we *do* have the advantages of and are sort of part of the CLR?

That's a pretty big "if". I would be happy if we could get that now, but we haven't. Why would we get it with the advent of CLR? FWIW, some versions of the VB runtime have been included with various versions of Windows, but the VB guru will tell you to never develop with those versions in mind, because they are guaranteed to be old.


>If I am right, surely the technical question is "how much of VFP's 6Mb runtime dll can go (and needs to go) in the CLR". If we are to use Winforms, I assume that much of the UI can go there. Maybe all of it.

I really doubt that VFP will drop support for scx forms any time soon. And if we are to use WinForms, you can guarantee that we will lose local data access abilities in favor of COM access to data (ADO). Granted, for VFP data, this will be much nicer with a VFP OLEDB provider, but it's still quite a change.

>How big is the CLR anyway?

I'm wondering that myself.