On Thu, 19 Jul 2001, Daniel Walker wrote:
I was thinking of ways to get the CLSCTX_LOCAL_SERVER option working in wine. The only program that uses it , that I know of, is installshield v6 .. I pretty sure some other people are working on this, but I don't know that status. (Anyone care to update me?)
I'm working on it. In my tree, CoGetClassObject successfully launches ikernel.exe and establishes an IPC connection to it, and queries it for the CLSID that installshield wants. That works fine, but that's just the easy part. Currently the service process (ikernel.exe) can't yet send a reply, since interface marshalling is not quite implemented yet... and I'm not entirely sure how typelibs work yet, and how to retrieve the typelib info for a CLSID.
will CoRegisterClassObject on all needed objects .. One problem is that the registered class object list isn't shared between the two processes, so we would need to move that list into the wine server (Right?) ..
Not necessarily.
Since we have complete control over how IKernel.exe is run, how would we get the two processes to share memory? Maybe have IKernel.exe execute in a thread?
No. There's no reason to share memory either, we're supposed to do it like Windows does it and it doesn't share memory. It uses proxy objects, created by marshalling the interface across.
IKernel.exe doesn't do anything but register it's class objects .. Would it be possible to treat IKernel.exe as a DLL then run CoRegisterClassObject for it?
I don't know how you're going to get that to work, CoRegisterClassObject needs pointers to application structures, which only ikernel.exe's startup code knows. And you probably *still* won't be able to load it into the same address space as the installer, for reasons known to everyone that eagerly awaited the big Address Space Separation.