http://bugs.winehq.org/show_bug.cgi?id=20220
--- Comment #13 from Damjan Jovanovic damjan.jov@gmail.com 2010-10-10 14:47:09 CDT --- I've written up a patch to add COM registration and widl-generated proxies and stubs to windowscodecs. Most of the stubbed windowscodecs.spec methods now make sense - the proxy methods have exactly the same names - but finer points of COM marshaling are now the problem.
According to MSDN its prototype is "WICCreateImagingFactory_Proxy(__in UINT SDKVersion, __out IWICImagingFactory **ppIImagingFactory);". If you return a plain IWICImagingFactory in the **ppIImagingFactory parameter, it then calls one of the exported IWICImagingFactory proxy methods, which calls into the widl generated code, which expects a proxy not the raw object -> exception c00000005 (ie. SIGSEGV).
I then looked into getting WICCreateImagingFactory_Proxy to return a proxy. To generate a proxy is not straightforward, you apparently have to call into the widl generated code to create an IPSFactoryBuffer, then call IPSFactoryBuffer_CreateProxy. This gives a proxy ready to marshal, but that proxy is utterly useless unless its IRpcProxyBuffer is connected to something. But connected *to what*? The registry values indicate windowscodecs runs in-process. You cannot even create an instance of IWICImagingFactory using CoCreateInstance with an out-of-process context. And the arguments to WICCreateImagingFactory_Proxy don't specify what to connect to.
Maybe the exports from windowscodecs are meant to go to the plain methods and not the widl proxy - that would probably work. But I doubt it - why all the "_Proxy" suffixes whose names exactly match the widl code?
Maybe the caller connects the proxy to something later? Returning the proxy to the application results in the application calling NdrProxyInitialize with the proxy. NdrProxyInitialize calls StdProxy_GetChannel, which return a NULL channel. Later NdrProxyInitialize attempts to access the NULL channel, causing a c0000005 :-(.
Anyway that's it for this weekend.