https://bugs.winehq.org/show_bug.cgi?id=18070
--- Comment #132 from Zebediah Figura z.figura12@gmail.com --- (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.