The obvious solution is to do just that and buy 32-bit Windows. Of course, you aren’t going to receive a call from your client until after they buy the machine, and wiping the machine may not be a good option. You could use Virtual PC or other virtualization software to install 32-bit Windows on top of the x64 version and run the app inside that environment indefinitely. I think that will be a common choice. If you’re lucky, maybe the client will realize it’s finally time to get off of DOS/Windows 3.x and upgrade the app. Unless a complete rewrite is in order, the easiest and cheapest path will be to use VFP 9, which works just fine on 64-bit Windows.
Can we use the lifetime of 16-bit computing to predict the lifetime of 32-bit? Not really, but let’s do it anyway :). It’s hard to pinpoint the “beginning” of 16-bit, but let’s go with the dawn of the IBM PC in 1980. 32-bit computing clearly became mainstream with the release of Windows 95. In 2010, whether or not 64-bit will be considered “mainstream” is debatable, but it certainly presents a problem for 16-bit apps. With that in mind, it appears that desktop computing shifts to the next level roughly every 15 years. Again, this is just conjecture, but if that pattern holds true, 32-bit Windows apps (like those written in VFP) would continue to function until 2025. Virtualization may extend that further. That doesn’t mean they will be acceptable in the marketplace, any more than 16-bit apps are now, but they may at least still run.
2 Replies to “The End of 16-bit”
I still use FoxPro 2.6 – amazing (with .asp)
I can’t understand why Microsoft don’t give as a VFP9 compilated "as is" in 64 bits.
I am sure they have tools to automate it.