FoxPro 5.0a taking forever to load on Windows 7

Question

I'm assisting a company that is using fairly old software and they want to get off the old server and on to a more recent workstation. Here is their setup:

Windows 2000 Server (domain controller) FoxPro 5.0a as a shared folder (no database, just a folder with the data)

How they launch the Inventory system:

PC users double click a lucky.exe shortcut which is mapped to the server share in a \lucky folder. The only requirement for this to run is to map a driver letter E: to the server\lucky folder. When the exe is launched the custom FoxPro inventory system loads immediately. Everyone in the office uses this same method of opening and they can all run it at the same time. The data seems to be stored in a folder called \lucky\LU_

In this current environment the inventory system works fine.

Note: If I try to browse to the LU_ folder it takes quite a bit of time to display the files. I don't know if it's because there is 1gb of data in that \LU_ folder.

However, for the fear of the hard drives failing they would like to get rid of the Windows 2000 server and have the inventory run on a newer machine. So I bought a Windows 7 Pro workstation. Copied the \lucky folder and tried to run the inventory system.

It takes more than 4 minutes just to load the Log in screen. It's clearly hanging or doing something erroneous. Then a pop up asks if we want to RUN the exe). Clicking Run then takes another 4 minutes or so just to see the log in screen appear. I've tested this on a Windows 7 workstation and Windows XP - both have same issues. Once the login screen finally loads the system works fine.

So to recap, I am trying to get the inventory system to work on a Windows 7 Pro workstation but it simply takes forever to load.

Things I've tried that made no difference:

• right click "Run as administrator"
• Compatibility mode

Thanks in advance!

Answer 1

My original thought, I researched but couldn't find... however, in doing so, found some other things to consider.

The folder that you say just to browse the folder (via file-manager which has nothing to do with VFP) would indicate your folder structure is HUGE with # of files, not necessarily that VFP has a problem with large files. In fact, VFP can handle files as long as any single file is less that the 32-bit 2GIG single file limit. So a table (.dbf) could be up to 2 gig, its index file (.cdx) could also be up to 2 gig, and if a (.fpt) also exists could be up to 2 gig.

However, I would be more concerned with TEMP files. If the application over the years has had a history of creating temp files and crashing and/or never erasing them, I would suspect that might be killing the directory system, thus making VFP take forever just to find the files to get a file handle on them.

Since you are testing on another machine, I would look at what is truly in that _LU data folder and probably clear it out... such as look for any .BAK, .TMP files and for sake of not killing them, move them to another folder UP the hierarchy of your table structure, ex:

C:\SomePath\SomeFolder\VFP\Lucky move to C:\SomePath\SomeFolder\VFPHolding\Lucky.

Is the folder filled with other documents the system is creating or works with such as .PDF, .XLS generated files? Maybe these too are old and not applicable. Move to the paralleled folder just to be sure.

What is the TEMPORARY path for the system. That too might be filled with clutter. If you are not sure, there MAY be a file called "config.fpw" It's like an .INI file of startup settings telling VFP what mode to start in for exclusive, paths, and other environmental settings. If one is so available, please post it and it might trigger something.

Additionally, it may have a temp path folder that is pointing to the "E:" share location you are referring to. If so, that might be where all the clutter is hanging out and nobody just knew to clean it out.

Hope SOME of this enlightens you on things to dig into.

Answer 2

(1) The network implementation of post-XP Windows versions is not really compatible with workstations running earlier versions of Windows. This is fixable but it requires a lot of registry fu and farting around with policy editors. So make sure the network as such is working without a hitch and without undue delays.

(2) SP2 or SP3 of Windows XP introduced a 'feature' that makes networked file open/close operations slow as molasses. The 'feature' persists even in the newest Windows versions, which means that older programs that do rapid file open/closes have to be rewritten to avoid them lest they suffer a slowdown of several orders of magnitude. Fox doesn't do anything like that on its own but components included in the app might (in my case it was an OCX that we used to access multi-image TIFF files). Or the app may include code that does rapid appends to a log file, opening and closing the file each time.

(3) Windows systems growing wild tend to have huge PATHs. Make sure that Fox has the shortest possible PATH in its environment, since Fox uses it to search for stuff it cannot find using its own settings. If the app programmer relied on path searching instead of using qualified paths then this can cause extreme slowdowns, since everybody and their aunt has to append a dozen directories to the Windows PATH variable. Dead (inaccessible/unconnected) network shares in the path are particularly deadly.

Have you tried putting the shared files on a SAMBA server? Another thing to try is starting the app using the VFP8 or VFP9 runtimes. Or directly with VFP8.exe or VFP9.exe as a first test. If you find that the new runtimes work better, they can be downloaded for free from download.microsoft.com.

I'm running networked Fox 8 apps on a network with a mixture of anything from NT 4.0 to Phoney Windows 8.1, and I regularly do regression tests with all Foxen from 5.0 through the newest 9.0 on Windows 7 and 8.1. There is no fundamental reason why your app shouldn't work flawlessly.