Hi, Pertti.

I understand our position, and I just wanted to tell you some ideas that may -at least- contribute to alleviate some of your concerns a bit more:

>Yes, of course MS will keep the product running as they have promised, until 2015. I'm looking at the long-term picture, though, because 8 years goes by pretty fast and after that it is luck of the draw as to how long VFP keeps running. If 'm going to have to re-tool and re-write and re-educate myself and my staff, I need to start doing it very, very soon in order to BE ready and HAVE everything ready for the change in 8 years.

If the applications didn't need any of the stuff that newer platforms provide and it is viable as-is, even facing a non-compatible OS upgrade, the industry developed technology to help in this quite common scenario, which goes to a wider range than VFP: virtualization. You could always been able to run your apps boxed in a virtual machine running the appropriate OS. This is possible and efficient right now, and in 8 years it will surely be possible to make it even more transparent the underlying OS for a given application (it is starting to happen now -it just have to become mainstream).

>I'm personally not panicking, I am just making long term plans based on the current information -- luckily at least the fuse is long enough here for as non-panicked, organized transition plan and execution. I certainly would much rather not rewrite my many, many large, stable, fast and flexible applications in some other language. Instead, I would much prefer improving the apps incrementally in the same environment (or at least an environment close enough to it) that I developed my current programs with. Rewriting a big app is kind of like pressing a restart button on evolution -- there will be a lot of bugs, a lot of "tribal knowledge" to learn about the next tool, workarounds to keep the same functionality end users have gotten used to, etc. etc. Additionally, I will have to buy AND learn a whole new "ecosystem" for the new tool of choice (framework, CASE tools and their links to framework, data management and integrity utilities, installers, ...)

You know computing lives dog++ years, so an 8 year period will most probably bring so many changes that I can hardly imagine how to maintain a big app with the level of complexity you imply (by the amount of tooling you mention) without adopting new tools and techniques. Also, using the proper methodologies, partially porting code between different languages (mostly business logic) is not a really big problem. This is a huge topic on itself, but if you are interested and you didn't before, you may take a look at my articles for UT Mag (especially the Agile series and maybe the Design Patterns series).

>So, my main point is that ideally MS would make it possible for VFP developers to continue using the tool they have become experts on, even if MS doesn't support it any more. If all MS would do is set up a "VFP runtime maintenance" group which would only need to spring into action if a new Windows version breaks something in the runtime modules. SednaX and other extensions could then build on top of a solid foundation that won't just disappear all of a sudden.

I can't say for sure, and maybe Alan can come back and tell me wrong, but I believe that if even after 2015 something weird appears which doesn't requires a lot of effort (like the old speed bug) Microsoft might provide a fix, if they notice there is a fairly big community still needing that.

>Now that would be good karma, which maybe doesn't have immediate monetary value, but in the long run would serve MS well. What comes around goes around -- as a result of MS canning VB6 and now VFP and even majorly tweaking their flagship .NET product from one version to another (which often required some serious refactoring on the developer side), programmers might just draw the conclusion that MS development tools don't have the necessary longevity for long-term planning, and they would be better of looking elsewhere.

Judging by the numbers, I would say this is not happening. There are not drones of ex-VB6 guys going to PHP or even Ruby, while .NET adoption is growing fast. I guess that after all, people balance also what the vendor provides as alternatives, and what new features and capabilities justify the platform change, and in many situations it seems to be worth enough. With some skepticism, one can also consider that it is just the other platforms fault, falling short, but the net result is that .NET is doing fairly good.

>I have prior experience with this kinds of situations. Many years ago I had a pretty big FPM accounting application running on Macs, and it was actually relatively stable and the end users were quite happy to have a "real" database app running on their Macs. Eventually MS stopped supporting FPM, and things went still OK for a whaile, until Apple came out with Mac OS X. After that my app would not run on Macs any more, even in OS 9 compatibility mode, and I was dead in the water with the Mac programs. Game over in one day. I looked into FileMaker and Omnis and 4th Dimension as replacement platforms, but they just couldn't match Foxpro's flexibility, speed, IDE and functional breadth. So I dropped it.

Virtualization could save such a situation now. But of course, these problems were the cause, and virtualization is the effect.

>Then there were the timing problems in FPW runtimes that killed the program when processor speeds went over a certain threshold. Somebody actually hacked into the FPW runtime and managed to fix the problem, but that somebody sure wasn't Microsoft, because they had stopped suporting FPW by then. I considered this a lucky strike, because the problem could have been somewhere too deep in the bitwell for any hacker to get a good handle on it.
>It just goes to show what can (and usually) will happen to a development tool when manufacturer's support goes away.

I do remember that the FPW 2.6 patch was released by Microsoft and it can even be still around in the KB (didn't checked it), even while the product was out of support. I had several old applications running in such situations with happy customers not willing to change a bit on them, so we used the patch in many cases.

>In the end, this is surely not the end of the world, life goes on. But it is a **major** PITA, nevertheless.

Well, I agree it is far from what anyone could wish, but I think that it shouldn't necessarily be **major**. 8-)

Regards,