August 2017 - Wine-Devel - list.winehq.org

Re: [PATCH v2] ole32: Store proxy/stub CLSIDs per process, not per apartment.

by Zebediah Figura

On 08/02/2017 04:32 AM, Huw Davies wrote: > On Tue, Aug 01, 2017 at 04:54:45PM -0500, Zebediah Figura wrote: >> v2: use proper synchronization; add an MTA test (thanks Sebastian) >> Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> >> --- >> dlls/ole32/compobj.c | 48 ++++++++++++++++++++++++++++++------------ >> dlls/ole32/compobj_private.h | 1 - >> dlls/ole32/tests/compobj.c | 50 ++++++++++++++++++++++++++++++++++++++++++-- >> 3 files changed, 83 insertions(+), 16 deletions(-) >> >> diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c >> index 60244485249..ee904adbc38 100644 >> --- a/dlls/ole32/compobj.c >> +++ b/dlls/ole32/compobj.c >> @@ -170,8 +170,20 @@ struct registered_psclsid >> struct list entry; >> IID iid; >> CLSID clsid; >> + OXID apartment_id; >> }; >> >> +static struct list RegisteredPSCLSIDList = LIST_INIT(RegisteredPSCLSIDList); > > Please don't use CamelCase. > >> + >> +static CRITICAL_SECTION csRegisteredPSCLSIDList; >> +static CRITICAL_SECTION_DEBUG psclsid_cs_debug = >> +{ >> + 0, 0, &csRegisteredPSCLSIDList, >> + { &psclsid_cs_debug.ProcessLocksList, &psclsid_cs_debug.ProcessLocksList }, >> + 0, 0, { (DWORD_PTR)(__FILE__ ": csRegisteredPSCLSIDList") } >> +}; >> +static CRITICAL_SECTION csRegisteredPSCLSIDList = { &psclsid_cs_debug, -1, 0, 0, 0, 0 }; >> + >> /* >> * This is a marshallable object exposing registered local servers. >> * IServiceProvider is used only because it happens meet requirements >> @@ -622,7 +634,6 @@ static APARTMENT *apartment_construct(DWORD model) >> >> list_init(&apt->proxies); >> list_init(&apt->stubmgrs); >> - list_init(&apt->psclsids); >> list_init(&apt->loaded_dlls); >> apt->ipidc = 0; >> apt->refs = 1; >> @@ -1173,15 +1184,22 @@ DWORD apartment_release(struct apartment *apt) >> stub_manager_int_release(stubmgr); >> } >> >> - LIST_FOR_EACH_SAFE(cursor, cursor2, &apt->psclsids) >> + EnterCriticalSection(&csRegisteredPSCLSIDList); >> + >> + LIST_FOR_EACH_SAFE(cursor, cursor2, &RegisteredPSCLSIDList) >> { >> struct registered_psclsid *registered_psclsid = >> LIST_ENTRY(cursor, struct registered_psclsid, entry); >> >> - list_remove(&registered_psclsid->entry); >> - HeapFree(GetProcessHeap(), 0, registered_psclsid); >> + if (registered_psclsid->apartment_id == apt->oxid) >> + { >> + list_remove(&registered_psclsid->entry); >> + HeapFree(GetProcessHeap(), 0, registered_psclsid); >> + } >> } >> >> + LeaveCriticalSection(&csRegisteredPSCLSIDList); >> + >> /* if this assert fires, then another thread took a reference to a >> * stub manager without taking a reference to the containing >> * apartment, which it must do. */ > > > It seems it's more complicated than this. Consider two already > existing STAs, if the PSClsid is registered in STA1 which then leaves > the apt, a call in STA2 to CoGetPSCLSID() still succeeds. > > You'll want to expand the tests to cover things like this to really figure out > what's going on. > > Also note that the MTA -> MTA test isn't very convincing, since there is only > one MTA and hence both threads are in the same apt. > > Huw. > > I see; I'll send an updated patch.

Aug. 2, 2017

Re: [PATCHv2] msvcrt: Export -f suffixed float functions functions on arm64

by Martin Storsjö

