Win2000/XP EXE freezes 1

[crobg]

I have a FoxPro Application that was built using version 2.6. The developer was demostrating it on a machine at our offices and it continuelly locked up after a few minutes. This happened on several different Windows 2000 and XP machines. (Win2000 SP 4 and XP SP 1) The only way he could make it work was to boot in safe mode.

We both searched the Microsoft KB and came up empty. The support libraries are FoxPro 2.6 EXE Support Library (X). All of the systems in question are running on a Novell Netware 6.5 network, client v4.9 SP2. I have no problems with the program on Win 98 machines and he claims to not have this problem on other NT/2000 machines.

I have tried running the app from a shortcut, cmd.exe and command.exe. We have modified the config.nt file to have files set to 200. The files are stored on the local hard drive.

 

[TamarGranor]

If you need to keep a FoxPro 2.x application running today, you may find this e-book helpful:

http://www.hentzenwerke.com/catalog/painless.htm

Tamar

 

[rgbean]

This has been discussed many times in this forum. You may want to start at thread182-943193. After that, try the search button above.

Rick

 

[crobg]

I have made sure the DVZPATCH has been applied. I changed the following entries in my config.fp file:
MVCOUNT=50000
MEMLIMIT=60,16384

I have tried TameDOS. All to no avail. The program crashes at exactly 30 seconds after certain menu screens. With TameDOS the time is less 10 seconds after the action.

 

[rgbean]

DZPATCH is only meaningful if you are running FoxPro for Windows. Based on your other information it sounds like you are running FP DOS.

Does this application use any .PLB or .BIN files?

Rick

 

[crobg]

There aren't any in the application's folder.

 

[rgbean]

Is there a possibility that the application opens up more than the default number of files? i.e. Have you changed the CONFIG.NT file to include these lines:

dos=high, umb
device=%SystemRoot%\system32\himem.sys
files=220

Rick

 

[crobg]

Yes, my config.nt file has had all those lines. I also have played with all of the Memory and Misc tab settings for the PIF file.

 

[rgbean]

Well, I really don't have any more ideas, except to either setup a dedicated DOS machine to run this application, or use Virtual PC to run the app in a true DOS environment under Windows XP. I've done both of these in the past. In fact I use VPC on this machine to check out FP 2.0, FPD 2.5b and FPD 2.6a problems.

Rick

 

[crobg]

Thanks for all of your suggestions. I agree with you that this will need to stay in a DOS based OS (like Win9x or VPC) or get the developer to migrate the app to VFP.

 

[crobg]

**Update**

All of the computers that have been crashing have lacked an installed printer on LPT1:. Once I installed a printer on LPT1: (regardless if one was attached or not) the 30 second crash went away.

 

[rgbean]

Thanks for your update, it's obviously not the first thing I would have thought to check!

Rick

 

[crobg]

The developer is going to move the project to VFP. I belive he is going to do a simple port and update code where it is not compatible. What should I expect the interface to look like?

 

[alvechurchdata]

What should I expect the interface to look like?

If the developer's just doing a straight recompile of a DOS program then I fear that 'ghastly' is the only adjective that springs to mind.

List boxes, labels, and text boxes come across OK because they're much the same in DOS and Windows. Graphical controls don't work so well. Things like buttons and tick boxes get converted from their DOS text forms of < button > and [X] to their modern-day graphical equivalents but of course the text versions are only one line high so the graphical buttons can only be one line high too.

You'll have the urge to rearrange the form, to make the buttons bigger and to move them around. But the form only exists as a sequence of @ GET commands with X and Y co-ordinates. It's usually quicker to design the form afresh in the VFP Form Designer.

Sorry to be so negative. The bright point is that all (99% ?) of the logic behind the form will run unchanged.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[crobg]

Thanks, there is not a lot of graphics to begin with. And most of the check boxes and buttons are in file access windows, that appear to be OS driven. So maybe it won't be to bad. I'm keeping my fingers crossed.