>Hi Ed,
>
>Would there be advantages in re-writing or porting VFP from it win32 C++ roots to a Dot Net language like C# or Dot Net C++.

Sure; it would be able to run under non-Win32 supporting platforms. My understanding is that a great deal of internal optimization would have to be sacrificed in order to do this; if VFP were not richly data-centric with its own native file system, the advantages of VFP would be lost as a result of VFP simply becoming another dotNet language option - it's the feature set and functionality of VFP that makes it an attractive product, not simply the xBASE-style syntax.

>Is this feasible, or would it present to many problems?

According to the VFP development team, who are the people with the best view of what would be involved, most of the benefits of VFP would have to be sacrificed in the process. I'd suggest that Ken Levy's postings are about as authoritative as we're likely to see.

>If it were feasible, wouldn't it require an extension of the Dot net languages and CRL, for example, so they would support native VFP cursor, tables, etc via a file share in addition to the current method of using recordsets in a front end app to pass updates to a backend server?


The dotNet environment can already work with our native file system via ADO and the ODBC (or better, the OLE DB driver in VFP7 and due to ship with VFP8). And VFP can work with recordsets - in fact, with the CursorAdapter class which is integral to VFP8, you can treat ADO recordsets as VFP cursors, including the ability to bind them to native VFRP controls.