ole32: OleInitialize/OleUnitialize behaves differently in Wine and Windows

Paul Gofman gofmanp at gmail.com
Mon Jan 11 17:11:35 CST 2016


    OleInitialize/OleUnitialize behave differently in Wine and Windows
(at least WinXP) in the following special case. The application thread
has a multithreaded apartment initialized. Then OleInitialize is called
from the same thread, followed by OleUnitialize call later. According to
MSDN spec OleInitialize should return RPC_E_CHANGED_MODE (which is the
case both in Windows and Wine) and OleUnitilize call should not be
performed after that. If OleUnitilize is actually called (which is the
case in the application), it presumably should uninitialize the COM
apartment completely just as in case CoUnitialize (this is what Wine
does). But this seems to be not the case under Windows.
    I am attaching a patch which adds such a test to
ole32/tests/compobj. The test does CoInitializeEx(NULL,
COINIT_MULTITHREADED), then OleInitialize, OleUninitialize and then
tries to create COM object. The test fails under Wine (apartment not
initialized) but passes OK under my WinXP virtual machine. If to change
OleInitialize/OleUninitialize to CoInitializeEx(NULL,
COINIT_APARTMENTTHREADED)/CoUnitialize the test will fail both under
Wine and Windows.

    The application works under Windows but crashes under Wine. I can
tweak the application to work under Wine by, for instance, incrementing
init counter in CoInitializeEx in ole32/compobj.c despite of returning
RPC_E_CHANGED_MODE.

    So, the questions are:
1. Should I submit this test to wine-patches?
2. Is there some obvious way how can this be correctly fixed? E. g. it
could potentially be fixed by adding some extra field to COM current
info which would be checked in OleUninitialize not to allow the
decrement of init counter by OleUnitialize below the value that was
before first OleInit call, but I am not sure for now what Windows
actually does. Maybe there are some known good ways how to explore this
refcounting behaviour under Windows? If no, I could try to guess native
behaviour by doing multiple CoInit/CoUninit/OleInit/OleUninit in
different combinations followed by CoCreateInstance.

Regards,
    Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160112/563610a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OleInit_test.patch
Type: text/x-patch
Size: 1394 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160112/563610a0/attachment.bin>


More information about the wine-devel mailing list