On 22 Jan 2003, Mike Hearn wrote:
Why not just use threads? Is there a particular advantage to using IPC in this instance? I'd guess that ikernel.exe is the program that does the installing, and the program you launch does the front end code?
It does use threads, and a lot of other things. But I think the idea of using advanced COM stuff makes sense from the InstallShield point of view - all that COM/DCOM/RPC stuff is already on every Windows installation, so the installer executable does become smaller by using it instead of writing their own mechanisms to achieve the same thing.
The program you launch simply does the "Preparing InstallShield Wizard" thing, this is where interprocess COM call takes place. Once you get past that and start the actual installer, the main engine (ikernel) only uses threads (though unfortunately, interthread COM calls aren't quite implemented yet, so repainting suffers). However, that engine does export OLE Automation-compatible COM interfaces, probably so that app-specific installation routines can be written in any language, including Visual Basic, Java, C++, etc (not just iscript), and still be able to easily call the ikernel API. This sometimes calls for IPC, but again, this is all handled by the stuff that's already there in every Windows installation, so there's no reason for InstallShield to bloat itself with its own reimplementation of these mechanisms - other than "it causes headaches for those Wine guys", but that probably wouldn't be their primary concern...