Comment 138 for bug 357456

(In reply to Dmitry Timoshkov from comment #131)
> (In reply to Zebediah Figura from comment #130)
> > I've been looking at a proper solution for this.
> >
> > We already have the MSIServer service already implemented—it just doesn't do
> > anything yet. I think the best way to fix this is to register the
> > IWineMsiRemote* classes in the server process with REGCLS_MULTIPLEUSE, so
> > not much change in infrastructure at all. I see two ways of doing this:
> > either move all of the COM objects into msiexec.exe, or add an internal
> > function in msi.dll. I like the first one for the sake of separation, but it
> > does mean we need an internal idl.
> >
> > Any thoughts on this from anyone else?
>
> Did you try to investigate how that's done in Windows, so you wouldn't need
> to invent custom interfaces?

Windows appears to have its own set of internal interfaces, e.g. {000c101c-0000-0000-c000-000000000046} "Msi install server". We actually have an IDL for these in msi.dll, since evidently some program tries to create one. But these interfaces are all internal; we don't even know the vtbls. It would appear that this approach would be close enough to replicating that one.