>>>As soon as they remove the support for Win32, they are obligated to change the name, or they will lose all credibility.
>
>FWIW, VFP is not trapped in Win32: I can compile my VFP apps to x64 today using VFP Compiler. The biggest impediment is that most of the add-ons we rely on are only 32-bit. West Wind, the Sweetpotato flls, etc etc, though theoretically these also can be recompiled to x64 and Chen is offering to assist. The big one is that 64-bit OS no longer comes with OCX for treeview and the like, so you need to purchase commercial options for anything that isn't a native VFP control and generally you'll need to re-do the interfacing code.

IMO vfp is trapped on Intel. I want to see the performance on ARM first before musing further about vfp everywhere in the next decade ;-)

MS killed the option of storing multisuser data in server hosted dbf via SMB2 thrashing all multi-machine-access ISAM-DBfile, even when they were ok from TCO in some cases and WAN search access was not needed. In the early days of vfp LAN was high tech, today coding for it is coding to the physical network implementation at the users site, which as we both know is an antipattern to use only if there is large compensation by other factors at this special site. That selling point, really big back then, has nearly evaporated.

For some use cases vfp is hampered by the 2GB barrier per file (when used in workstation mode, single user data slinging) - pretty certain that somebody without my long grown knowlede of vfp would be better served with something based on connected servers or importing directly into some "backend" server process used only locally and single user at the WS machine for datamining. But that limit is based more on the implemented locking mechanism than the 2**31 numerical value definig the border , no need to go to 64bit for a different implementation as long as you have support for long long in your implementation language.

Vfp being EOL forces you into Goldbergian structures for trying to use a current mechanism for display or communication. Even the ex/import of Excel is not really working well with sheets created by current version of Excel.

Yes, I also think that data from the multiuser dataserver store should be piped into a file based data store on the client machine, if possible with an option to pipe into memory if the programmer opts for that. It is IMO the best usage of the technology built and in place. But in the (biz) scenarios where this REALLY makes sense, you have most OOP programmers against you and the marketing of the server sellers: remember Oracle squashing WebSQL with MS looking innocent?

Hobby users are perhaps really better served with document databases: even most of us, knowing about the benefits of normalization, had at least sometimes to include memo fields for unstructured info, oftem later enhanced with minimal structuring (JSON, Xml, Ini) adding some "document database" functionality to the app