> 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 <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
