>>>>How about a post-setup executable, would that work?
>>>
>>>I will have to use that route as I already have a post executable method, so I will have to call another exe from within the current post executable method to install the current dcom95.
>>
>>You will become the expert on this, if it works (or doesn't, I guess :)...it's blazing new trails, since I think most of us haven't got that far along in 6 yet...
>
>It is the fact that the microsoft dcom update requires that you reboot your machine that will cause me some fits, but another day another challenge.

With either an InstallShield or Wscript wrapper, or even with a post-setup executable other than a VFP app, this is handle-able. You need logic to determine if the DCOM install is to be run; if it is, have a continuation setup executable somewhere on the local machine (maybe copy it there?), write a RunOnce key that will invoke the continuation executable when Windows restarts, and then run the DCOM .EXE. If your script get control back after the DCOM install runs, either DCOM wasn't installed, or the user elected not to reboot after the DCOM install ran. In the first case, remove the RunOnce key and abort the install, since you know your VFP app will have a problem at this point. If the second, I'd figure I was smarter than my user in any case, and force a reboot, which will invoke the remaining script via the RunOnce.

The RunOnce key goes away after it, well, Runs Once.

Under NT, or on Win95/Win98 with User Profiles enabled, there may be issues if, after reboot, the user logs in with a userid having lesser privileges and/or different user profile details than the userid that started the install. IOW, you may have problems if the application installed under the local Administrator account, but after rebooting the system, the user then logs in as 'EvilChuckie' or 'JRandomEndUser', or even as Administrator under a domain rather than the local account. This especially applies if you're going to reference registry detail attached to HKEY_CURRENT_USER or need to have the same or greater access privileges to directories. And if you're referencing things installed to the Start Menu or Desktop, they may not be there when logged in as a different user.

I've done this with InstallShield 5.1 Professional several times; it's a bit involved, but works well except for some temp file cleanup issues when the user elects to reboot before the InstallShield script is able to clean up after itself. It should be equally doable with a Windows Scripting Host script, but I have not needed to do that yet in the apps I've developed with WSH-based installs.