>Hi Ed,
>
>I'm a guy that has alot of time, energy, and money investmented in VFP, relatively speaking. I am looking for ways to protect my investment in VFP. The advent of Dot Net seem to be eroding the value the market once placed on VFP as a platform of choice for data intensive applications that could be quickly developed and easily distributed.
>
You don't believe that I have an investment in VFP?? Or that I have less of one than you do???
I'm extremely committed to VFP from a developer POV, but there are circumstances where it is not the best solution; I happen to work in one of the fields where this is particularly true at the moment. I don't bill myself as a VFP developer, but as a developer in a more general sense. I have no objection to doing part, or for that matter, all, of a particular job with another tool if it's the right thing to do. My skill set is language-independent; I solve problems, not VFP problems.
>Since VFP is win32 dependent, wouldn't this present a problem if Windows evolved into a Dot Net specific OS.
Only if Windows no longer supported the Win32 platform; we've already seen the evolution of Windows from a DOS platform to a Win16 platform to a Win32 platform, with varying degrees of backwards compatibility. I take it that you're planning to commit seppuku when a DOS app or two fail to operate properly under XP...
The fact that VFP as a language may someday disappear will affect some clients at some point down the road. I can see clearly enough that, given the years of lead time available, I can move into a supported platform and move my clients apps from VFP to another platform with no more difficulty than I had moving from any of the many languages I've worked in before even dBASE II was around.
>This begs the question whether 1) VFP would be rewritten to run natively in a Dot Net OS, even though it may not participate in Dot Net CLR, 2) would VFP be provided a win32 emulation layer on which its win32 apps could be run, or 3) would VFP not be ported to Dot Net and just fade away.
>
I'd bet that one or more of those would be true. There is still legacy support for DOS apps; DOS has been dead for quite a while - in fact, it hasn't really existed in an MS product since ME. We still have people actively developing in FPW even though MS dropped support for it over two years ago and it has some significant bugs that will never be addressed fully. There's still a WOW VDM supported in the current MS environment.
>I know that as OS system change they go through transation periods until the transition is completed. For example, Window originally ran on a 16 bit platform. When windows was moved to a 32 bit platform to take advantage of 32 bit hardware, C and C++ had to be rewritten to accommodate both 16 bit and 32 bit code. The window's OS, as well as all other applications, had to be re-compiled before they could run on the 32 bit hardware. Eventually, windows became a true 32 bit OS and 16 bit software would no longer run under windows.
>
Not true at all - there's still a considerable amount of DOS and Win16 code out there running under Win2K and WinXP, without recompilation. There's even new development done in these platforms.
>What do you see as the best alternative for VFP and what could we do as a community to needle Microsoft in that direction. I personal would like to see a native Dot Net port of VFP with VFP fully participating in the underlying Dot Net foundation, classes, etc. Is this possible?
I believe what I've been told about the sacrifices necessary to move VFP to the CLR, and I'd rather learn another language than sacrifice the things that make VFP a unique resource that is proper for many environments that are not suited to dotNet as it exists today. Then again, I use VB and C++ when they seem to be the right choice, too. And I'm learning to function well in the managed code environment as well.
