>I think you're still stuck on VFP versus SQL Server when many here have delivered apps using both for 20 years. Also the idea that a particular 4GL can only ever be used with obsolete runtimes and IL. Do you know what other vendors use to create their C++ apps - or even their assemblies?
>
>>>As opposed to not having to pay an extra 1/4 million dollars to have access to an antiquated desktop app and have a windows admin create and delete user accounts all day long when SuzyQ in HR can do it from a website.
>
>Maybe check out MS revenues from servers and Azure. Falling rapidly in line with your decrees? Err, no. 90% growth last reporting period with the cloud division up to $5B sales (compared to Amazon's $20B) but MS saying they're tracking strongly for $20B. They don't call it RDS, but that's how you access an app in Azure.
>
>>>VFP is not VC++, and VFP would be the development language yes? The client will care. Or at least the ones I've known sure care.
>
>No, VFP is an obsolete IDE. for the C++ apps the "language" includes ASM, VC++ and xbase converted to C++ for compilation using MAKE.

...but the code is written using the VFP syntax and language via the IDE -- all of which are obsolete. ...and all his is done using hacked software that violates the MS license agreements.

>>>Contractor A: I will write you an app...
>
>While I certainly get your point, IMHO you're stuck on your own contractor anecdote. I have no experience of that and can't comment, except that in 2017 I wouldn't offer a VFP app for somebody seeking bids for an app they'll own themselves.

...or anyone that is licensing the software either - all for the same reasons.

But there is still practical uses for doing this. If you have a legacy app that for whatever reason needs to stick around - there are some serious advantages to putting it on a server and having users remote into the app to use it. For one you don't end up supporting everyone's desktop machine or have to deal with pushing updates to all the machines. But there are a couple of huge problems with doing this as well. Biggest issue you will run across is when it comes to printing reports. If all the users have different types of printers you can end up in a no-win situation real quick. There are ways to map the printer via RDP (at least in the windows client) so that you can print locally - but this has HUGE problems. First you have to find a way to setup everything just right so the customers can't see each other's printers -- aaand you have to install those print-drivers on the server as well. Now that itself can cause a major problem because some of these drivers conflict with each other - and what ends up happening is the reports don't print right for some of the clients - 99% chance that will happen too. There are some 3rd party tools I've seen that supposedly deal with this problem - but they don't work very well and in some cases not at all, and cost $3,000 to $15,000 per server. The other option is on the server side to print to a PDF, then push the PDF file up to the cloud, then make them download it from the cloud on their local machine if they want to print it - a big clumsy hassle for the user (they will hate you) It's sort of a catch-22 situation really. Either you save them license fees and server costs and printing problems and just put the .exe on the workstations and force them to use windows machines and go though the hassle of setting up ODBC connections on all the workstations and end up playing tech support for all those workstations - or deal with the extra costs and the printing problems and put it on a server and let them remote into it. Either way they loose. At the end of the day, if it's a legacy app - don't touch it - fix bugs or whatever to keep it alive - but don't go wasting time putting it on a server unless they don't plan to print from it (maybe toss a copy of it on a server for the occasional user to have access remotely with an RDP client, but goodbye printing). If it's a new app, then it simply needs to be a browser based app in this day and age.