February 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 2/3] user32: Added more dialog owner tests.

by Dmitry Timoshkov

Jacek Caban <jacek(a)codeweavers.com> wrote: > >>> Please don't create fake embedded blocks. > >> I need this declaration here, otherwise I wouldn't be able to use > >> handles for testing lparam value. > > wparam/lparam could be tested directly in the window procedure. > > It would require some global variables and new window procedure. It's > cleaner to do it using existing tools IMO. Writing the tests for user32 requires a bit of efforts, yes. But since you are new to this area I think it's justified to ask for more tests to show that you well understand the code and can proof that the patch is 100% correct. -- Dmitry.

Feb. 29, 2016

Student interested in GSoC 2016 implementing D3DX9 API idea

by Xu Zhao

Hello Wine Community, First congrats that Wine Project get accepted into GSoC 2016 summer organization! I am currently a PhD student in University of Toronto and I am interested in the D3DX9 API implementation task. Mainly because I would like to see more games can run in wine because of my work! My research field is operating system so I am a pretty good C/CPP programmer. However I am not very familiar with DirectX related programming and hopefully I can get some help from the community, like where to start. I have read the wiki entry of D3DX9 API and want to get some help in selecting a reasonable sized API list, maybe someone can reply and provide some help? Thank you! Regards, - Xu -- Xu Zhao i(a)xuzhao.net

Feb. 29, 2016

The Wine Project has been accepted as a GSoC 2016 mentor organization!

by André Hentschel

Hi, I'm a little late, but yes, we're accepted again!

Feb. 29, 2016

Re: [PATCH] winex11: Don't create a temporary context each time X11DRV_wglBindTexImageARB is called.

by Miklós Máté

On 02/29/2016 06:10 PM, Matteo Bruni wrote: > 2016-02-29 3:59 GMT+01:00 Ken Thomases <ken(a)codeweavers.com>: >> On Feb 26, 2016, at 5:29 PM, Miklós Máté <mtmkls(a)gmail.com> wrote: >> >>> @@ -2320,6 +2322,7 @@ static BOOL X11DRV_wglDestroyPbufferARB( struct wgl_pbuffer *object ) >>> TRACE("(%p)\n", object); >>> >>> pglXDestroyPbuffer(gdi_display, object->drawable); >>> + pglXDestroyContext(gdi_display, object->tmp_context); >> I think you need to check if object->tmp_context is non-zero before calling glXDestroyContext() to avoid a GLXBadContext error. Mesa handles ctx=0 by doing nothing. I guess the blob drivers do the same. >> >> >>> + if (!object->tmp_context) { >>> + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >>> + object->prev_context = prev_context; >>> + } else if (object->prev_context != prev_context) { >>> + pglXDestroyContext(gdi_display, object->tmp_context); >>> + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >>> + object->prev_context = prev_context; >>> + } >> Those two branches are mostly the same. This could be reduced to: >> >> if (!object->tmp_context || object->prev_context != prev_context) { >> if (object->tmp_context) >> pglXDestroyContext(gdi_display, object->tmp_context); >> object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >> object->prev_context = prev_context; >> } I don't think this improves readability, but whatever. >> >> >> Is it necessary, when a context is destroyed, to go through all wgl_pbuffer structs looking for any whose prev_context matches the one being destroyed and clear it? Otherwise, you risk having a stale reference that could be reused for a different context and not realize you need to recreate tmp_context. Of course, enumerating all of them in a thread-safe manner is going to require a lot of added infrastructure and complexity. > Good point, that's necessary in principle and it shouldn't be too hard > to do by keeping a wgl_pbuffers list (similarly to context_list for > wgl_context, you should probably reuse the same context_section > critical section for synchronization). > > The other points brought up by Ken are valid too of course. If a context is destroyed, and a new context is created, what are the chances that the two pointers end up being the same? MM

Feb. 29, 2016