Hi Piotr, On Wed, 2 Aug 2017, Piotr Caban wrote: > Hi Martin, > > On 07/31/17 14:47, Martin Storsjo wrote: >> --- a/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec >> +++ b/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec >> @@ -77,7 +77,7 @@ >> @ cdecl _fdtest(ptr) ucrtbase._fdtest >> @ stub _fdunscale >> @ cdecl _finite(double) ucrtbase._finite >> -@ cdecl -arch=arm,x86_64 _finitef(float) ucrtbase._finitef >> +@ cdecl -arch=arm,x86_64,arm64 _finitef(float) ucrtbase._finitef >> @ cdecl _fpclass(double) ucrtbase._fpclass >> @ stub _fpclassf >> @ cdecl -arch=i386 -ret64 _ftol() ucrtbase._ftol >> @@ -85,7 +85,7 @@ >> @ cdecl _hypot(double double) ucrtbase._hypot >> @ cdecl _hypotf(float float) ucrtbase._hypotf >> @ cdecl _isnan(double) ucrtbase._isnan >> -@ cdecl -arch=arm,x86_64 _isnanf(float) ucrtbase._isnanf >> +@ cdecl -arch=arm,x86_64,arm64 _isnanf(float) ucrtbase._isnanf > Maybe I'm checking it incorrectly but I don't see isnanf in the lib file. Is > it really exported on arm64? I didn't check all of the functions but _scalbf > also seems to be not exported. Hmm, indeed - thanks for checking thoroughly. I'll recheck them one by one with the import library. FWIW it seems like this also is wrong for _isnanf already now. For that case, it can be traced back to 599d92a2, where I bootstrapped ucrtbase, with a list of symbols dumped from real DLLs, but with the -arch flags taken from msvcrt (where it was added to a bunch of float functions in 599d0802). // Martin

Aug. 2, 2017

Re: [PATCHv2] msvcrt: Export -f suffixed float functions functions on arm64

by Piotr Caban

Hi Martin, On 07/31/17 14:47, Martin Storsjo wrote: > --- a/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > +++ b/dlls/api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec > @@ -77,7 +77,7 @@ > @ cdecl _fdtest(ptr) ucrtbase._fdtest > @ stub _fdunscale > @ cdecl _finite(double) ucrtbase._finite > -@ cdecl -arch=arm,x86_64 _finitef(float) ucrtbase._finitef > +@ cdecl -arch=arm,x86_64,arm64 _finitef(float) ucrtbase._finitef > @ cdecl _fpclass(double) ucrtbase._fpclass > @ stub _fpclassf > @ cdecl -arch=i386 -ret64 _ftol() ucrtbase._ftol > @@ -85,7 +85,7 @@ > @ cdecl _hypot(double double) ucrtbase._hypot > @ cdecl _hypotf(float float) ucrtbase._hypotf > @ cdecl _isnan(double) ucrtbase._isnan > -@ cdecl -arch=arm,x86_64 _isnanf(float) ucrtbase._isnanf > +@ cdecl -arch=arm,x86_64,arm64 _isnanf(float) ucrtbase._isnanf Maybe I'm checking it incorrectly but I don't see isnanf in the lib file. Is it really exported on arm64? I didn't check all of the functions but _scalbf also seems to be not exported. Thanks, Piotr

Aug. 2, 2017

Re: [PATCH] comctl32/taskdialog: Add callback and tests

by Nikolay Sivov

