>>I too have seen the videos about APPX (http://en.wikipedia.org/wiki/APPX). It will have full support for Win32 applications because it will also include all Win32 APIs. That is really good news. It implies that we are now able to migrate in a slow pace. All our current applications can be run as Appx and be sold in the Windows Store. And future developments can be done either in VFP or with the help of other languages/platforms or a mix. In theory, there's no need to convert anything. That was a different story when we went from FPD to FPW to VFP.
>>
>>So, I side with Tore Bleken that we can be sure that our apps will work till at least 2030 and that we'll even be able to use the Development Environment and the language to develop new stuff. And VFP is still among the fastest dbms'es.
>
>In addition to my previous post:
>
>From (as well as many other similar articles); http://www.tomsitpro.com/articles/windows-10-app-development-appx,1-2566.html
>
>...This is all well and good for new or upcoming applications, but what about apps built for previous versions of Windows? There is good news and bad news. First, the good news: Microsoft is trying hard to make converting applications to the AppX model easy. The bad news: chances are you will still need to rewrite some code.
>
>Microsoft is currently developing a converter tool, under the umbrella of Project Centennial, to automate the transition from Win32 or .NET to AppX. The converter will sit on the kernel and act as a filter by catching any files the MSI attempts to install and, hopefully, create a container for the app. However, a converted app will fail to run if it depends on kernel or user access. For instance, if your app uses a hardware sweep to identify the CPU serial number in order to license the software, the app will break as an AppX container ...
>
>So even a containerized Win32 AppX might not run out of the box without changes. In any case, my position stands - VFP apps (and other Win32 apps) may or may not work for ever and a day under Windows 10 if the underlying OS is being changed. If the host OS changes there is a possibility of apps breaking. If one can virtualize a Win32 app then you are not really running that app under the OS anymore but within a virtual container or virtual machine. That's a different argument.

Yes, any bindings to hardware, like a check of the harddisk's serial number, will frustrate the converter, because it will write down the hardware info of the computer it was converted on and later will use that in the setup/start of the appx. This drawback is okay, imo. I can live with it.

There will never come a Windows 10 version that'll gonna break your appx-code. The virtualization is no longer a workaround, but from now on it's part of the core of the os-model. I'm not entirely sure on this, but I assume that EACH application (windows 10 native or not) will gonna run in a virtualization sandbox. And MS has developed a model that will guarantee support of all stuff that can run in the current os.