[Bug 20220] AutoCAD 2009: unimplemented function windowscodecs.dll.WICCreateImagingFactory_Proxy

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Oct 10 14:47:11 CDT 2010


http://bugs.winehq.org/show_bug.cgi?id=20220

--- Comment #13 from Damjan Jovanovic <damjan.jov at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list