Re: [PATCH 6/6] d3d10core/tests: Port test_multiple_render_targets() from d3d11.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=20980 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 5/6] d3d10core/tests: Introduce check_texture_color().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=20979 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 4/6] d3d11/tests: Introduce check_texture_color().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=20978 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 3/6] d3d11/tests: Add test for multiple render targets.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=20977 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: [PATCH 1/6] d3d10core/tests: Port test_create_typeless_resource() from d3d11.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=20976 Your paranoid android. === build (build) === Patch failed to apply

Feb. 29, 2016

Re: ole32: Do not open registry keys with no access rights.

by Thomas Faber

On 2016-02-29 17:03, Sebastian Lackner wrote: > On 29.02.2016 16:49, Thomas Faber wrote: >> While simply opening a subkey (as done here) does not require any >> access rights in particular, NtOpenKey with 0 desired access always >> fails with STATUS_ACCESS_DENIED on Windows. >> Consequently specifying a nonzero access is a prerequisite for some day >> fixing Wine's NtOpenKey behavior in this regard. > > It would be nice to have tests for that in the wine source tree > (marked with todo_wine, until all places which rely on it have been fixed). It definitely would! Patch submitted. Thanks, Thomas

Feb. 29, 2016

Re: [PATCH v3] winex11.drv: Make the GL context current even if no drawables were given.

by Matteo Bruni

2016-02-29 12:45 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 29 February 2016 at 04:33, Ken Thomases <ken(a)codeweavers.com> wrote: >> So the reasons to revert are: a) we don't have a real test case, and b) leaving it in causes a success-in-todo_wine test failure specific to the Mac? Seem somewhat tenuous reasons to revert a change that implements functionality from the spec. >> > Those don't help, but the more important reason is that as far as we > know this functionality isn't supported on any Windows OpenGL driver, > supposedly because of architectural reasons. Yeah. FWIW I checked on AMD Win10 and that's still unsupported.

Feb. 29, 2016

Re: [PATCH] winex11: Don't create a temporary context each time X11DRV_wglBindTexImageARB is called.

by Matteo Bruni

2016-02-29 3:59 GMT+01:00 Ken Thomases <ken(a)codeweavers.com>: > On Feb 26, 2016, at 5:29 PM, Miklós Máté <mtmkls(a)gmail.com> wrote: > >> @@ -2320,6 +2322,7 @@ static BOOL X11DRV_wglDestroyPbufferARB( struct wgl_pbuffer *object ) >> TRACE("(%p)\n", object); >> >> pglXDestroyPbuffer(gdi_display, object->drawable); >> + pglXDestroyContext(gdi_display, object->tmp_context); > > I think you need to check if object->tmp_context is non-zero before calling glXDestroyContext() to avoid a GLXBadContext error. > > >> + if (!object->tmp_context) { >> + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >> + object->prev_context = prev_context; >> + } else if (object->prev_context != prev_context) { >> + pglXDestroyContext(gdi_display, object->tmp_context); >> + object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); >> + object->prev_context = prev_context; >> + } > > Those two branches are mostly the same. This could be reduced to: > > if (!object->tmp_context || object->prev_context != prev_context) { > if (object->tmp_context) > pglXDestroyContext(gdi_display, object->tmp_context); > object->tmp_context = pglXCreateNewContext(gdi_display, object->fmt->fbconfig, object->fmt->render_type, prev_context, True); > object->prev_context = prev_context; > } > > > Is it necessary, when a context is destroyed, to go through all wgl_pbuffer structs looking for any whose prev_context matches the one being destroyed and clear it? Otherwise, you risk having a stale reference that could be reused for a different context and not realize you need to recreate tmp_context. Of course, enumerating all of them in a thread-safe manner is going to require a lot of added infrastructure and complexity. Good point, that's necessary in principle and it shouldn't be too hard to do by keeping a wgl_pbuffers list (similarly to context_list for wgl_context, you should probably reuse the same context_section critical section for synchronization). The other points brought up by Ken are valid too of course.

Feb. 29, 2016

Re: [PATCH 2/3] user32: Added more dialog owner tests.

