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