MS redistributable files: the infamous DCOM and co.
Hi,
In my installer I need to redistribute some Microsoft installers, such as DCOM95.exe and another .exe that installs a recent version of the Common Controls, and probably some more. Now here's the catch. Microsoft insists on using these executables as the only means of redistributing the DLLs inside them. Fine. Running them with /q even ensures they are silent. However, they often need a reboot, and even when run with /q they may pop up a reboot request dialog right in the middle of your installer. Some years ago I found that by using the undocumented /u switch that is supported in most Microsoft installers, you could make these guys *really* silent. E.g., you execute DCOM95.exe /q /u, and it shuts up until it completes its work and lets your installer run through to completion. However, the plot thickens, because now it's up to you (or, in this case, me :-) to detect whether the executable *wanted* a reboot, so as to set the NSIS reboot flag manually.
If it wanted a reboot, it must have ordered some post-reboot action; an action which was not possible at install time because one or more files were locked. This is handled differently on the various Microsoft operating systems - basically a new operation is flagged in the Registry or in system .ini files (for older operating systems) with an activity that needs to take place right after a reboot. It seems feasible to detect this, but there may be an easier way to solve this altogether.
My question to this forum is as follows: has any of you had real-world experience of launching such MS redistribution executables from NSIS and has handled the reboot matter well? It seems to be a problem for many NSIS uses, so I'm certain I'm not the only one facing this. I would like to hear your thoughts, and of any of your approaches to solve this, and hope my discussion of the undocumented command line switch would be of help to some of you. Regards, GJ