by Jacek Caban

Hi Dmitry, On 02/29/16 17:40, Dmitry Timoshkov wrote: > Jacek Caban <jacek(a)codeweavers.com> wrote: > >>>> + parent = CreateWindowExA(0, "TestParentClass", "Test parent", >>>> + WS_OVERLAPPEDWINDOW | WS_VISIBLE, >>>> + 100, 100, 200, 200, 0, 0, 0, NULL); >>>> + ok (parent != 0, "Failed to create parent window\n"); >>>> + >>>> + child = CreateWindowExA(0, "TestWindowClass", "Test child", >>>> + WS_OVERLAPPEDWINDOW | WS_VISIBLE, >>>> + 100, 100, 200, 200, 0, 0, 0, NULL); >>>> + ok (child != 0, "Failed to create child window\n"); >>>> + >>>> + child2 = CreateWindowExA(0, "SimpleWindowClass", "Test child2", >>>> + WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, >>>> + 100, 100, 200, 200, child, 0, 0, NULL); >>>> + ok (child2 != 0, "Failed to create child window\n"); >>>> + >>>> + SetParent(child, parent); >>>> + SetFocus(child); >>> Is that really required to use SetParent() instead of specifying correct >>> parent in the CreateWindowEx call? >> Yes, SetParent and CreateWindowEx's parent are not the same thing. See >> for example d13a44e4aa12fa5ad3498c39934e88a7dcd30916 to understand the >> difference. > For child windows it shouldn't matter. It does, otherwise parent would be the owner. >>>> + flush_sequence(); >>>> + DialogBoxA( 0, "TEST_DIALOG", child2, TestModalDlgProc2 ); >>>> + ok_sequence(WmModalDialogSeq_2, "ModalDialog2", TRUE); >>> Is this test supposed to show that actual dialog owner is parent window? >>> If yes, then this theory is not tested at all. >> No, it's actually supposed to show that owner is not the parent. We know >> that owner is child in this case, but current code will use parent >> anyway, which is not right. My tests show that messages are sent to >> child, not parent. > Adding actual checks with GetParent()/GetWindow(GW_OWNER)/GetAncestor() > would be preferrable IMO instead of not obvious message sequences. If I just wanted to test the owner, then yes. But we already have tests for that (the one I pointed you) and this part already works fine. I want to test that messages are sent to the right window, which is what this series fixes. >>>> + SetForegroundWindow(hdlg); >>>> + >>>> + { >>>> + const struct message WmEndDialogSeq[] = { >>>> + { WM_ENABLE, sent }, >>>> + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, >>>> + { HCBT_ACTIVATE, hook|wparam, (WPARAM)hchild }, >>>> + { WM_NCACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, >>>> + { WM_ACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, >>>> + /* FIXME: Following two are optional because Wine sends WM_QUERYNEWPALETTE instead of WM_WINDOWPOSCHANGING */ >>>> + { WM_WINDOWPOSCHANGING, sent|wparam|optional, SWP_NOSIZE|SWP_NOMOVE }, >>>> + { WM_QUERYNEWPALETTE, sent|optional }, >>>> + { WM_NCACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, >>>> + { WM_GETTEXT, sent|optional|defwinproc }, >>>> + { WM_ACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, >>>> + { HCBT_SETFOCUS, hook|wparam, (WPARAM)hchild }, >>>> + { WM_KILLFOCUS, sent|wparam, (WPARAM)hchild }, >>>> + { WM_SETFOCUS, sent|defwinproc|wparam, (WPARAM)hdlg }, >>>> + { 0 } >>>> + }; >>>> + >>>> + flush_sequence(); >>>> + EndDialog(hdlg, 0); >>>> + ok_sequence(WmEndDialogSeq, "EndDialog", FALSE); >>>> + } >>> Please don't create fake embedded blocks. >> I need this declaration here, otherwise I wouldn't be able to use >> handles for testing lparam value. > wparam/lparam could be tested directly in the window procedure. It would require some global variables and new window procedure. It's cleaner to do it using existing tools IMO. Cheers, Jacek

