Re-installing VFP9

[AndrewMozley]

I have to re-install VFP9 on a Windows 10 machine. I have the VFP9 CD and the product key. It is a little while since I last did this, so may I check that I am doing it right.

My understanding is that I need to install it from the CD and then download Service Pack 2 from the Microsoft website. Grateful for any guidance if there are any other things I need to do.

Thanks. Andrew Mozley

 

[Dan Olsson]

Wouldn't you also need to copy C:\Program Files (x86)\Common Files\microsoft shared\VFP? I think I did that when I started a new machine recently.

Since I never installed VFP in C:\Program Files, the answer (for me) is no.
The runtime files is also installed in HOME() so when I make a setup I make a distribution directory and copy my EXE and runtime files (including MSVC?71.DLL) before I build the installation.
I've done this with different computers for some 15 years now. Always worked

 

[Mike Lewis]

Since I never installed VFP in C:\Program Files, the answer is no.

I don't either, Dan. I was simply making the point that, as well as copying the VFP directory and doing the regserver thing, you would also need to copy the resource files. Whether or not they end up in Program Files\Common Files is not the point.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[tomk3]

Hello,

just some days ago I had to do the same.
I juste reinstalled by copying my folder d:\develop which contains th installation folders \vfp9, \vfp8

There is a very good article :

http://woody-prolib.blogspot.com/

HTH
Regards
tom

 

[Olaf Doschke]

The runtime files is also installed in HOME()

No, not by default. When you have them there, you or someone put them there at some time. The VFP installer puts runtime in the Microsoft Shared folder, no matter what home installation path you choose. And the merge module also is separate.

While you work in VFP IDE, vfp9.exe is your "runtime" and there are some resource DLLs like the vfp9enu.dll instead of the ditributed resource file vfp9renu.dll, look at the detail. Overall the only DLLs the installer puts into home are VFP9CHT.DLL, VFP9ENU.DLL, VFP9KOR.DLL, VFP9CHS.DLL, in previous VFP versions you also had more languages supported in the IDE, French and German, for example, they are now only available as runtime resource DLLs.

A subfolder "Visual FoxPro 9.0 Professional - English" within HOME() also has msvcp70.dll, msvcr70.dll, but the setup will also add those into Sysdtem32 or Syswow64. This folder is a remniscence of the installation process, IIRC.

You don't need to move Microsoft Shared or Merge Modules of VFP and C++ runtime and some redistributable OLE controls for the IDE to work, but you then will need to grab the DLLs and other stuff from elsewhere. Therefore Mike is still right if you don't just care for the IDE to work.

Or as I said, no matter which way you choose to get to the same situation you have to know your VFP also in that aspects of where which files are, and what other components it depends on that may have been there by default in XP but are not anymore. That's also why your experience of just moving the folder from saying NT to XP was a full experience, while you need to care about the surrounding elements, too, now, as MSXML3 and 4 also are legacy, Soap Toolkit is legacy (it still works, but is not supported by MS, if you cared you also wouldn't use VFP).

In my eyes, the reinstallation is the simpler thing to do, the argument for moving a home folder is when you have multiple VFP versions. And you still can fail not knowing or remembering back in the time VFP9 was new CD autostart still wasn't disabled by default, so when you pick the setup.exe you skip the prerequisite installation and go straight for VFP9 installation.

So all in all you need to know your stuff, both about VFP and Windows, like that you find what autostart would have started in an autostart.inf. VFP isn't a game, it asks you to be a developer, a knowledgeable person about more than just the VFP language.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name