Visual FoxPro 6 - Windows 10 Issues

[RWilkes]

Finally bit the bullet and installed Win 10. After a few tweaks, seems OK.
BUT
I support several legacy apps written in VFP 6.
They seem to run OK.
A problem in the development environment, though.
I can open & edit project files with out error.
When I close the project, VFP craps out with a system error message: "Microsoft Visual FoxPro has stopped working"
The VFP6.exe is set to run as Admin and I had no problems in Win 8.1.

I'm at a loss...anybody have any suggestions?

 

[audiopro]

Does it respond if you wait?
The reason I ask is I see '........... is not responding' in several programs under WIN8, but they recover eventually.
I keep seeing the experts stating that 8 and 10 are more efficient than previous versions, that may be true if you are only running Facebook and checking the weather but my WIN8 machine works far slower than my XP box ever was. I know I will have to make the WIN10 leap at some point but I am reluctant.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, Keith

"<<Application>> has stopped working" is not ""<<Application>> does not respond", "<<Application>> has stopped working" is the message Windows shows in case of C5 errors since Vista and you find the typical mentioning of the vfpX.err file in there.

RWilkes, what I'd do is recreate a PJX under Win8 and retry moving that project to VFP6 under Win 10. The error might also point to a problem in only one file, eg foxuser.dbf, maybe also a file of the PJX.

If all fails you won't find many people using VFP6 anymore and could easier update to VFP9 than finding a stabilization of the VFP6 IDE under Win10.

Bye, Olaf.

 

[RWilkes]

AudioPro: ... WIN8 machine works far slower than my XP box... I have quite the opposite experience. Seems like my XP box has a built in 'planned obsolescence' app and gets slower every day. Ergo the aforementioned upgrade to Win 10 (I got tired of the <ever more often> nagging) and trying to get VFP 6 to run on Win 10.

Olaf: Thanks for the reply. I took the 'least intrusive first' approach and deleted the FoxUser files. That seems to have fixed the issue. I've had to do that before and had forgotten about it.

As for the "won't find many people using VFP6 anymore", I agree, but these are apps that I wrote long ago, and still work as designed. I'm trying to upgrade them, and have been 'in process' for a number of years. It is, however, a 'pro bono' situation and tends to get set aside when 'real work' is available

TNX, again, for your replies.

 

[Olaf Doschke]

Makes me wonder what type of problems you have converting, VFP9 is downward compatible and the conversion is easier than with making the jump from a legacy app.

Bye, Olaf.

 

[audiopro]

I have 6 XP boxes at various locations using VFP6 and they are as fast today as they were 100 years ago when I wrote the EPOS program. I have been hounded constantly by some of the shop employees to upgrade to something 'modern' but the system is fast and reliable and that is all the client needs. I have tested it on WIN8 and it is easily 25% slower but that could well be all the junk which is shipped with WIN8.

It seems that everyone is in a hurry to upgrade everything to the latest fad but I am finding many of the new solutions are noticeably slower and far more complicated than the older, reliable solutions.

Progress is great as long as it is forwards.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

The motivation here is not to be more modern, but to have one development platform knowing to work in Win10.

As it seems, the problem went away with a broken foxuser.dbf, so that motivation is lost.

What's true is: DBFs don't get faster due to VFP version changes, but due to faster hard drives only. DOS apps profit from hardware accelerations in the same manner as other apps and in many cases a modern UI look is not needed, but you also block out many things. I once was in a pub in prague and they had a Fox Dos POS system, fine that it still works, but now try to add smartphone near field communication (nfc) for micro payments, for example.

If your app becomes slower on a newer OS, the first suspect is the bloatware, really? Well, that's very short sighted.

Bye, Olaf.

 

[RWilkes]

Olaf, a straight copy & run would be fairly easy, with only a couple problem areas, e.g., SQL aggregate Group BY.
But I'm trying to also upgrade my framework (from the very old VFP 6 version) to a more current VFP 9 level, so it involves a lot more work and testing...