OK, let's simply make this as clear as mud:
The hotfix is updating (fixing) your VFP installation, so you only install it on your dev pc. This is an IDE update, not a runtime installer.
The hotfix ALSO updates the runtime DLLs in Microsoft Shared/VFP folder (within Program Files x86) on your dev pc, but again: It is no runtime installer, it has the IDE as the prerequisite to run at all, so you can't install it on clients anyway. It enables you to compile code in and for that version. But that upgrade of the dev pc runtimes allows you to get what you need on clients, too.
Because on clients, these updated runtime DLLs and reportoutput.app have to be installed plus your rebuilt EXE.
That's all you need to know. In summary, you install the hotfix on your dev pc, rebuild your EXE and provide it to clients with the upgraded vfp9r.dll, reportoutput.app and anything else necessary.
In more detail:
The runtime installers of which you have one, are only there to simplify the distribution process for devs not able or not wanting to create a setup, which of course needs elevation once to run, that's then reduced to once (for the runtime installer itself) for all EXEs you put on that client from then onwards. But a) when you do your own setups with InstallShield or Inno you don't need any RT installer as that setup can installs RTs, too, also registered for all or just into your application folder and b) you also don't need the RT installer when you make the simplest distribution with your EXE plus the 2-3 DLLs side by side, they don't need registering, so you can install VFP code without admin permissions at all, only not in Program Files, as putting files there already needs elevated permissions.that means you can mix 9SP0,1,2 with or without hotfixes as necessary for each indiidual EXE.
The runtime installers used at clients do install the same SP/hotfix level in a place found by any EXE or COM DLL not having their own runtime side by side to it and thus you will for sake of a clean setup need to upgrade all executables when going the route of the runtime installers. You can individually make some EXEs use other runtime DLLs by putting them side by side, I think (not 100% sure) those are taken with the highest priority before searching registry for the runtime location.
Anyway, you CAN, if you find it, use the similar runtime installer for SP2 Hotfix3 and install it on clients, you just need to be aware those are then used for any VFP9 executable and may cause C5, when an EXE is compiled in SP0, SP1 or even SP2 but without the hotfix 3, so I'd not upgrade clients this way. The runtime installers are good for servers you only get permission to set up once with an on-site admin and you only want to use one executable an be able to upgrade that later without admin permission, though you can also go the simplest route of putting DLLs side by side to your EXE. The runtime installers are not good in my opinion for generally enabling a client to run any VFP executables as they don't allow the mixed mode within each major VFP version. Of course the situation is simpler in case you have several executables in different major VFP versions, a VFP6.exe will not look for a VFP9 runtime, although that could execute most any VFP6 (or 4,5,7,8) bytecode, the major version numbers are in the runtime DLL files, but not so SP and Hotfix levels, that's the pure reason behind all that.
You have to know VFP doesn't compile into assembler, it compiles to a bytecode that then is read and interpreted by runtimes. There are mostly constant bytecodes for same commands throughout all VFP versions, which is why a VFP6 compiled executable also can run with a VFP9 runtime DLL, as long as all bytecodes have stayed downward compatible. It won't do so in an EXE, but when you call into a class or procedure of a VFP6 APP file, you can run that with VFP9R.DLL, too. There are changes in parameterization along VFP versions, that limit that kind of downward compatibility. Don't mind, if you don't get what bytecode is, it boils down to the best practice not making use of these quirks and just using exact same RT version as used for compilation ideally, even though some things also work with older EXE code using newer runtimes. The main fixes of behavior surely are in the runtime DLL, as it has the real executable code. The EXE you compile just tells the runtime DLL which of his internal function and command implementations to execute. The only part really executable from your built EXE is a part of compiled C++ loading the VFP runtime and starting up the program execution, pointing the VFP program counter to the start of main. That together means an updated runtime executes fixed versions of functions and commands and report apps, but if anything changes in bytecode even just the parameterization order, the fixed runtime code only runs, when finding that newer bytecode version, too. That's how I at least explain the C5 cases I had with mismatches, something then was so weird even causing fatal errors, just like a not found entry point/address.
The only situations you really need a setup making this an official Windows installed software seen on features and programs for uninstallation, too, is when you want that to be listed there and when you have more advanced steps to do like registering an ActiveX control or OLE server or adding some registry data or many other things needing elevated admin permissions, which normal users won't have after the setup just starting your EXE. So the simplest setup with EXE+DLLs in one folder is really efficiently getting you the desired runtime usage. The only downside of that procedure is when using CHM and HELP commands of VFP, as they need a registered foxhhelp EXE and any OLE/COM stuff you then can't use or need to prepare with a separate setup.
Bye, Olaf.
