>>>The problem with that of course is the cost of the terminal server licences...sadly if people are remoting into a windows server to use a VFP windows desktop app, it's time to toss in the towel and move on.
>
>As I said, if clients already require users to remote in to run business apps, including browser apps: then the wider availability of RDC can perpetuate previously deprecated Windows apps IMHO. We moved most of our stuff to browser in the early 2000s, and are now offering tweaked old faithfuls again. Performance of VFP Compiled apps: unbelievable.
>
>FWIW, while huge corporates have resources or a business requirement to expose web servers to the wild, not all businesses want to do that. Especially when we keep seeing huge data breaches via hacks and leaks. E.g. this year's Equifax leak exposing 145M people in the US to identity theft because hackers found an Apache Struts flaw in a sleepy corner of an online disputes portal. The churn of Rube Goldberg dependencies and vulnerabilities almost guarantees something like this will be missed eventually.
>
>Which is why many/most of my clients prefer to set up their doctors' and others' personal devices for RDS access. Nothing exposed on the web so no risk of illicit hacking from Ukraine or wherever. As for utility: what's the difference remoting in to use a browser vs a Windows app? Not least since some prevalent systems insist on IE for desktop (because cross platform is too expensive, they say) and I've watched doctors cheerfully navigating IE via RDS from their Macs or even a pad.

That is not as safe as having required VPN to access a webserver on an intranet plus it would cost quite a bit more money too - it's not just the terminal server licenses you have to consider but the windows servers you need as well. I can pull a RDP password out of a pc in about 2 seconds. We do not allow any users or doctors offices to access anything here unless it's via VPN on our intranet if they are remote. The VPN clients are setup so when they connect to the VPN, it kills all other internet activity on their machine other than to the intranet and servers and such they've been given permissions to access.

>>> The Android client has been around for a long time, and there have been ways to remote in using a browser too for a long time -- but really it's antiquated to do all of this.
>
>IMHO the browser is becoming a liability. Too much complexity, too much Rube Goldberg, too many hackers motivated to sneak in to destroy your reputation and/or business. And the more clever bits you include to mimic the responsiveness and features of an ordinary Windows entry form, the more risk of sneaky vulnerabilities taking you down. If the essence of quality is standardization, then the browser milieu is at war with quality. ;-)

VPN.

>Why expose this to the wild when for a few bucks- as little as $100 per RDS CAL according to a quick google- you can keep the barbarians outside the walls? Compared to what cost of having a few million patient records stolen? I can answer that one: check out the story of Accretive Health that was flying high until one employee lost control of just 23,000 patient records. They lost statewide contracts and suffered huge business loss, eventually changing their name this year to try to put it behind them.

VPN.

> >>The new 64-bit compiler helps extend the life of VFP more than anything if you ask me -- but only useful for local network desktop apps. And doing new development with VFP seems like you would be doing a dis-services to the customer as it's not even supported by Microsoft.
>
>VFP Compiler fixes the known bugs that MS couldn't fix and assures longevity by compiling up to the latest VC++ including x64, though VFP's remarkably small memory footprint means there's few if any reasons to use x64. FWIW, pulling out mothballed Windows apps (we moved most of our stuff to browser in the early 2000s) and VFP Compiling delivers absolutely staggering performance. I suppose that's not so surprising when 133Mhz Pentiums were just released when VFP3 came out.

..except that 32 bit is going away and sooner or later you won't be able to even run a 32 bit application anymore - just wait - a version or two more of windows and that compatibility mode will disappear. Plus, with the 64bit version you can use the 64bit ODBC drivers - which may be a requirement depending upon what database you connect to. But ..... that is not an official VFP version - and as matter of fact if MS ever wanted to be jerks about it they could bust you for breaking user or license agreements just by using it. Odds are that will not happen - but still, you're taking a chance and many companies are not interested in anything that is borderline sketchy like that. ..and then there is the issue of VFP not being supported by Microsoft anymore. - an instant deal breaker for most big companies - especially if you're dealing with medical data.

..that being said - VFP can have uses in the middle-ware arena like for data translations -- but even that is pretty much squashed by SSIS and DTS packages now.

If a company has a legacy VFP application and doesn't have the resources to re-write it, then sure these RDP clients and 64-bit compilers can extend the apps life some - and that is a great thing for sure. But new development? I just don't see that being a wise decision anymore. Times have changes - technology has moved on - and VFP has was left behind by Microsoft.