Hi,
As part of a program that creates an instance of MSXML2.DOMDocument, I get the following errors:
fixme:ole:CoCreateInstance no classfactory created for CLSID {00000323-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {6c736db1-bd94-11d0-8a23-00aa00b58e10}, hres is 0x80040154
(actually there are some more beforehand, but they don't seem fatal).
Anyway, the first one seems to be StdGlobalInterfaceTable, which MSDN indicates should be implemented by Windows. Is this right, and if so, does Wine implement it? I grepped the sources and the only mention is in an IDL file, so I'd assume not.
thanks -mike
On Sun, Mar 02, 2003 at 07:15:16PM +0000, Mike Hearn wrote:
Hi,
As part of a program that creates an instance of MSXML2.DOMDocument, I get the following errors:
fixme:ole:CoCreateInstance no classfactory created for CLSID {00000323-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {6c736db1-bd94-11d0-8a23-00aa00b58e10}, hres is 0x80040154
(actually there are some more beforehand, but they don't seem fatal).
Anyway, the first one seems to be StdGlobalInterfaceTable, which MSDN indicates should be implemented by Windows. Is this right, and if so, does Wine implement it? I grepped the sources and the only mention is in an IDL file, so I'd assume not.
It is not implemented yet.
Should not be hard though. It belongs to OLE32 I guess.
- winedefault.reg entries. - add to OLE32_DllGetClassObject(). - add a brief static implementation of IGlobalInterfaceTable and return that.
Ciao, Marcus
It is not implemented yet.
Should not be hard though. It belongs to OLE32 I guess.
Yeah, it's in OLE32. To a COM newbie however, it looks positively scary - switching interfaces between threading contexts? Huh?
Anyway, I've just been reading up on the whole apartment/threading/marshalling business. Just before I start though I'd like to check that this isn't part of the work TransGaming are doing on marshalling interfaces between threads as part of cleaning up InstallShield... can anybody comment on that?
- winedefault.reg entries.
- add to OLE32_DllGetClassObject().
Easy enough
- add a brief static implementation of IGlobalInterfaceTable and return that.
Yeah, implementing it is the fun bit. What is involved in ensuring an interface pointer is valid in a given context?
thanks -mike
man, 2003-03-03 kl. 10:59 skrev Mike Hearn:
It is not implemented yet.
Should not be hard though. It belongs to OLE32 I guess.
Yeah, it's in OLE32. To a COM newbie however, it looks positively scary
- switching interfaces between threading contexts? Huh?
Yes, it might be a bit scary. The GIT is a pretty much a band-aid solution for shortcomings in the other marshalling modes.
Anyway, I've just been reading up on the whole apartment/threading/marshalling business. Just before I start though I'd like to check that this isn't part of the work TransGaming are doing on marshalling interfaces between threads as part of cleaning up InstallShield... can anybody comment on that?
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.)
- 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.
This won't make a difference before apartments are properly implemented in Wine, though. 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 and).
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
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.
-
Marcus Meissner -
Mike Hearn -
Mike Hearn -
Ove Kaaven