Feb. 29, 2016

Re: [PATCH 2/3] user32: Added more dialog owner tests.

by Dmitry Timoshkov

Jacek Caban <jacek(a)codeweavers.com> wrote: > >> + parent = CreateWindowExA(0, "TestParentClass", "Test parent", > >> + WS_OVERLAPPEDWINDOW | WS_VISIBLE, > >> + 100, 100, 200, 200, 0, 0, 0, NULL); > >> + ok (parent != 0, "Failed to create parent window\n"); > >> + > >> + child = CreateWindowExA(0, "TestWindowClass", "Test child", > >> + WS_OVERLAPPEDWINDOW | WS_VISIBLE, > >> + 100, 100, 200, 200, 0, 0, 0, NULL); > >> + ok (child != 0, "Failed to create child window\n"); > >> + > >> + child2 = CreateWindowExA(0, "SimpleWindowClass", "Test child2", > >> + WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, > >> + 100, 100, 200, 200, child, 0, 0, NULL); > >> + ok (child2 != 0, "Failed to create child window\n"); > >> + > >> + SetParent(child, parent); > >> + SetFocus(child); > > Is that really required to use SetParent() instead of specifying correct > > parent in the CreateWindowEx call? > > Yes, SetParent and CreateWindowEx's parent are not the same thing. See > for example d13a44e4aa12fa5ad3498c39934e88a7dcd30916 to understand the > difference. For child windows it shouldn't matter. > >> + flush_sequence(); > >> + DialogBoxA( 0, "TEST_DIALOG", child2, TestModalDlgProc2 ); > >> + ok_sequence(WmModalDialogSeq_2, "ModalDialog2", TRUE); > > Is this test supposed to show that actual dialog owner is parent window? > > If yes, then this theory is not tested at all. > > No, it's actually supposed to show that owner is not the parent. We know > that owner is child in this case, but current code will use parent > anyway, which is not right. My tests show that messages are sent to > child, not parent. Adding actual checks with GetParent()/GetWindow(GW_OWNER)/GetAncestor() would be preferrable IMO instead of not obvious message sequences. > >> + SetForegroundWindow(hdlg); > >> + > >> + { > >> + const struct message WmEndDialogSeq[] = { > >> + { WM_ENABLE, sent }, > >> + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, > >> + { HCBT_ACTIVATE, hook|wparam, (WPARAM)hchild }, > >> + { WM_NCACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, > >> + { WM_ACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, > >> + /* FIXME: Following two are optional because Wine sends WM_QUERYNEWPALETTE instead of WM_WINDOWPOSCHANGING */ > >> + { WM_WINDOWPOSCHANGING, sent|wparam|optional, SWP_NOSIZE|SWP_NOMOVE }, > >> + { WM_QUERYNEWPALETTE, sent|optional }, > >> + { WM_NCACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, > >> + { WM_GETTEXT, sent|optional|defwinproc }, > >> + { WM_ACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, > >> + { HCBT_SETFOCUS, hook|wparam, (WPARAM)hchild }, > >> + { WM_KILLFOCUS, sent|wparam, (WPARAM)hchild }, > >> + { WM_SETFOCUS, sent|defwinproc|wparam, (WPARAM)hdlg }, > >> + { 0 } > >> + }; > >> + > >> + flush_sequence(); > >> + EndDialog(hdlg, 0); > >> + ok_sequence(WmEndDialogSeq, "EndDialog", FALSE); > >> + } > > Please don't create fake embedded blocks. > > I need this declaration here, otherwise I wouldn't be able to use > handles for testing lparam value. wparam/lparam could be tested directly in the window procedure. > > Also it would be really nice to send the tests first so it would be more clear > > when a todo_wine is removed with a subsequent patch in order to see whether > > the patch is actually related to the previously sent tests. > > I'm not sure I agree. Please don't get me wrong, but when sending tests after the fixes the result can't be easily verified, and therefore this reduces the trust and value of patches. -- Dmitry.

