Foxpro Libraries Help!

[DBDivaAuto]

I accidentally uninstalled 2 Foxpro runtime libraries off a machine. 8.0 and 9.0sp2. I was able to get 8.0 installed but the software that needs to run it isn't seeing the library and the Control Panel doesn't show it. 9.0SP2 is not installing saying that it cannot find the file to upgrade and there is no 9.0 regular download.

How can I get these libraries back?

 

[Olaf Doschke]

1. Where in the world would the control panel show a runtime? There is the odbc manager showing ODBC drivers, but I don't know any component of the control panel for managing any runtimes.
2. SP2 is a VFP service pack and not a runtime installer. Yes, it will look for a valid VFP installation.
3. Yes, there is no regular VFP9 download without a subscription, it is not a free product.

Do you have backups? This would be the first place to look, wouldn't it?
Do you have setups of the applications? You could use them to repair the missing runtimes.
Are you just a customer of VFP applications or also a developer? The runtimes are installed with any full installation of Foxpro within system32/syswow64 respectively and within /Microsoft Shared/VFP.

Well, and one last resort for getting runtimes is downloading the versions you need here:

http://www.foxpert.com/download/runtime.html

Bye, Olaf.

 

[Tore Bleken]

http://www.foxpert.com/download/runtime.html

http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles

 

[DBDivaAuto]

OLAF!!!! It is funny because when I was writing this yesterday I said "Olaf will know!" It's been a while because I took a new job in Sunny Las Vegas (boiling this week).

So - I thought it was interesting when I was helping the HR Dir. on her machine with unwanted pop-ups that FoxPro libraries were listed in her Programs in the Control Panel. I had never seen that and worked with FoxPro the previous 8.5 years. And they said "Runtime Libraries". So I had asked her if she ran anything that was written in FoxPro. She said no so I deleted.

Well - she did! Thankfully though after hours of searching MSDN and getting thoroughly ticked off (the library between 8 and 9SP2 is not an available resource from MSDN) - I started trolling the network. I found the libraries - there were 4 of them, loaded them in order of production year and Viola!

Thank you!

 

[Olaf Doschke]

If you refer to the download links, notice these runtime installers once were made by ProLib, they are not coming from MS, but are simply making a setup, which makes the runtimes available to any VFP app already half installed. So thank ProLib, neither MS nor me. The general idea was to deploy the runtimes once (also possible silent, but needing admin elevation) and then be able to deploy any number of EXEs even for normal users.

There's a little catch, which might not get you in your situation, but it's recommended to not install runtimes in a general location for all apps but to provide them in the single application folders. Since there are vfp9r.dll in six variants no SP0, SP1, SP2, SP2 with Hotfix1, SP2 with Hotfix2, and SP2 with Hotfix3, this can be important. They all have the same file name, but some features may have differing entry points. I personally made contact with C5 errors when using [tt]SET SQLBUFFERING[/tt] and [tt]WITH (BUFFERING = .T.)[/tt] in an EXE compiled with a different SP level than the runtime used. So it's perfidious, you don't get an error right at startup, any vfp9r.dll is fine for an EXE looking for this file and surely its initialization would fail, if it was any other file just renamed to vfp9r.dll, but the subtle differences show up in usage, also not always reproducible.

If you have VFP9 without SP apps and VFP9 SP2 apps, you better let each app have its own and very specific runtime DLL in its folder. Even if all apps are needing the exact same runtime, this does not harm and two apps sessions won't get in each other way by blocking calls into the same DLL you put in SysWow64.

One way to account for all this is only using the runtime installers to get the DLLs installed and then take them, where they need to be. The runtime installer setup could be done on a totally different computer, to avoid getting the DLLs registered on the application clients. The only runtimes needing a registration are the foxhhelp9.exe and foxhhelpps9.dll, as they are not only important for your EXE but also for the OS side of integrating into the Windows CHM help system. But the core C++ and VFP runtime DLLs and language resource DLLs are always found in the app folder and are better found there than in the registry, so it's better to avoid their registration, as that enforces every VFP app to use them in their registered location.

As said you may not be caught by the problems of this, if all companies applications are compiled with the same SP level, it also is okay to have a runtime setup to have a single installation for all apps, albeit I still see a slight performance advantage, if every VFP EXE uses its own runtime DLL copy.

Bye, Olaf.

 

[Olaf Doschke]

So I had asked her if she ran anything that was written in FoxPro. She said no so I deleted.

I think you had one more lesson learned from this: Don't ask such questions to a Director, Manager, or such. They never know this, they can't, but they won't show the weakness of not knowing something - anything.

I had contract work for a bigger company, which has made their own Foxpro Library installer, and that also shows up in the Programs and Features, yes. And its last usage will normally show the date of installation, as there is no menu item or tile about this "software". That's not the way the runtimes install together with a VFP software being its own MSI or setup.exe

Libraries could also be installed completely without a setup using a batch file elevated, but for a bigger company that's still not the comfortable way of assigning software packages to clients.

A thorough approach from your side to find out, whether VFP libraries are necessary would scan all drives for executables (including DLLs and FLLs) and analyze their dependencies with depends.exe, for example, or simply detect the string "VisualFoxProRuntime.9" (or .8) within an executable.

Bye, Olaf.