On 28.07.2017 19:53, Fabian Maurer wrote: > > +static HRESULT callback(struct taskdialog_info *dialog_info, UINT uNotification, WPARAM wParam, LPARAM lParam) > +{ > + if(dialog_info->callback) > + return dialog_info->callback(dialog_info->hwnd, uNotification, wParam, lParam, dialog_info->callback_data); > + return S_OK; > +} Please use consistent naming and formatting, like space after 'if' for example, and uNotification -> notification. > + > static INT_PTR CALLBACK taskdialog_proc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) > { > + static const WCHAR taskdialog_info_propnameW[] = {'T','a','s','k','D','i','a','l','o','g','I','n','f','o',0}; > + struct taskdialog_info *dialog_info; > + > TRACE("hwnd=%p msg=0x%04x wparam=%lx lparam=%lx\n", hwnd, msg, wParam, lParam); > > + if(msg != WM_INITDIALOG && msg != WM_NCDESTROY) > + dialog_info = GetPropW(hwnd, taskdialog_info_propnameW); > + Why WM_NCDESTROY is a special case? > switch (msg) > { > + case WM_INITDIALOG: > + dialog_info = (struct taskdialog_info *)lParam; > + dialog_info->hwnd = hwnd; > + SetPropW(hwnd, taskdialog_info_propnameW, dialog_info); > + > + callback(dialog_info, TDN_DIALOG_CONSTRUCTED, 0, 0); > + callback(dialog_info, TDN_CREATED, 0, 0); > + break; This looks suspicious, documentation is not strict on this, but it seems TDN_CREATED corresponds for to WM_SHOWWINDOW stage. > case WM_COMMAND: > if (HIWORD(wParam) == BN_CLICKED) > { > WORD command_id = LOWORD(wParam); > - EndDialog(hwnd, command_id); > + click_button(dialog_info, command_id); > return TRUE; > } > break; > + case WM_DESTROY: > + callback(dialog_info, TDN_DESTROYED, 0, 0); > + RemovePropW(hwnd, taskdialog_info_propnameW); > + break; > + > + /* Custom messages*/ What do you mean by "custom"? > + > + case TDM_CLICK_BUTTON: > + click_button(dialog_info, wParam); > + break; > } > return FALSE; > } > @@ -507,17 +556,24 @@ HRESULT WINAPI TaskDialogIndirect(const TASKDIALOGCONFIG *taskconfig, int *butto > int *radio_button, BOOL *verification_flag_checked) > { > DLGTEMPLATE *template; > + struct taskdialog_info dialog_info; > INT ret; > > TRACE("%p, %p, %p, %p\n", taskconfig, button, radio_button, verification_flag_checked); > > + if(!taskconfig || taskconfig->cbSize != sizeof(TASKDIALOGCONFIG)) > + return E_INVALIDARG; Tests you added only check cbSize == 0 case. > + > + dialog_info.callback = taskconfig->pfCallback; > + dialog_info.callback_data = taskconfig->lpCallbackData; > + > template = create_taskdialog_template(taskconfig); > - ret = DialogBoxIndirectParamW(taskconfig->hInstance, template, taskconfig->hwndParent, taskdialog_proc, 0); > + ret = DialogBoxIndirectParamW(taskconfig->hInstance, template, taskconfig->hwndParent, taskdialog_proc, (LPARAM)&dialog_info); > Free(template); > > if (button) *button = ret; > if (radio_button) *radio_button = taskconfig->nDefaultButton; > - if (verification_flag_checked) *verification_flag_checked = TRUE; > + if (verification_flag_checked) *verification_flag_checked = FALSE; Why do you need this flag value change? > > return S_OK; > } > diff --git a/dlls/comctl32/tests/taskdialog.c b/dlls/comctl32/tests/taskdialog.c > index c937127897..867361617c 100644 > --- a/dlls/comctl32/tests/taskdialog.c > +++ b/dlls/comctl32/tests/taskdialog.c > @@ -24,13 +24,250 @@ > #include "winuser.h" > #include "commctrl.h" > > +#include "wine/list.h" > #include "wine/test.h" > #include "v6util.h" > +#include "msg.h" > + > +#define WM_TD_CALLBACK (WM_APP) /* Custom dummy message to wrap callback notifications */ > + > +#define NUM_MSG_SEQUENCES 1 > +#define TASKDIALOG_SEQ_INDEX 0 > + > +#define TEST_NUM_BUTTONS 20 /* Number of custom buttons to test with */ > + > +#define ID_START 20 /* Lower IDs might be used by the system */ > +#define ID_START_BUTTON (ID_START + 0) > > static HRESULT (WINAPI *pTaskDialogIndirect)(const TASKDIALOGCONFIG *, int *, int *, BOOL *); > static HRESULT (WINAPI *pTaskDialog)(HWND, HINSTANCE, const WCHAR *, const WCHAR *, const WCHAR *, > TASKDIALOG_COMMON_BUTTON_FLAGS, const WCHAR *, int *); > > +static struct msg_sequence *sequences[NUM_MSG_SEQUENCES]; > + > +/* Message lists to test against */ > + > +struct message_send_info > +{ > + UINT send_message; > + WPARAM send_wparam; > + LPARAM send_lparam; > + > + BOOL post; /* post instead of send */ > + const CHAR *title_target; /* control text, 0 means it's send to the dialog form instead */ > +}; > + > +struct message_info > +{ > + UINT recv_message; /* Message the callback receives */ > + WPARAM recv_wparam; > + LPARAM recv_lparam; > + > + HRESULT ret; /* Value the callback should return */ > + > + struct message_send_info send[9]; /* Message to send to trigger the next callback message */ > +}; > + > +static const struct message_info *current_message_info; > + > +static const struct message_info mes_return_press_ok[] = { > + { TDN_CREATED, 0, 0, S_OK, { > + { WM_KEYDOWN, VK_RETURN, 0, TRUE }, > + { 0 }}}, > + { TDN_BUTTON_CLICKED, IDOK, 0, S_OK, {{ 0 }}}, > + { 0 } > +}; > + > +static const struct message_info mes_cancel_button_press[] = { > + { TDN_CREATED, 0, 0, S_OK, { > + { TDM_CLICK_BUTTON, IDOK, 0, TRUE }, > + { TDM_CLICK_BUTTON, IDOK, 0, TRUE }, > + { TDM_CLICK_BUTTON, IDOK, 0, TRUE }, > + { 0 }}}, > + { TDN_BUTTON_CLICKED, IDOK, 0, S_FALSE, {{ 0 }}}, > + { TDN_BUTTON_CLICKED, IDOK, 0, 0xFF, {{ 0 }}}, /* Random return value tested here */ > + { TDN_BUTTON_CLICKED, IDOK, 0, S_OK, {{ 0 }}}, > + { 0 } > +}; > + > +static const struct message_info mes_send_button_directly[] = { > + { TDN_CREATED, 0, 0, S_OK, { > + { WM_LBUTTONDOWN, MK_LBUTTON, 0, TRUE, "02" }, > + { WM_LBUTTONUP, 0, 0, TRUE, "02" }, > + { 0 }}}, > + { TDN_BUTTON_CLICKED, ID_START + 2, 0, S_OK, {{ 0 }}}, > + { 0 } > +}; This looks too complicated, I'd just check notifications callback received, using 'struct message' data, same way WM_NOTIFY tests work. > + > +/* Create a message to test against */ > +static struct message create_test_message(UINT message, WPARAM wParam, LPARAM lParam) > +{ > + struct message mes; > + > + mes.message = WM_TD_CALLBACK; > + mes.id = message; > + mes.flags = sent|wparam|lparam|id; > + mes.wParam = wParam; > + mes.lParam = lParam; > + > + return mes; > +} > + > +/* Our only way to get a button handle, since GetDlgItem and FindWindowEx don't work for the official taskdialog */ > + > +static HWND taskdialog_child; > +BOOL CALLBACK enum_taskdialog_children_proc(HWND hwnd, LPARAM lParam) > +{ > + CHAR text[100]; > + const CHAR *title = (const CHAR *)lParam; > + > + GetWindowTextA(hwnd, text, sizeof(text)); > + > + if(lstrcmpA(text, title) == 0) > + { > + taskdialog_child = hwnd; > + return FALSE; > + } > + > + return TRUE; > +} > + > +static HWND get_child_from_title(HWND hwnd_parent, const CHAR *title) > +{ > + taskdialog_child = NULL; > + EnumChildWindows(hwnd_parent, enum_taskdialog_children_proc, (LPARAM)title); > + return taskdialog_child; > +} I don't think we need to get that deep. > > + init_msg_sequences(sequences, NUM_MSG_SEQUENCES); > + test_TaskDialogIndirect(); This name is too generic, in a test function like that you can test invalid parameter handling for example. Then have another function for callback notifications, and another one for TDM_* messages. I think for first iteration test should simply check creation/destruction notifications and callback user data value.

