VFP9 exe runs slow on WIN7 64-bit machines

35 - 40 concurrent sessions running a single VFP9 exe file on a virtual (Hyper v) windows server 2008 R2 SP1 12 GB RAM 64-bit server. Host machine is a Windows Server 2012 R2 standard 486 GB 64-bit Dell T420 machine.

1 user can log in and a specific application task will take 8-10 seconds. Additional users logging in extend the application time to 35-45 seconds. A new Win7 professional 64-bit 4 GB RAM machines takes 1:10 seconds to perform the same task with multiple users logged in. Older style 32-bit machines seem to run faster than the 64-bit machines, but overall time to perform tasks has gotten significantly worse with all machines.

Most users are running WIN7 professional (mix of 32 and 64 bit machines). What can I do to facilitate faster application response time on our network? I assume from reading other posts it's not a VFP issue as much as they way the network is allowing data to be accessed. Is that correct? If so, what's a user to do that depends on VFP9 ??

Thanks for your response.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Visual Fox Pro is a 32bit application.
You need
1) Make sure redistributable components are VFP9 SP2 + 3 Patches (the only supportable version according to microsoft)
2) Patch image (EXE) to be IMAGE_FILE_LARGE_ADDRESS_AWARE and get more than 64MB RAM or so (it is a long story to tell, but basically it depends on some old MFC libraries, and wow64 locks it into very old compatibility mode)
Just a few notes to above post:
1) The 3 hotfixes are declared as "Install at your own risk" by Microsoft but they are OK. More important is the fact FoxPro is not supported at all... (I don't count the last 2 months of the extended support period.)
2) FoxPro can use cca 1.5 GB of memory from 32 bit address space without patching.

W7/W2008 is slower than previous systems when you use shared file access. In addition to that you should apply some recommended settings:

1) Apply Alaska patch: http://www.alaska-software.com/fixes/smb2/overview.shtm#download
2) Switch SMB2 off on both server and workstations
3) Read something about opportunistic locking: http://fox.wikis.com/wc.dll?Wiki~OpportunisticLocking (and test oplocks disabling)
4) Move your app, its libraries, and temp files to local workstations. Server should host just shared data.
5) Disable IPv6 on your network - it slows the shared file access down

6) Think about your app redesign. Remote shared file access is deprecated in Microsoft.  App running in Remote desktop session is better solution because it can access data locally. VFP COM Server is also good solution but too much work...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
2. If it loads some control that uses visual C++ 6.0 runtime, odds are high it is landed in w95 bin and less memory (that is usually evidenced by compatibility assistant popping up when you close the program)


4) Instead of moving .exe to local drive, you can also try setting them read-only. That would make sure single lock is held per client (but then again imagine updating program ever)
SolarWinds® IP Control Bundle (IPCB)

Combines SolarWinds IP Address Manager and User Device Tracker to help detect IP conflicts, quickly identify affected systems, and help your team take near instantaneous action. Help improve visibility and enhance reliability with SolarWinds IP Control Bundle.

Yes, VFP 9 needs msvcr71.dll but it never displayed compatibility assistant on 64 bit machines to me.

If the app uses some (OCX) controls then these controls must be registered which itself is annoying complication on new computers.

Each VFP program should use a loader which checks for new updates as the first step and then starts the app itself. Of course, this is valid in the case of planned updates only. If you don't plan updates then the local drive ensures fast app start at least.
We got rid of it approx 2 years ago, I can just report how it worked back then ;)

At the end we walked around each OCX with dependency walker to make sure it has no unwanted dependency on w95/NT4. etc etc.
HealthcomAuthor Commented:
Thanks for your quick reply's and suggestions. We're going to be attemping some of these fixes next week and I'll be able to report back. Any other last minutes thoughts...please feel free to send over.
HealthcomAuthor Commented:
We were able to turn off SMB2 and added a regedit entry to disable opportunitic locking. This significantly reduced task time from 46-55 seconds down to 8-10 seconds on WIN7 machines. Thanks for your helpful suggestions!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Management

From novice to tech pro — start learning today.