I support a company that has a very old, mission critical, FoxPro for DOS 2.6 (FPD) application.
For variuos reasons the company didn't adapt/migrate their app, which, ironically, has been running even better under Windows XP (and 32-bit Win7) because the OS allowed new features like more reliable networking, distributed printing, email integration. Unfortunately for this company, most new machines now come with a 64-bit version of Windows 7, which is incompatible with their FPD app.
I know this time the writing is on the wall: the only long-term solution is to migrate their app. But I wonder if anyone can suggest a temporary alternative path, which doesn't involve either:
a) downgrade 64-bit Windows to 32-bit, or
b) run the app on a virtualized 32-bit XP
Thanks!
PS: Happy New Year!!!
It looks like you don't have many viable choices.
The easiest and fastest is b option using XP Mode. XP Mode, as a virtualization option, integrates the installed application in XP, in Windows 7.
Give it a try.
My guess for the reason that it doesn't run and will not run is because it's actually a 16-bit application. Apparently, Win64 doesn't include the WoW Win16-support subsystem required to run 16-bit apps.
You can definately run 32-bit apps on 64-bit windows. But if yours is 16-bit then you're going to have to run an emulator.
If it really is 32-bit then make sure the 32-bit libraries are installed and available. Also make sure to disable Data Execution Prevention or add your app as an exclusion to it or it also won't run.
All the old 16 bit addressing compatibility modes were left out of 64 bit mode when AMD developed their 64 bit extensions to the x86 processor. This makes it impossible for Windows on Windows 64 bit (WOW64) to support running older 16 bit software in the same way WOW32 is able to on a processor in 32 bit mode.
The 32 bit versions of Windows 7, 8, 8.1 and 10 all still support 16 bit software - you just need to enable the legacy feature NTVDM (NT Virtual Dos Machine) and can even type
command
at a NT command prompt to switch to a DOS command line.I would suggest running it in a virtual machine using a 32 bit version of the main OS the company is currently running - so Windows 7 32 bit for now.
you can run in virtualized Win98
you can run in virtualized DOS
you can try in DosBox under Linux
you can try in Bochs x86
you can try Wine under Linux
you can try Cedega under Linux
Run the app on a Windows 2003 Terminal Server
It's a little late perhaps, but you could try this: run the app on a Windows server, then install OpenSSH and configure passwordless login for every user. Kind of like using Terminal Server, but may avoid the problems you anticipated with it. Also, if the users are accustomed to cmd.exe you can try ssh'ing from it instead of Putty or some other terminal emulator/ssh client, but the feasibility of that depends on your app mostly.
If done right and with a little luck they might not notice they're running the app somewhere else at all.