FoxPro loads very very slow on Windows 7

[SteadySystems]

FoxPro loads very very slow on Windows 7
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.

I've created a test environment (Windows 7 Pro) and copied the live environment (windows 2000 Server) Data folder over. Here is their setup...

Live Working Environment: 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.

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:

1. right click "Run as administrator"
2. Compatibility mode

AntiVirus prorgram uninstalled and not the culprit.

To test, I took an old XP Workstation (newly formatted) and connected to the live environment (Windows 2000 Server), joined the Workgroup, mapped the drive, launched lucky.exe and it loads fast and works great.

I then removed the mapping, change the workgroup to point to new Windows 7 Workstation, remapped the drives, launched lucky.exe and its brutally slow. I checked resource monitor on the Windows 7 Workstation and it does not spike.

This is a complete mystery. Someone had mentioned something about the files I copied from Windows 2000 Server (Live environment) to the Windows 7 Workstation (test environment) having Encrypted Files enabled since it was on Windows 2000 Server first?

Here is a quick video also:

http://screencast-o-matic.com/watch/c26Dqwejy3

Thanks!

 

[Olaf Doschke]

Well, a Workstation is no file server, it's not specialised as that. Nevertheless it shouldn't be so bad.

As you said in the screen cast, the folder containing the EXE also contains 200.000 data files, this may play a role. Separating the data from the EXE would better be done, also the data minus one exe and perhaps some other files still would be about 200.000 files in one directory, that's always bad for performance, not only for showing the files in Windows explorer. Data files should be put into a folder structure partitioning the data in smaller chunks.

What we know is causing network problems is SMB2 protocol changes, but since XP and Win7 won't talk SMB2 to each other, that's not it.

It might play a role the Win2000 server still is the domain controller and therefore plays a role in authentication andd file permission checks.

Are the computers networked via Wifi? That's often causing trouble. And indeed overall it looks more like a network problem than anything else. Resource monitor will not be very verbose on what happens. You could use Wireshark to see what happens in the LAN and Process Monitor to look at the EXE and some DBF files.

Bye, Olaf.

 

[SteadySystems]

1. Windows 7 Pro can handle up to 20 connections. We only have 7 employees accessing lucky.exe at peak times.

2. Since this custom system is so old I would not dare touch moving files around. This is everything for them, it runs the company.

3. How to we check if Windows 2000 server is playing a role still? I copied the data folder to the new workstation so they are independent.

4. They are networked through a RJ45 panel / hub / router. Both the Windows 2000 server and Windows 7 Workstation is plugged into the Hub so they can see each other.

Getting back to the 200,000 files in the LU_ folder; Even when I am directly on the server, C: drive, Data\Lucky\Lu_ it stills hourglasses for a long time before it shows the files. The difference is that our live environment is completely functional, whereas trying to use the Windows 7 Workstation in this manner is not working properly. The true test was when I formatted the old WinXP PC and was able to connect it to the Windows 2000 Server without any problems.

Do you want to connect in and take a look? I have teamviewer setup on both.

 

[GriffMG]

I have seen something like this before, and it wasn't to do with the files, or really the server - the application
was trying to set up a default printer that no longer existed. All I had to do was either set up a matching print queue
or change the default printer to one that actually existed.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

>Even when I am directly on the server, C: drive, Data\Lucky\Lu_ it stills hourglasses for a long time before it shows the files.
Yes, I know that, because I also had a directory with many files locally. Windows Explorer is not good at handling large amounts, several things are triggered for all files in a directory listed, meta data is retrieved. from each file, etc. These things are quite specific to Windows Explorer, though. FOPEN or Shellexecute or other direct file access is not looking at how many other files are in a directory.

The main problem you have is with the load to to the XP clients and that is LAN, mainly LAN.

I would try how the start improves with a local installation of VFP runtimes and copying the EXE local, too, before starting. The question is, if it's configurable to look into another folder as the one it's in itself.

What works good in your situation is starting on the Win7 machine. If you say 7 users are using this system, then they could do so via remote desktop and that might already help enough. It may be your only option, if you don't have sources and can't change the behaviour of the exe and its configurability even with just a small change of the startup code.

Bye, Olaf.

 

[SteadySystems]

GriffMG: but the freshly formatted WindowsXP PC client does not have a default printer installed and it worked perfectly on live environment. When connecting to the test environment it takes forever to load.

Olaf: in the video you can see it loads immediately locally. So the issue is when clients connect to the test environment.

But the network setup is identical on both situations. The only single factor is the test environment workstation (win7).

To that point I should be able to remove the live environment (windows 2000 server), copy the data folder to new workstation and have clients connect and use right? Tried this week's ago and the slow problem was discovered. That's how I learned about the slow problem so I put everything back.

We are close. ..

 

[Olaf Doschke]

Well, when client start the EXE they load via LAN, so that is the difference to starting locally on the Win7 machine. The LAN is the same, yes, but the Win7 station does not run via the LAN.

Bye, Olaf.

 

[Olaf Doschke]

A measurable question: How large is the exe, and what does it load at startup? Can you even say if it's loading more than itself? A typical database application establishes a connection, but does only begin reading at first requests. Some application may load much data to a local drive to be faster after that initial load.

Bye, Olaf.

 

