CoGetClassObject

[Ove Kaaven]

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.