Link to home
Start Free TrialLog in
Avatar of forwiw2day
forwiw2dayFlag for United States of America

asked on

Does FoxPro Version 9 Run on a Windows 7 Professional 64-bit Computer?

Experts,

I'm currently in the process of ordering a new computer, Windows 7 Professional 64-bit, and need to know if FoxPro Version 9 will run on the type of operating system?

I have successfully tested FoxPro Version 9 on a Windows 7 Professional 32-bit and FoxPro runs without an issue.

Don't know if the FoxPro Version 9 system will run on a 64-bit operating system?

Has anyone been successful with 64-bit?

PS.  Also, we currently just "use" the FoxPro Version 9 system, don't think we can make any changes as the developer is no longer accessible.

Forwiw2day
ASKER CERTIFIED SOLUTION
Avatar of Pavel Celba
Pavel Celba
Flag of Czechia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of forwiw2day

ASKER

pcelba:  Of course, OCX controls must be registered and possible DSN to access SQL Server must be defined as 32 bit (ODBCAD32.EXE in WIndows\SYSWoW64\ folder).

How do I go about checking the above Control Registered?

And where will I look for the ODBCAD32.exe?  IE on the C Drive of the computer and/or on our File Server where FoxPro resides?

Thanks
Simply install and execute the application and you'll see. Correctly written installation software should register all controls required. If some control is missing on your new machine then you have to investigate which one it is (hard for non-programmer sometimes). Application documentation should describe all necessary dependencies.

VFP 9 itself or simple app does not require any OCX controls to be installed. (VFP 9 requires just MS XML to be installed on the PC. The installation process should tell it.)

The ODBCAD32.EXE was mentioned as possible option and it is necessary when your app requires DSN to connect to the SQL Server or other data engine. Some VFP applications use connection string so they don't need DSN other VFP apps do not need SQL Server at all and they access DBF data on shared server folder.

So if DSN is necessary then you have to create it on the computer where the app is running. Even when the app is stored at the server but you are executing it from local PC then you should create the DSN on the local PC. If you are running the app in Terminal Server (or Remote Desktop) environment the you don't need to install any additional software except the TS/RD setup.

First of all you have to know what are the app installation requirements and prerequisites.
Avatar of jrbbldr
jrbbldr

I too have run VFP applications (VFP7 & VFP9) in Win7 64-bit workstations with no problems.

However, as Pavel has already said, the initial set up of the workstation's directories and directory user rights may need to be looked at carefully.

ODBCAD32.EXE is in the directory: C:\WIndows\SYSWoW64

IF you have ODBC DSN's defined for use within your VFP application, you will need to set them up using that specific 32-bit EXE (ODBCAD32.EXE) and NOT the 'standard' 64-bit version found in the Control Panel - Administrative Tools (Data Sources)

Good Luck
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
pcelba:  Simply install and execute the application and you'll see.  What application?

So if DSN is necessary then you have to create it on the computer where the app is running.  Don't know about DSN?

Even when the app is stored at the server but you are executing it from local PC then you should create the DSN on the local PC.  Yes, VFP is stored on the server and we are executing it from our local network computer.

I went to the MS link and in the community discussions it states that it will VFP 9 will run on Windows 7 64-bit.  

Your VFP 9 application does not require any special libraries. Not sure.

Went to the fox link... Should I check all the listed DLL Names Listed?  If so, where, on our server, local pc, or both?

Thanks for your input!
jrbbldr:  I too have run VFP applications (VFP7 & VFP9) in Win7 64-bit workstations with no problems.  Thanks, this is good to know, it's just those other issues you talk about, that I'm not sure of.

IF you have ODBC DSN's defined for use within your VFP application, you will need to set them up using that specific 32-bit EXE (ODBCAD32.EXE) and NOT the 'standard' 64-bit version found in the Control Panel - Administrative Tools (Data Sources)  Please explain, I know nothing about VFP 9.  