Aug. 2, 2017

Re: [PATCH v2] ole32: Store proxy/stub CLSIDs per process, not per apartment.

by Huw Davies

On Tue, Aug 01, 2017 at 04:54:45PM -0500, Zebediah Figura wrote: > v2: use proper synchronization; add an MTA test (thanks Sebastian) > Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> > --- > dlls/ole32/compobj.c | 48 ++++++++++++++++++++++++++++++------------ > dlls/ole32/compobj_private.h | 1 - > dlls/ole32/tests/compobj.c | 50 ++++++++++++++++++++++++++++++++++++++++++-- > 3 files changed, 83 insertions(+), 16 deletions(-) > > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index 60244485249..ee904adbc38 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -170,8 +170,20 @@ struct registered_psclsid > struct list entry; > IID iid; > CLSID clsid; > + OXID apartment_id; > }; > > +static struct list RegisteredPSCLSIDList = LIST_INIT(RegisteredPSCLSIDList); Please don't use CamelCase. > + > +static CRITICAL_SECTION csRegisteredPSCLSIDList; > +static CRITICAL_SECTION_DEBUG psclsid_cs_debug = > +{ > + 0, 0, &csRegisteredPSCLSIDList, > + { &psclsid_cs_debug.ProcessLocksList, &psclsid_cs_debug.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": csRegisteredPSCLSIDList") } > +}; > +static CRITICAL_SECTION csRegisteredPSCLSIDList = { &psclsid_cs_debug, -1, 0, 0, 0, 0 }; > + > /* > * This is a marshallable object exposing registered local servers. > * IServiceProvider is used only because it happens meet requirements > @@ -622,7 +634,6 @@ static APARTMENT *apartment_construct(DWORD model) > > list_init(&apt->proxies); > list_init(&apt->stubmgrs); > - list_init(&apt->psclsids); > list_init(&apt->loaded_dlls); > apt->ipidc = 0; > apt->refs = 1; > @@ -1173,15 +1184,22 @@ DWORD apartment_release(struct apartment *apt) > stub_manager_int_release(stubmgr); > } > > - LIST_FOR_EACH_SAFE(cursor, cursor2, &apt->psclsids) > + EnterCriticalSection(&csRegisteredPSCLSIDList); > + > + LIST_FOR_EACH_SAFE(cursor, cursor2, &RegisteredPSCLSIDList) > { > struct registered_psclsid *registered_psclsid = > LIST_ENTRY(cursor, struct registered_psclsid, entry); > > - list_remove(&registered_psclsid->entry); > - HeapFree(GetProcessHeap(), 0, registered_psclsid); > + if (registered_psclsid->apartment_id == apt->oxid) > + { > + list_remove(&registered_psclsid->entry); > + HeapFree(GetProcessHeap(), 0, registered_psclsid); > + } > } > > + LeaveCriticalSection(&csRegisteredPSCLSIDList); > + > /* if this assert fires, then another thread took a reference to a > * stub manager without taking a reference to the containing > * apartment, which it must do. */ It seems it's more complicated than this. Consider two already existing STAs, if the PSClsid is registered in STA1 which then leaves the apt, a call in STA2 to CoGetPSCLSID() still succeeds. You'll want to expand the tests to cover things like this to really figure out what's going on. Also note that the MTA -> MTA test isn't very convincing, since there is only one MTA and hence both threads are in the same apt. Huw.

