Hmm. Sounds as if, in theory, you're right. Would be interesting to see the results. Of course a VFP app (or, for that matter, any desktop exe) is not, unless it is trivial, going to run well on anything other than a desktop/laptop device without re-writing the UI with XAML.
Watching this :
https://channel9.msdn.com/Events/Build/2015/2-617 I was struck by how closely it follows the Android/IPhone models. Although perhaps not surprising since it has to cope with the same limitations....
>The containerization technology is Microsoft's way to go to ensure that all the legacy application will still work in the future. It enables Microsoft to further develop Windows without having to bother too much about backward compatibility. It will also support VFP, as to my understanding. See also:
http://fox.wikis.com/wc.dll?Wiki~Windows10ProjectCentennial>
>Win32 merely refers to the 32 bit Windows versions. (The containerization technology will also support 16 bit.) There's no requirement that apps use the standard featues of those Windows versions for creating windows and input controls. By the way, as I understand it, the vfp-windows are formally Windows windows. It are only the controls within those windows that are vfp native.
>
>
>>Don't think so - VFP is not a 'Windows App' in that sense (e.g. does not use standard Windows input controls etc.)
>>
>>>VFP app modules, probably not suitable, but a VFP Win32 exe might be (?).
>>>
https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root>>>
>>>
>>>>Isn't that all about converting Windows applications to UWP ?
>>>>Since FoxPro is NOT a windows application I don't think it's relevant......
>>>>
>>>>>Hi All,
>>>>>
>>>>>In 2015 Microsoft introduced the phrase 'Windows Desktop Apps' for PC-applications. This month they demonstrated the preview of the ‘Desktop App Converter’. The claim is that legacy apps can run without much adaptations inside a 'container'. Moreover, extensions can be built with the legacy platform, but also with newer platforms.
>>>>>
>>>>>I interpret this as the claim that, in time and gradually, we can build new modules and/or replace existing modules with another tool/language. Eventually the application might be totally VFP-free. However, esp. one question pops up:
>>>>>
>>>>>Modules (.app) in VFP are aware of the open tables/cursors, the public/private variables and the various SETtings. Will we be able to build a module with such a new tool/language that is also aware of open tables/cursors and variables??