Oh, I forgot to mention that I generally turn OFF UAC on those workstations so as to minimize the directory rights issues.  Where, How?

Thanks for your input!
We should clarify what you are planning to use/install.

What means "FoxPro Version 9 system" in your question?

Do you have Visual FoxPro 9 Professional edition?  Or do you have  an application (system) written in Visual FoxPro 9 language?

Visual FoxPro 9 is a programming language and much more. In other words it is IDE - Integrated Development Environment. It has no meaning for you if you are not a VFP developer.

Visial FoxPro 9 system can by almost anything, the most fitting term is the application written in VFP 9 language and compiled to EXE.

Visual FoxPro 9 IDE is licensed per developer and the developer can install it on as many local PCs as he needs. The server installation is not allowed.

Application written in Visual FoxPro 9 IDE and compiled to EXE can be installed anywhere on unlimited number of computers having Windows operating system. It just needs Run-time libraries (listed in the link provided) on the computer where it is running. The computer where it is stored (your server folder) is just the storage where it does not run. But FoxPro looks for missing libraries in the folder where it is stored obviously. OCX must be registered on the computer where it is running.

If you need DNSes or OCX registrations depends purely on the application. VFP 9 IDE does not need them.
 
The simplest thing you can do is to copy following three files from the VFP 9 folder to a flash disk:
VFP9.EXE
VFP9ENU.DLL
MSVCR71.DLL

Connect the disk to some computer having Windows OS installed and try to execute the VFP9.EXE. You'll see the compatibility result immediatelly. (Of course, full VFP9 functionality would need more files.)
As Pavel has explained, DSN's are not needed by VFP9, but many Applications are developed (in a variety of languages) to utilize DSN's to access data from sources other than 'native' VFP data tables.  

So it would be the Application itself and how it was developed which would determine if you would need DSN's that had been previously defined on other workstations.  Since you cannot 'look' into the code, you will have to go by what you find 'externally' (see below).

Don't know about DSN?

Within one of your older, working workstations go to the Control Panel (if not Win7) and then into the Administrative Tools - Data Sources.  
There are a number of 'DSN' tabs there.
Go through them and see if you find any that are unique (Not 'generic' Excel, MS Access, etc.).
If you find any of them, you will want to go into their Configure and make note of all of the parameter settings - those will need to be duplicated on the Win7 system within the ODBCAD32.EXE.

Turn OFF UAC - Where, How?

Within Win7 go to the Control Panel - System and Security - Within the Action Center is Change User Account Control settings - move the slider to the bottom and click OK

NOTE - depending on the 'flavor' of Win7 (Professional, Enterprise, Ultimate, etc) you have the controls may be somewhat different.

Good Luck
Before you address all the single questions, simply install VFP9 or your VFP app and see if it works, then address problems. It's good to know eventualities in advance, but you don't need to deep dive into OCXes, DSNs, MSXML unless you get problems.

From your previous thread you don't need VFP9 itself, but only install your application developed in VFP9, don't you? Why are you asking  What application? You want to install a VFP software product, application is just another general name for a software. If your software doesn't come/came with a setup, as it was developed by a retired developer, you may only have some EXE, even that can be called software/application. What you need on top of that is merely the VFP runtimes. You can get an installer for these runtimes here: http://www.foxpert.com/runtime.htm
For VFP9 I suggest you take the latest one: VFP 9 Service Pack 2 Runtime.

The runtime always has to be installed on the PC the EXE runs on. And if you put an EXE on a network share on a file server, that merely let's everyone see and access the file, but the file doesn'T run on the server just because the EXE file is located there. It's a good practice to have an EXE there to have a central place to update it to the latest version, but use a command file to copy the EXE To a local folder. It's best practice to have a setup and install it on each client, which can then take care of installing all other runtimes, OCXes, DSNs etc. needed for the application to run, but that's a tedious work in a larger company, unless you have an it department knowing about software distribution and assignment in a corporate network with appropriate management systems.

Anyway, just install it, as it has been done on other PC clients, the Win7 OS won't hinder you.

