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.
