GlobalInterfaceTable?

[Mike Hearn]

> Yes, it might be a bit scary. The GIT is a pretty much a band-aid
> solution for shortcomings in the other marshalling modes.

Oh yipee

> No, we haven't implemented this interface, though once the apartment
> stuff is in, I can see two approaches to implementing this interface.
> Note that the GIT object is a process-wide singleton (any instantiation
> requests should return the same object every time).
> 
> - the GIT object could live in a particular apartment (e.g.
> ThreadingModel=Free, so it lives in the MTA). Every instantiation
> request would then marshal the interface to the requestor's thread. Then
> the marshalling code for the GIT interface will also automatically take
> care of the marshalling of the interface pointers to be registered and
> retrieved. (This might need Wine's CoCreateInstance/CoGetClassObject to
> check the threadingmodels, and I haven't implemented that myself.)

Is this object performance sensitive? If so then the less marshalling
needed the better right? But this way would make the implementation of
the GIT itself simpler.

> - the GIT object could be apartment-independent (use the Free-Threaded
> Marshaler). Then RegisterInterface would manually use CoMarshalInterface
> to table-marshal the interface, and GetInterface would manually
> unmarshal it.

That was the approach I was considering, but how would GetInterface
unmarshal it in the correct apartment/context (are they just different
names?). Or is that implicit in the context it was called from?

> This won't make a difference before apartments are properly implemented
> in Wine, though. 

Ah, ok. For now then I'll probably just do what Marcus suggested and
stub it out, or maybe implement the table but ignore the actual
threading stuff.

> The code I have now still does not work exactly like it
> should (I implement IRemUnknown improperly, I still use midl instead of
> widl to generate the marshalling code), it still crashes a lot, and I'm
> too busy to clean it up for submission to Wine just yet (but in case
> that worries people into thinking that it won't get into wine, people
> hereby have my permission to lift my OLE stuff from winex if they want,
> I just won't submit it all myself before working on it some more).

Do you know when you might be able to get around to doing it? I guess
for now if the stubs aren't good enough I can just use native OLE32, but
I'd like to get the app working with no native overrides if possible :)

thanks -mike

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center