Future of VFP apps in Windows

[VFPTekTips1]

I have an app written in VFP. It does not require access to any DBF tables, but creates cursors that are indexed.

If I compile it as an EXE in version 9, what could make it obsolete after Microsoft ends support for VFP in 2014? More advanced OSs that don't support VFP 9 EXEs, etc?

If such a scenario could exist, would it be a few years away, a decade, ...?

 

[JRB-Bldr]

after Microsoft ends support for VFP in 2014?

The greatest resource for VFP support has for a good while now been in VFP forum's like this one - not via Micro$oft.

With that in mind, the issue is not: Will there be support? since we will most likely be around forums like this one for a good while yet.

The issue is more: Will Microsoft OS's eventually somehow make it IMPOSSIBLE to run VFP EXE's
So far the answer has been NO.

While it may take some environment setting changes to get 32-bit VFP applications to run in 64-bit Win7 environments, it can be done one way or another.

If such a scenario could exist, would it be a few years away, a decade, ...?

Whoever out there who has a crystal ball that can accurately predict where Micro$oft's OS's will go in the future, please also advise us on future investments to make so that we can make our fortune.

Good Luck,
JRB-Bldr

 

[VFPTekTips1]

Supposedly, Windows 8 has support for 16-bit applications:

http://www.askvg.com/windows-8-comes-with-built-in-16-bit-application-support/

 

[Olaf Doschke]

The end of support in detail means vfp is not included in testing of eg bugfixes or security fixes of MS in regard of vfp itself and other products. Eg if a gdiplus fix is done, as has been done in the past, this will not result in a vfp fix, you as developer are more responsible for that.

That aspect is not a big deal, really.

Even security bugs in vfp are also not that important, as they would seldom be exploited by malware programmers, they rather concentrate on widespread software, which foxpro is not.

Even if the day may come vfp doesn't run on windows 9 or 10, take a look back on how much dos apps still run in some dos add on or virtualised.

That is not the reason to migrate, but to integrate with newer stuff will get more and more complicated. Waiting for the day you can't work with your app is like running a car until your car breaks down, probably on the highway in the midst of nowhere. The return of investment is better, if you renew at some point, even if there are no new forms of streets an no new gas or other reason to upgrade from a car working.

It's the maintainance and further development that will get harder than with more modern tools. You stay behind. Don't only think in terms of investment done. Once that has more than amortized it has paid and squeezing out more may be less effective than investing into newer technology, optimising workflows. The main cost of software should not be in the creation, but in the usage. If you bought a million dollar car to drive a few mile per month, you better had used a taxi from the economical standpoint, which even includes the driver. So your software investments for custom development hopefully pay off, not just by consuming the time of developer staff, which is paid anyway, but by optimising the workflow of the software users, so they are more productive and that finally saves mony or get's more cusomters, more income.

And that kind of investment into new workflows never stops. You may solve such things on a totally different area than with software support, too, but software is the main motor of rationalisation today. If you don't see anything that could be done better, congrats!

Bye, Olaf.

 

[Nigel Gomm]

VFP will likely run on intel based windows machines for many years to come but there are soon to be ARM based windows 8 machines that will not support x86 based applications. dotNet applications will need to be recompiled for ARM; VFP doesn't have that option.

Plus the days of being able to assume that 95% of customers run windows PCs are long gone.

But it's not all doom and gloom... legacy vfp apps can be migrated to 'the cloud' (for some definitions of 'the cloud') using remoteapp and terminal server ; with that your vfp application will run on a windows server and used by customers with pretty much anything including Macs, iPads, iPhones and ARM windows.


nigel

 

[Olaf Doschke]

You should also mention ARM based machines will stay in the range of smartphones, handheld devices and notbooks, PCs will still be intel based. It's also untrue you can simply recompile for ARM and are done. It's likely ARM based machines will only see the metro surface of Windows. It's true no x86 apps will run on ARM devices, so also not the classic desktop.

PCs will continue with x86 processor architecture.

But it's true, aiming for android apps, apple apps or other in the future windows will need other tools than VFP. That also is true right now including Windows Phone 7 and Windows Mobile 6.

It looks like you can easily support those mobile platforms via HTML5 and CSS3 and javascript in the future, there are already platform independent IDEs for that right now. But of course you will not make your phone an office workstation. Maybe that day will come, as those machines are getting much stronger as first PCs were, but there will stay a gap towards desktop PCs for some time to come.

Just my 2¢

Bye, Olaf.