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.