Feb. 29, 2016

Re: [PATCH 2/3] user32: Added more dialog owner tests.

by Jacek Caban

Hi Dmitry, On 02/29/16 17:16, Dmitry Timoshkov wrote: > Hi Jacek, > > Jacek Caban <jacek(a)codeweavers.com> wrote: > >> + parent = CreateWindowExA(0, "TestParentClass", "Test parent", >> + WS_OVERLAPPEDWINDOW | WS_VISIBLE, >> + 100, 100, 200, 200, 0, 0, 0, NULL); >> + ok (parent != 0, "Failed to create parent window\n"); >> + >> + child = CreateWindowExA(0, "TestWindowClass", "Test child", >> + WS_OVERLAPPEDWINDOW | WS_VISIBLE, >> + 100, 100, 200, 200, 0, 0, 0, NULL); >> + ok (child != 0, "Failed to create child window\n"); >> + >> + child2 = CreateWindowExA(0, "SimpleWindowClass", "Test child2", >> + WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, >> + 100, 100, 200, 200, child, 0, 0, NULL); >> + ok (child2 != 0, "Failed to create child window\n"); >> + >> + SetParent(child, parent); >> + SetFocus(child); > Is that really required to use SetParent() instead of specifying correct > parent in the CreateWindowEx call? Yes, SetParent and CreateWindowEx's parent are not the same thing. See for example d13a44e4aa12fa5ad3498c39934e88a7dcd30916 to understand the difference. >> + flush_sequence(); >> + DialogBoxA( 0, "TEST_DIALOG", child2, TestModalDlgProc2 ); >> + ok_sequence(WmModalDialogSeq_2, "ModalDialog2", TRUE); > Is this test supposed to show that actual dialog owner is parent window? > If yes, then this theory is not tested at all. No, it's actually supposed to show that owner is not the parent. We know that owner is child in this case, but current code will use parent anyway, which is not right. My tests show that messages are sent to child, not parent. >> + SetForegroundWindow(hdlg); >> + >> + { >> + const struct message WmEndDialogSeq[] = { >> + { WM_ENABLE, sent }, >> + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, >> + { HCBT_ACTIVATE, hook|wparam, (WPARAM)hchild }, >> + { WM_NCACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, >> + { WM_ACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, >> + /* FIXME: Following two are optional because Wine sends WM_QUERYNEWPALETTE instead of WM_WINDOWPOSCHANGING */ >> + { WM_WINDOWPOSCHANGING, sent|wparam|optional, SWP_NOSIZE|SWP_NOMOVE }, >> + { WM_QUERYNEWPALETTE, sent|optional }, >> + { WM_NCACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, >> + { WM_GETTEXT, sent|optional|defwinproc }, >> + { WM_ACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, >> + { HCBT_SETFOCUS, hook|wparam, (WPARAM)hchild }, >> + { WM_KILLFOCUS, sent|wparam, (WPARAM)hchild }, >> + { WM_SETFOCUS, sent|defwinproc|wparam, (WPARAM)hdlg }, >> + { 0 } >> + }; >> + >> + flush_sequence(); >> + EndDialog(hdlg, 0); >> + ok_sequence(WmEndDialogSeq, "EndDialog", FALSE); >> + } > Please don't create fake embedded blocks. I need this declaration here, otherwise I wouldn't be able to use handles for testing lparam value. > Also it would be really nice to send the tests first so it would be more clear > when a todo_wine is removed with a subsequent patch in order to see whether > the patch is actually related to the previously sent tests. I'm not sure I agree. Thanks for the review, Jacek

Feb. 29, 2016

Re: [PATCH 2/3] user32: Added more dialog owner tests.

by Dmitry Timoshkov

Hi Jacek, Jacek Caban <jacek(a)codeweavers.com> wrote: > + parent = CreateWindowExA(0, "TestParentClass", "Test parent", > + WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 100, 100, 200, 200, 0, 0, 0, NULL); > + ok (parent != 0, "Failed to create parent window\n"); > + > + child = CreateWindowExA(0, "TestWindowClass", "Test child", > + WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 100, 100, 200, 200, 0, 0, 0, NULL); > + ok (child != 0, "Failed to create child window\n"); > + > + child2 = CreateWindowExA(0, "SimpleWindowClass", "Test child2", > + WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, > + 100, 100, 200, 200, child, 0, 0, NULL); > + ok (child2 != 0, "Failed to create child window\n"); > + > + SetParent(child, parent); > + SetFocus(child); Is that really required to use SetParent() instead of specifying correct parent in the CreateWindowEx call? > + flush_sequence(); > + DialogBoxA( 0, "TEST_DIALOG", child2, TestModalDlgProc2 ); > + ok_sequence(WmModalDialogSeq_2, "ModalDialog2", TRUE); Is this test supposed to show that actual dialog owner is parent window? If yes, then this theory is not tested at all. > + SetForegroundWindow(hdlg); > + > + { > + const struct message WmEndDialogSeq[] = { > + { WM_ENABLE, sent }, > + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, > + { HCBT_ACTIVATE, hook|wparam, (WPARAM)hchild }, > + { WM_NCACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, > + { WM_ACTIVATE, sent|wparam|lparam, WA_INACTIVE, (LPARAM)hchild }, > + /* FIXME: Following two are optional because Wine sends WM_QUERYNEWPALETTE instead of WM_WINDOWPOSCHANGING */ > + { WM_WINDOWPOSCHANGING, sent|wparam|optional, SWP_NOSIZE|SWP_NOMOVE }, > + { WM_QUERYNEWPALETTE, sent|optional }, > + { WM_NCACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, > + { WM_GETTEXT, sent|optional|defwinproc }, > + { WM_ACTIVATE, sent|wparam|lparam, WA_ACTIVE, (LPARAM)hdlg }, > + { HCBT_SETFOCUS, hook|wparam, (WPARAM)hchild }, > + { WM_KILLFOCUS, sent|wparam, (WPARAM)hchild }, > + { WM_SETFOCUS, sent|defwinproc|wparam, (WPARAM)hdlg }, > + { 0 } > + }; > + > + flush_sequence(); > + EndDialog(hdlg, 0); > + ok_sequence(WmEndDialogSeq, "EndDialog", FALSE); > + } Please don't create fake embedded blocks. Also it would be really nice to send the tests first so it would be more clear when a todo_wine is removed with a subsequent patch in order to see whether the patch is actually related to the previously sent tests. -- Dmitry.

Feb. 29, 2016

Re: ole32: Do not open registry keys with no access rights.

by Sebastian Lackner

On 29.02.2016 16:49, Thomas Faber wrote: > While simply opening a subkey (as done here) does not require any > access rights in particular, NtOpenKey with 0 desired access always > fails with STATUS_ACCESS_DENIED on Windows. > Consequently specifying a nonzero access is a prerequisite for some day > fixing Wine's NtOpenKey behavior in this regard. It would be nice to have tests for that in the wine source tree (marked with todo_wine, until all places which rely on it have been fixed).

Feb. 29, 2016

Re: [PATCH 2/3] user32: Added more dialog owner tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=20971 Your paranoid android. === w7u (32 bit msg) === msg.c:8926: Test failed: did not get expected count for minimum timeout (51 != ~100). === w7pro64 (32 bit msg) === msg.c:15473: Test failed: wrong status 00400040 === w1064 (32 bit msg) === msg.c:6417: Test failed: Update region shouldn't be empty msg.c:6651: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6653: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6423: Test failed: Regions are different msg.c:6423: Test failed: Regions are different msg.c:6423: Test failed: Regions are different

Feb. 29, 2016

Re: [PATCH 1/2] include: add authz.h

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +typedef struct _AUTHZ_ACCESS_REPLY > +{ > + DWORD ResultListLength; > + DWORD *SaclEvaluationResults; > + DWORD *Error; > +} AUTHZ_ACCESS_REPLY, *PAUTHZ_ACCESS_REPLY; There's a field missing here. > +BOOL WINAPI AuthzInitializeResourceManager(DWORD flags, void *access_checker, > + void *compute_dyn_groups, void *free_dyn_groups, > + const WCHAR *managername, void *handle ); That's not the correct prototype. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2016

Re: [v4 PATCH] comctl32/tooltip: Protect TTM_ADDTOOLW from invalid text pointers

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -1041,6 +1041,9 @@ TOOLTIPS_AddToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > if (ti->cbSize >= TTTOOLINFOW_V2_SIZE && !ti->lpszText && isW) > return FALSE; > > + if(isW && ti->lpszText && IsBadReadPtr(ti->lpszText, sizeof(WCHAR))) > + return FALSE; You want IsBadStringPtrW, and this should most likely be merged with the check above it one way or another. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2016

Re: [PATCH v3] winex11.drv: Make the GL context current even if no drawables were given.

by Henri Verbeet

On 29 February 2016 at 04:33, Ken Thomases <ken(a)codeweavers.com> wrote: > So the reasons to revert are: a) we don't have a real test case, and b) leaving it in causes a success-in-todo_wine test failure specific to the Mac? Seem somewhat tenuous reasons to revert a change that implements functionality from the spec. > Those don't help, but the more important reason is that as far as we know this functionality isn't supported on any Windows OpenGL driver, supposedly because of architectural reasons.

Feb. 29, 2016

Problems in winedbg.1, msiexec.1, winemaker.1

by esr＠thyrsus.com

This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond Problems with winedbg.1: Ambiguous or invalid backslash. This doesn't cause groff a problem. but it confuses doclifter and may confuse older troff implementations. --- winedbg.1-unpatched 2014-06-02 09:40:08.604693388 -0400 +++ winedbg.1 2014-06-02 09:41:09.350110336 -0400 @@ -163,7 +163,7 @@ .IP \fBbreak\ \fIN\fR Adds a breakpoint at line \fIN\fR of current source file. .IP \fBbreak\fR -Adds a breakpoint at current \f$PC\fR address. +Adds a breakpoint at current \fB$PC\fR address. .IP \fBwatch\ *\ \fIN\fR Adds a watch command (on write) at address \fIN\fR (on 4 bytes). .IP \fBwatch\ \fIid\fR Problems with msiexec.1: Ambiguous or invalid backslash. This doesn't cause groff a problem. but it confuses doclifter and may confuse older troff implementations. --- msiexec.1-unpatched 2014-06-02 17:15:58.428528019 -0400 +++ msiexec.1 2014-06-02 17:18:59.360645276 -0400 @@ -24,25 +24,25 @@ \fR[\fBp\fR|\fBo\fR|\fBe\fR|\fBd\fR|\fBc\fR|\fBa\fR|\fBu\fR|\fBm\fR|\fBs\fR|\fBv\fR]\ \ \fR{\fIpackage\fR|\fIproductcode\fR} Repair an installation. Default options are \'omus\' -.IP "\flp\fR" +.IP "\fBlp\fR" Reinstall the file if it is missing. -.IP "\flo\fR" +.IP "\fBlo\fR" Reinstall the file if it is missing or if any older version is installed. -.IP "\fle\fR" +.IP "\fBle\fR" Reinstall the file if it is missing, or if the installed version is equal or older. -.IP "\fld\fR" +.IP "\fBld\fR" Reinstall the file if it is missing or a different version is installed. -.IP "\flc\fR" +.IP "\fBlc\fR" Reinstall the file if it is missing or the checksum does not match. -.IP "\fla\fR" +.IP "\fBla\fR" Reinstall all files. -.IP "\flu\fR" +.IP "\fBlu\fR" Rewrite all required user registry entries. -.IP "\flm\fR" +.IP "\fBlm\fR" Rewrite all required machine registry entries. -.IP "\fls\fR" +.IP "\fBls\fR" Overwrite any conflicting shortcuts. -.IP "\flv\fR" +.IP "\fBlv\fR" Recache the local installation package from the source installation package. .SH PATCHING .IP \fB/p\ \fR{\fIpatch\fR}\ \fR[\fIproperty\fR=\fIfoobar\fR] @@ -65,35 +65,35 @@ [\fBi\fR|\fBw\fR|\fBe\fR|\fBa\fR|\fBr\fR|\fBu\fR|\fBc\fR|\fBm\fR|\fBo\fR|\fBp\fR|\fBv\fR]\ [\fB+\fR|\fB!\fR]\ {\fIlogfile\fR} Enable logging to \fIlogfile\fR. Defaults are \'iwearmo\'. -.IP "\fl*\fR" +.IP "\fBl*\fR" Enable all logging options except \'v\' and \'x\'. -.IP "\fli\fR" +.IP "\fBli\fR" Log status messages. -.IP "\flw\fR" +.IP "\fBlw\fR" Log nonfatal warnings. -.IP "\fle\fR" +.IP "\fBle\fR" Log all error messages. -.IP "\fla\fR" +.IP "\fBla\fR" Log start of actions. -.IP "\flr\fR" +.IP "\fBlr\fR" Log action specifc records. -.IP "\flu\fR" +.IP "\fBlu\fR" Log user requests. -.IP "\flc\fR" +.IP "\fBlc\fR" Log initial UI parameters. -.IP "\flm\fR" +.IP "\fBlm\fR" Log out of memory errors. -.IP "\flo\fR" +.IP "\fBlo\fR" Log out of diskspace messages. -.IP "\flp \fR" +.IP "\fBlp \fR" Log terminal properties. -.IP "\flv \fR" +.IP "\fBlv \fR" Verbose logging. -.IP "\flx \fR" +.IP "\fBlx \fR" Log extra debugging messages. -.IP "\fl+ \fR" +.IP "\fBl+ \fR" Append logging to existing file. -.IP "\fl! \fR" +.IP "\fBl! \fR" Flush each line to log. .SH OTHER OPTIONS .IP \fB/h Problems with winemaker.1: Unbalanced group in command synopis. You probably forgot to open or close a [ ] or { } group properly. --- winemaker.1-unpatched 2014-06-02 09:52:02.517334795 -0400 +++ winemaker.1 2014-06-02 09:54:21.272566508 -0400 @@ -29,7 +29,6 @@ .br [ .BR "--generated-files " "] [ " "--nogenerated-files " "] -] .br [ .BR "--wine32 " "]

Feb. 29, 2016

Re: [PATCH 4/4] d3d10core/tests: Test swapchain buffer cycling.

by Henri Verbeet

On 24 February 2016 at 23:28, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Testing multisampling is not possible because only > DXGI_SWAP_EFFECT_DISCARD supports multisampled swapchains and it allows > only access to buffer 0. > > Not exactly test_flip from ddraw because we can't write to the end of > the chain... > > Plenty of todo_wine in here. The read-only part is missing and texturing > from swapchain buffers doesn't work either. > > foo > Is there a d3d11 version of this as well?

Feb. 29, 2016

Re: xcopy/tests: Reset "current directory" of current process.

by Alexandre Julliard

Jactry Zeng <jzeng(a)codeweavers.com> writes: > @@ -97,4 +99,5 @@ START_TEST(xcopy) > > DeleteFileA("xcopy1"); > RemoveDirectoryA("xcopytest"); > + SetCurrentDirectoryW(curdir); Restoring the directory at process exit is not useful. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2016

Re: shell32/tests: Reset "current directory" of current process.

by Alexandre Julliard

Jactry Zeng <jzeng(a)codeweavers.com> writes: > @@ -1882,6 +1884,7 @@ static void test_ITEMIDLIST_format(void) { > } > > IShellFolder_Release(psfPersonal); > + SetCurrentDirectoryW(curdir); > } You'd need to do that on the various error returns too. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2016