Ove Kaaven ovek at
Tue Mar 4 07:20:21 CST 2003

tir, 2003-03-04 kl. 10:13 skrev Mike Hearn:
> > - 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.

I don't know how performance-sensitive it is. But I suppose that would
be a reasonable concern.

> > - 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?

Yes, CoMarshalInterface and CoUnmarshalInterface would by themselves
figure out what apartment they're called from (provided the calling
thread has been a good COM citizen and called CoInitializeEx or

> > 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.

Sounds reasonable.

> > 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 :)

It would definitely have to be sometime after WineX 3.0 is out. The bugs
in it might get found during the bughunts I expect we'll have before its
release, so that after the release, I might be able to clean it up and
submit to Wine. But fixing the kludges might still be a bit of work even
after that. We'll see.

More information about the wine-devel mailing list