Bye, Olaf.
Experts,

Do you have Visual FoxPro 9 Professional edition?  Or do you have  an application (system) written in Visual FoxPro 9 language?  After reading the posts, I found a folder on our server called VFP9.  Inside there is an application file called VFP9.exe and after I started this, it displayed a window Visual FoxPro 9.0 Professional SP1.  

Our network users have a default network mapped drive to the retired developers exe file that was created, all we do is double click this file to use the customized system that was developed.  So to answer your question, we may have both?


Within one of your older, working workstations go to the Control Panel (if not Win7) and then into the Administrative Tools - Data Sources.    Followed your instructions and there are three tabs that include the DSN name.  The only tab that had any information in it was the User DSN tab, it included dBASE Files, Excel Files, MS Access Database.  The other two tabs were blank.

After I receive the new computers with Windows 7 64-bit, (This may be a month down the road), I will test the users default network mapped drive, and hope that I don't get any error messages.  If I do, I'll post the error message here in Experts Exchange.

The conclusion is VFP9 does run on a Windows 7 64-bit computer.  I just need to be aware of the Compatability Status, Special Libraries, OCX Controls, DSN, and the most common problem is UAC.  I'll use this post for the information if needed.  If anything else comes up, I'll post a new question.

Thanks to ALL Experts!
You are welcome!
It's not a surprise you find both a Foxpro installation and the application we already talked about, as you said you had a developer writing that application EXE, and of course he had VFP for that matter. But the final exe does not need a VFP installation, merely a VFP Runtime, eg it won't need the VFP9.exe, but the vfp9r.dll to work, and some other DLLs it's already an EXE on it's own. You also don'T need to know which DLLs and other stuff is needed, as all that is installed with the runtime installers I pointed you to.

It's unusual to have Foxpro installed on a network share, though. The license allows multiple installations for a single developer, but not for everybody in a company.

Anyway, you should already know from the other thread, your users mainly need network access to the application EXE. I can understand you don't know any specifics of what the EXE needs besides itself, for one that are the runtimes, and it can't hurt to install them on each client. All the other stuff is only needed when needed, and you'll get to know this.

As you added the one user now (or are you still not finished?) that's the same steps needed on a Win7 client. Everything else is very speculative. Your current clients might have been prepared to run the application with preinstalled runtime, activex controls, some DSN and more, but you'll see what's missing, when running on a new "box". It'll be fixable, as you will find all needed things on other clients, but it'd be too much to tell you things you only may eventually need to know.

I only want to address one misconception about UAC: The TLA (three letter acronym) stand for User Access Control and while you now may get the idea "ah, that was/is in my way", no that in general is controlling access to limit spreading of viruses and other harmful software, it's not to control users, but what user accounts can do (so it's more about restriction of the technical user accounts and only indirectly of the users themselves in person. You better not turn it off. If you had the impression the developer was not doing good work you might expect problems in accessing locations that shouldn't be accessed, eg putting data into the C:\Program Files\Yourapp\Yourapp.exe folder, as Program Files is limited to execute what's inside, but Readonly. This is most probably NOT a problem in your situation as your EXE is located somewhere on a network share and not on each single client. This location has other problems with concurrent access to the EXE file itself, but not with UAC.

Bye, Olaf.

Edit: As you said when starting VFP9.exe you see it is VFP9, SP1, then I suggest you also install the SP1 Runtime installer, the second download, if at all.

As the application EXE is running I assume you find a vfp9r.dll and maybe other files mentioned in the wiki link Pavel gave you, put side by side to the application EXE, then it's use by the EXE too, as the EXE and at each client, also new ones. That's one of the advantages of putting an application on a network share instead of the usual local installation on each PC. To limit the concurrent usage of the runtime DLLs, one of our customers has applied the runtime installation on any company PC and removed runtime files from any network location and that may already perform much better as the DLLs then are a) local and b) only in use by one user. It's a rather simple thing to do without breaking anything.