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.