[SteadySystems]

Olaf, here is the diagram of our setup. You can see it's identical setup, both coexist. Difference being that we have different workgroups VINTAGEINCUSA (Windows 2000 Server) vs VINTAGE (Windows 7 Pro) PC Clients can connect to Windows 2000 Server and run the lucky.exe shortcut with no problems, been working for over 10 years.

PC Clients can connect to the Windows 7 Pro workstation but loading the lucky.exe is very very slow.

So I've literally done this:

1. copy entire /Data/Lucky folder from Windows 2000 server
2. paste it to /Data/Lucky folder on Windows 7 Pro workstation
3. Unplug Windows 2000 server from Patch Panel
4. Change PC Clients to VINTAGE workgroup (Windows 7 Pro workstation)
5. Map a network drive letter to /Data/Lucky folder
6. From the LU_ in /Data/Lucky folder I copy lucky.exe shortcut to their desktop

Attempt to run and we are not faced with the slow loading problem.

The Lucky.exe is 4.62Mb

 

[SteadySystems]

oppps type, Attempt to run and we are NOW faced with the slow loading problem.

 

[SteadySystems]

A typical database application establishes a connection, but does only begin reading at first requests. Some application may load much data to a local drive to be faster after that initial load." - Only thing I know is they install something locally to the client first. After the setup.exe a c:\LU_ folder is created. But they never run anything from that folder.

 

[Olaf Doschke]

I was thinking you were talking about the difference of starting the EXE on the Win7 client itself vs starting it from the XP clients connected to the Win7 client.
You're talking about the diff of Win200 vs Win7 as server, both used from XP clients. The network then is not the same, it differs at least in the last cable to either win2k or win7. It may simpoly be the cable connecting the win7 client being bad.

The servers (more precise the server and the win7 client acting as server) also differ in the roles win2k is a server and the domain controller, win7 is just a client. Client to client networking accompanied by communications with the domain controller (which is what always happens as far as I know - be it only for permissions) is a difference.

>After the setup.exe a c:\LU_ folder is created. But they never run anything from that folder.
In the screen cast you say the shortcut starting the application points to an exe in the server side LU_ folder. That doesn't contradict what you say, but this makes even less clear what really is installed where and who starts what.

So let me tell you my understanding of things:
You have a central setup of EXE and data in one main folder on both win2k server (operative) and win7 client (test). XP clients merely have a mapped drive and shortcut to the central exe. They get it from there in each start. This works fine on win2k, not so on win7. Now how does a local installation at each xp client play a role? Is it merely to have the VFP runtimes on each client? There has to be the exe and a vfpNr.dll (N being the main VFP version 3,5,6,7,8,9) besides some more DLLs for a foxpro application to work. I think you talked about a VFP5 app.

Wireshark is still my recommendation to measure the LAN and REmote DEsktop connections of XP clients to the Win7 client instead of starting the EXE on them would surely be a solution, as the EXE runs fine alone on the Win7 test server, what the screen cast showed. This is what you can work with right away, you only need to allow remote desktop usage on the win7 clients and put users into the remote desktop user groupd to be able to connect that way.

Bye, Olaf.

 

[EzLogic]

Virus scan could be a culprit too.

Can you exclude your EXE and your app folder from the scan?

Ez Logic
Michigan

 

[SteadySystems]

Virus scan could be a culprit too.

Can you exclude your EXE and your app folder from the scan?"

We already uninstalled Anti Virus.

 

[SteadySystems]

Olaf, would you have time to TeamView in?

 

[SteadySystems]

Olaf, you are 100% correct in understanding the setup. Wireshark is going to be over my head.

I just dont get why the WIN7 clients do not work.

 

[Olaf Doschke]

Don't say Wireshark goes over your head before even first using it.

You download, install, start and then record simply all network packets of all protocols.
You do that once short before starting the application on a client mapped to win2k until it has started and shows the login.
You do that once short before starting the application on a client mapped to win7 until it has started and shows the login.

You would expect the protocols to be the same, but as the starting time differs so much you'd most likely see some diffs.

If I would know before hand what you'll find, I could tell you what to look for.

And no, I don't have the time to spend an afternoon or several to do that for you.

Also you haven't answered the question yet, whether you have source code or not. If you have, starting the app within VFP and debugging what happens would even be a more ideal way of finding out what takes longer.

Bye, Olaf.

 

[SteadySystems]

I don't know if we have the source code, it's incredibly old and I am not a programmer.

I feel like we are really struggling here to find a solution why it won't work on from a Windows 7 Workstation.

 

[Olaf Doschke]

>I don't know if we have the source code
It's a yes/no question.

I am not asking, if you would understand it or not, if you are able to load it or not, if you can debug it or not.
Just, whether you have it or not.

If you don't have it that means you can only work from outside, change environment, configure. If you find something, that's only possible to fix with a code change, it would be bad to not have the source code.
If this application really is that mission critical it's very critical you can't even say you have the source code or not.

Bye, Olaf.

 

[SteadySystems]

Nobody in the office knows anything about it, the guy who created it disappeared. They've just been using it ever since.

So you know if it could be related to Windows 2000 server encrypted files? The data folder was copied from Windows 2000 Server to the Windows 7 Workstation. Perhaps it brought something related to EFS over?