Aug. 2, 2017

Re: shell32: Implement SHCreateItemInKnownFolder.

by Huw Davies

On Wed, Aug 02, 2017 at 10:58:34AM +0800, Jactry Zeng wrote: > 2017-07-31 15:47 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > > > > You probably want to use SHGetKnownFolderIDList() instead of these > > last two calls. > > > I had some more tests of SHGetKnownFolderIDList() and IShellFolder_BindToObject > (), I found that in some cases SHGetKnownFolderIDList() will return a pidl > which ILIsEmpty() thinks it is empty. This is presumably a bug in SHGetKnownFolderIDList(), which we should fix. Huw.

Aug. 2, 2017

Re: [PATCH 2/3] msvcrt: Set errno through the _matherr function.

by Alex Henrie

2017-08-01 11:25 GMT-06:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 08/01/17 08:13, Alex Henrie wrote: >> >> @@ -252,7 +320,7 @@ float CDECL MSVCRT_powf( float x, float y ) >> { >> /* FIXME: If x < 0 and y is not integral, set EDOM */ >> float z = powf(x,y); >> - if (!finitef(z)) *MSVCRT__errno() = MSVCRT_EDOM; >> + if (!finitef(z)) math_error(_DOMAIN, "powf", x, 0, ret); > > ret is not defined here. Good catch, thanks. I will test a 64-bit build of Wine before resubmitting. 2017-08-01 11:32 GMT-06:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 08/01/17 19:25, Piotr Caban wrote: >> >> Could you please also add exception.name tests (in this case it should be >> set to pow instead of powf). > > I've done the testing incorrectly. Adding a test for exception.name value > will be useful anyway. I thought about testing exception.name, but then I found that on Windows a lot of the reported names don't match the functions' real names. For example, atanh reports itself to be asin, which is almost certainly a bug. I'd prefer to not write tests for buggy behavior that no application depends on. Who knows, maybe Microsoft will fix it in a future release. -Alex

Aug. 2, 2017

Re: shell32: Implement SHCreateItemInKnownFolder.

by Jactry Zeng

Hi Huw, Thanks for review! 2017-07-31 15:47 GMT+08:00 Huw Davies <huw(a)codeweavers.com>: > > You probably want to use SHGetKnownFolderIDList() instead of these > last two calls. > I had some more tests of SHGetKnownFolderIDList() and IShellFolder_BindToObject(), I found that in some cases SHGetKnownFolderIDList() will return a pidl which ILIsEmpty() thinks it is empty. And IShellFolder_BindToObject() will return E_INVALIDARG for an empty pidl. So keep using SHGetKnownFolderPath() and IShellFolder_ParseDisplayName() seems can make this work more easy? -- Regards, Jactry Zeng

Aug. 2, 2017

Re: [5/6] wsdapi: Add support for sending messages via UDP multicast.

by Owen Rudge

On 27/07/2017 21:22, Vincent Povirk wrote: > Using rand() for this doesn't seem very random, and it could interfere > with an application's use of rand(). I've altered this to use BCryptGenRandom instead. > Sending messages to every adapter in sequence, with a delay for each, > doesn't seem right. The spec doesn't explicitly state how multiple adapters should be handled. The SOAP over UDP spec just suggests how multicast messages should be sent (including delays and repeats as appropriate). However, I've changed this now so that a new thread is spawned for each adapter's transmission, which should reduce the overall time taken, and will also allow the Publish/UnPublish etc method to return immediately (or near enough), which appears to be the behaviour on Windows, as you've pointed out. > It seems like this will call WSACleanup even when freeing an object > that was never used. Thanks, I've amended this too. -- Owen Rudge http://www.owenrudge.net/

Aug. 1, 2017

Re: [PATCH] ole32: Store proxy/stub CLSIDs per process, not per apartment.

by Sebastian Lackner

On 01.08.2017 23:27, Zebediah Figura wrote: > @@ -1173,13 +1175,16 @@ DWORD apartment_release(struct apartment *apt) > stub_manager_int_release(stubmgr); > } > > - LIST_FOR_EACH_SAFE(cursor, cursor2, &apt->psclsids) > + LIST_FOR_EACH_SAFE(cursor, cursor2, &RegisteredPSCLSIDList) Accessing a global list from multiple threads requires synchronization (for example, using a CS to avoid conflicting access). Using apt->cs is not sufficient because it might be a different one for each thread. The same also applies to all other places where the list is used. > @@ -1177,6 +1196,15 @@ static void test_CoRegisterPSClsid(void) > hr = CoRegisterPSClsid(&IID_IWineTest, &CLSID_WineTestPSFactoryBuffer); > ok_ole_success(hr, "CoRegisterPSClsid"); > > + hr = CoGetPSClsid(&IID_IWineTest, &clsid); > + ok_ole_success(hr, "CoGetPSClsid"); > + ok(IsEqualGUID(&clsid, &CLSID_WineTestPSFactoryBuffer), "expected %s, got %s\n", > + wine_dbgstr_guid(&CLSID_WineTestPSFactoryBuffer), wine_dbgstr_guid(&clsid)); > + > + thread = CreateThread(NULL, 0, register_ps_clsid_thread, NULL, 0, &tid); > + ok(thread != NULL, "CreateThread failed with error %d\n", GetLastError()); > + ok(!WaitForSingleObject(thread, 10000), "wait timed out\n"); The thread handle is leaked here. Also, it would be more convincing to run the tests for both STA and MTA.

Aug. 1, 2017