About Win2K:

I have experienced major slowdowns of FWP26 apps on Win2K. I have also heard grumblings from people running VFP6/7 apps on Win2K systems. Not ALL of them -- some run just great. I haven't run into slowdowns with Win2K/VFP apps yet, but based on what I've heard, the time is coming. Must be something in Win2K settings. As I don't have Win2K installed here, I can't test any of this, but I will be testing at a client site next week.

Ed Rauh, active UT member, had a number of ideas about the FWP26 part of this -- here are some of them:

The WOW VDM is the Windows Win16 and DOS emulator module for NT/2K/XP; it actually controls how memory and resources are made available to Win16 and DOS apps. A .PIF file is associated with each such app either implicitly or explicitly, by finding the executable, right-clicking in and selecting Properties from the drop-down context menu, a tabbed property sheet for the app is displayed. One of the tabs is memory.

You need to control the memory made available to the application. With Win16 and DOS, there is a problem allocating >16M oA to the process IAC. For FPDOS 2.0 and 2.5, a number of varieties of memory types need to be allowed - either EMS or XMS, such that the total memory allocated does not exceed 16M of both conventional and extended memory.

FPDOS 2.6 standard must be given 640K of conventional memory, no more than about 15MB of EMS, and no XMS or DPMI memory. FPDOS 2.6 Extended must be given 640K of conventional memory, and no more than 15M of DPMI memory. In both cases, all other extended memory types (standard, XMS and DPMI, extended, EMS and XMS) must be set to 0.

FPW should run in a separate VDM rather than a shared VDM, and should have DPMI memory allocated to the process.

There are many other potentially useful settings in the PIF; you'll want to explore the tabbed property sheet dialog and experiment with screen and font behavior, background execution and related process properties.

HTH; it's a fair amount of information to digest to understand all the whys and wherefors of the subject

***

Another, more general list (which should apply to VFP as well):

Windows Server caching of the data files; you may need to adjust the property sheet of the folder containing the data, or change the operating mode of Fox. One important tip would be to have a separate CONFIG.FP (FPDOS) or CONFIG.FPW (FPW) per machine, that sets it's TMPFILES to a local drive - that often is the problem, the competition for temporary drive file allotments between systems. I normally do this by creating a DOS environmental variable to direct Fox to use the local drive, and to use a local FoxUser resource file. Add the following line to each station's AUTOEXEC.BAT or AUTOEXEC.NT, as appropriate:

SET FOXPROCFG=C:\FoxFiles\config.fp

SET FOXPROWCFG=c:\FoxFiles\config.fpw

On the local C: drive, create a folder called FoxFiles. Add two text files as noted below:

*CONFIG.FP

TMPFILES=c:

SORTWORK=C:\FOXFILES\

PROGWORK=C:\FOXFILES\

EDITWORK=C:\FOXFILES\

MVCOUNT=1024

RESOURCE=OFF

*CONFIG.FPW

TMPFILES=C:\FOXFILES\

RESOURCE=OFF

If you need a resource file (FOXUSER file), make separate copies called FOXUSERD.DBF (and .FPT) and FOXUSERW.DBF; for the CONFIG.FP, use the line:

RESOURCE=C:\FOXFILES\FOXUSERD.DBF

and for the CONFIG.FPW:

RESOURCE=C:\FOXFILES\FOXUSERW.DBF

to maintain separate, potentially incompatible FOXUSER file versions. You'd then omit any settings in the app-local CONFIG.FP or CONFIG.FPW, and move them into the workstation-specific CONFIG file; this also gets around the need to have a read-onlyFOXUSER to share resource files.