4

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!!!

Improve this question
4
  • 1
    Why wouldn't you want to virtualize it?
    – GregD
    Dec 31, 2010 at 18:24
  • Since the program got better with the features provided thanks to its ability to run under XP, these "services" must be retained (ie: networking, email integration). So unless there's something I don't know, I have to virtualize XP. That would require an additional license.
    – Rolando
    Dec 31, 2010 at 20:17
  • But the main reason is worse user experience and re-training.
    – Rolando
    Dec 31, 2010 at 20:24
  • 1
    I tried XP Mode. The setup for the legacy app to work well in the virtualized environment was a bit cumbersome, the VM was slow, the support would be more complex. So in the end I decided to use Win7 32-bit as long as possible, after all the 32-bit workstations with 3GB run more than fine. I appreciate your effort and I thank everyone for your kind advices.
    – Rolando
    Jan 6, 2011 at 19:57

6 Answers 6

Reset to default
4

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.

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
0

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

Improve this answer
1
  • Win98 is no good because it doesn't play well along Win7 printing. DOS is no good they now require the new services provided by running the app on XP (ie: networking, distributed printing, etc). I tried DosBox in the past, but FreeDos was better, and I couldn't solve some issues. I'll look into the other suggestions
    – Rolando
    Dec 31, 2010 at 20:25
0

Run the app on a Windows 2003 Terminal Server

Improve this answer
1
  • old FoxPro DOS apps tend not to work well in TS. They poll for input in a loop and can drive CPU usage up to 100% quicky
    – Booji Boy
    Mar 24, 2011 at 19:38
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .