December 2014 - Wine-devel - list.winehq.org

Re: shell32: Implement IApplicationAssociationRegistration, QueryCurrentDefault (try 4)
by Nikolay Sivov 17 Dec '14

17 Dec '14

On 12/17/2014 08:11 AM, Alistair Leslie-Hughes wrote: > - test_IApplicationAssociationRegistration_QueryInterface(); > + /* this works since Vista */ > + hr = CoCreateInstance(&CLSID_ApplicationAssociationRegistration, NULL, CLSCTX_INPROC_SERVER, > + &IID_IApplicationAssociationRegistration, (LPVOID*)&appreg); > + if (hr == S_OK) > + { > + test_IApplicationAssociationRegistration_QueryInterface(appreg); > + test_IApplicationAssociationRegistration_QueryCurrentDefault(appreg); > + > + IApplicationAssociationRegistration_Release(appreg); > + } > + else > + skip("IApplicationAssociationRegistration not supported: 0x%x\n", hr); This should be win_skip().

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByName (try 3)
by Marvin 17 Dec '14

17 Dec '14

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=10793 Your paranoid android. === w8 (32 bit address) === The test timed out

2 1

Re: [1/2] server: Never attempt to wake up the current thread.
by Sebastian Lackner 16 Dec '14

16 Dec '14

On 16.12.2014 06:23, Sebastian Lackner wrote: > Alternative approach for patch #107840 "server: Avoid sending unexpected wakeup with uninitialized cookie value." (which should also still be fine, but this solution is probably a bit easier). > > We never want to send any wakeup cookies to our currently active thread, so just fake success in this case. > To demonstrate what happens without this patch (and to avoid any regressions) I've also added a test in patch 2/2. > > The unexpected cookies itself are not visible without debug messages of course, but because of the buffer size limitation the whole wineserver freezes. > When forcefully killing the test, the wineserver also crashes with: > > ==14785== Invalid read of size 4 > ==14785== at 0x807CE1B: select_on (thread.c:830) > ==14785== by 0x807E604: req_select (thread.c:1462) > ==14785== by 0x8076003: call_req_handler (request.c:247) > ==14785== by 0x807620A: read_request (request.c:302) > ==14785== by 0x807B8C1: thread_poll_event (thread.c:267) > ==14785== by 0x805679F: fd_poll_event (fd.c:446) > ==14785== by 0x8056A43: main_loop_epoll (fd.c:541) > ==14785== by 0x8056E2F: main_loop (fd.c:886) > ==14785== by 0x805F4B6: main (main.c:148) > ==14785== Address 0x50 is not stack'd, malloc'd or (recently) free'd > ==14785== > ==14785== Process terminating with default action of signal 11 (SIGSEGV): dumping core > > Reason for the crash is that the wakeup write() syscall fails -> the thread is terminated with kill_thread() -> this sets current = NULL - the code later assumes that 'current' is still a valid pointer. By not sending wakeup cookies we avoid this whole code path, and the test runs well. > > --- > server/thread.c | 4 ++++ > 1 file changed, 4 insertions(+) > Please ignore this patch for now, there are some situations (not covered by existing tests) where this idea would not work correctly.

1 0

Re: include/ddk: add csq.h
by Austin English 16 Dec '14

16 Dec '14

On Thu, Nov 13, 2014 at 3:30 PM, Austin English <austinenglish(a)gmail.com> wrote: > > > -- > -Austin > Patch dropped off the tracker without comment, could I get some feedback please? -- -Austin

1 0

Re: zh_CN Translation Submittion
by Nikolay Sivov 15 Dec '14

15 Dec '14

On 15.12.2014 17:39, Jeff Bai wrote: > Umm... I think POEdit is the one who made these changes... Not sure if it's my settings or what. Yes, it's mostly likely it. But you don't have to use it, your favorite text editor will work just fine. > > >> 在 2014年12月15日，上午12:01，Nikolay Sivov <bunglehead(a)gmail.com> 写道： >> >>> On 15.12.2014 7:53, Jeff Bai wrote: >>> Hello, fellow developers. >>> >>> I've got several hundred strings translated to zh_CN, and according to >>> you guys' wiki I am supposed to submit a patch of what I've changed. >>> >>> So here it is (too long, used PasteBin) >>> >>> https://pastebin.anthonos.org/view/bb82ca07 >>> >>> Also, I am not sure if I would be fast enough to get them all done by >>> 1.7.34 (nearly two weeks apart?), so is it Okay for me to submit them >>> bit by bit, like this time, several hundred? There's still about 950 >>> left as I can see on POEdit - and I think I can push this to 100% after >>> my high school final four days later. >>> >>> Thanks everyone, Wine is AWESOME. >>> >>> Regards, >>> >>> Jeff Bai (白铭骢) >> >> Hi, Jeff. >> >> I think it's okay to submit full diff at once. But please avoid changing original messages like you do here (or maybe not you directly but poedit): >> >>> #: oleview.rc:121 >>> -msgid "" >>> -"Toggle the display of component categories that are not meant to be visible" >>> +msgid "Toggle the display of component categories that are not meant to be visible" >>> msgstr "切换隐藏组件类显示" >> >> So keep msgid part as it is and touch only msgstr part, this will also help reducing resulting diff. >> >> And once you fixed that you should send a patch to wine-patches(a)winehq.org as it says here http://wiki.winehq.org/SubmittingPatches.

1 0

setting break point in 16 bit Windows app
by Marius Cirsta 15 Dec '14

15 Dec '14

I'd like to use winedbg to set a break point in a 16 bit Windows app, to stop execution on some function call. From what I've read this is broken as of 2005 ( https://www.winehq.org/pipermail/wine-devel/2006-June/048343.html ). Has anything happened since ? I'm interested in getting this to work but it all depends on the effort involved. Can anyone provide an estimate as to how much work is needed ? Thanks.

1 0

Re: d3d9: Don't assert when apps pass in the wrong shader iface.
by Sebastian Lackner 15 Dec '14

15 Dec '14

On 15.12.2014 15:29, Michael Stefaniuc wrote: > Fixes a regression reported in > https://bugs.winehq.org/show_bug.cgi?id=37723 > --- > dlls/d3d9/shader.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3d9/shader.c b/dlls/d3d9/shader.c > index 0c2c881..9541028 100644 > --- a/dlls/d3d9/shader.c > +++ b/dlls/d3d9/shader.c > @@ -165,9 +165,8 @@ HRESULT vertexshader_init(struct d3d9_vertexshader *shader, struct d3d9_device * > > struct d3d9_vertexshader *unsafe_impl_from_IDirect3DVertexShader9(IDirect3DVertexShader9 *iface) > { > - if (!iface) > + if (!iface && iface->lpVtbl != &d3d9_vertexshader_vtbl) ^^^^ Shouldn't it be !iface || iface->lpVtbl != &d3d9_vertexshader_vtbl ? > return NULL; > - assert(iface->lpVtbl == &d3d9_vertexshader_vtbl); > > return impl_from_IDirect3DVertexShader9(iface); > } > @@ -315,9 +314,8 @@ HRESULT pixelshader_init(struct d3d9_pixelshader *shader, struct d3d9_device *de > > struct d3d9_pixelshader *unsafe_impl_from_IDirect3DPixelShader9(IDirect3DPixelShader9 *iface) > { > - if (!iface) > + if (!iface && iface->lpVtbl != &d3d9_pixelshader_vtbl) > return NULL; > - assert(iface->lpVtbl == &d3d9_pixelshader_vtbl); > > return impl_from_IDirect3DPixelShader9(iface); > } >

1 0

Re: zh_CN Translation Submittion
by Nikolay Sivov 15 Dec '14

15 Dec '14

On 15.12.2014 7:53, Jeff Bai wrote: > Hello, fellow developers. > > I've got several hundred strings translated to zh_CN, and according to > you guys' wiki I am supposed to submit a patch of what I've changed. > > So here it is (too long, used PasteBin) > > https://pastebin.anthonos.org/view/bb82ca07 > > Also, I am not sure if I would be fast enough to get them all done by > 1.7.34 (nearly two weeks apart?), so is it Okay for me to submit them > bit by bit, like this time, several hundred? There's still about 950 > left as I can see on POEdit - and I think I can push this to 100% after > my high school final four days later. > > Thanks everyone, Wine is AWESOME. > > Regards, > > Jeff Bai (白铭骢) > > > Hi, Jeff. I think it's okay to submit full diff at once. But please avoid changing original messages like you do here (or maybe not you directly but poedit): > #: oleview.rc:121 > -msgid "" > -"Toggle the display of component categories that are not meant to be visible" > +msgid "Toggle the display of component categories that are not meant to be visible" > msgstr "切换隐藏组件类显示" So keep msgid part as it is and touch only msgstr part, this will also help reducing resulting diff. And once you fixed that you should send a patch to wine-patches(a)winehq.org as it says here http://wiki.winehq.org/SubmittingPatches.

1 0

Re: ole32:fix CoWaitForMultipleHandles cause RPC hang
by Changhui Liu 15 Dec '14

15 Dec '14

Hi, I got it. The CoWaitForMultipleHandles of Microsoft implement is this: The message loop continue although has received WM_QUIT, but just dispatch message who sent to the OleMainThreadWndClass Window. I attached a latest patch and a verify function. Run the test_CoWaitForMultipleHandlesDispatchMsg, We will only get the message who send to cowait_test_class window . It also pass your PeekMessage test at: https://github.com/wine-compholio/wine-staging/blob/master/patches/ole32-Co… Please help me review it again when you are free. Thank you. ------------------ Regards. ------------------ Original ------------------ From: "Sebastian Lackner"<sebastian(a)fds-team.de>; Date: Sat, Dec 13, 2014 11:32 PM To: "Changhui Liu"<liuchanghui(a)linuxdeepin.com>; Cc: "wine-devel"<wine-devel(a)winehq.org>; Subject: Re: ole32:fix CoWaitForMultipleHandles cause RPC hang Hi, On 13.12.2014 16:15, Changhui Liu wrote: > Hi Sebastian, > > > I tested your current work-in-progress patch: > https://github.com/wine-compholio/wine-staging/blob/master/patches/ole32-Co… > > I have two puzzles about these code: >> index = 0xdeadbeef; >> PostMessageA(hWnd, WM_DDE_FIRST, 0, 0); >> PostQuitMessage(44); >> thread = CreateThread(NULL, 0, post_message_thread, hWnd, 0, &tid); >> ok(thread != NULL, "CreateThread failed, error %u\n", GetLastError()); >> hr = CoWaitForMultipleHandles(0, 100, 2, handles, &index); >> ok(hr == RPC_S_CALLPENDING, "expected RPC_S_CALLPENDING, got 0x%08x\n", hr); >> ok(index == 0 || broken(index == 0xdeadbeef) /* Win 8 */, "expected index 0, got %u\n", index); >> success = PeekMessageA(&msg, hWnd, WM_DDE_FIRST, WM_DDE_FIRST, PM_REMOVE); >> ok(success, "PeekMessageA failed, error %u\n", GetLastError()); > > > The first, why use the PeekMessage to check if received a WM_DDE_FIRST message? > Is there an real application do like that way? Of course there are multiple ways to test for window messages in the message queue, I just picked PeekMessageA because it doesn't require setting up a Wndproc. > > > In fact CoWaitForMultipleHandles has a message loop, the WM_DDE_FIRST message has been > dispatched to the window's WNDPROC. So the PeekMessageA certainly failed. No, it doesn't. Feel free to run the tests yourself on a Windows machine, I have tested them with the Wine testbot and all tests pass on 2000/XP/Vista/8/2008/... - which means that Windows does not process all WM_DDE_FIRST messages. This is also why I am unsure about how to fix it. When changing the behaviour in order to fix one of the tests which fails in Wine (marked with todo_wine), it breaks other tests which were working well before. > > > I think the correct test should be this: > 1, Define a custom WNDPROC function named cowait_test_wnd_proc . > 2, Define a global int variable named g_count_of_wm_dde_first. > 3, Set the value of g_count_of_wm_dde_first to zero before call CoWaitForMultipleHandles. > 4, Increase the value of g_count_of_wm_dde_first by one, once received a WM_DDE_FIRST message in cowait_test_wnd_proc. > 5, Check if the value of g_count_of_wm_dde_first is equal to 2 after CoWaitForMultipleHandles returned. > This testing method would also be fine, but you would get 1 instead of 2. My patch doesn't show any test failures on Windows, which means that one of the WM_DDE_FIRST messages is still in the queue. > > The second is why use todo_wine ? > todo_wine > ok(!success, "PeekMessageA succeeded\n"); > why not just write? > ok(!success, "PeekMessageA succeeded\n"); > The Wine coding guideline does not allow to add new test failures, instead all tests which do not pass yet have to be marked with "todo_wine". This makes easily visible which tests need further work just by looking at the source code, moreover it avoids introducing regressions (breaking tests which were working well before). Take a look at some of the other Wine tests, this is not the only place where its used. > > > > Thank you. Regards, Sebastian

1 1

Re: [1/2] jscript: Support PROPERTYGET in Date Value
by Jacek Caban 14 Dec '14

14 Dec '14

On 12/14/14 00:18, Alistair Leslie-Hughes wrote: > case INVOKE_PROPERTYGET: > + { > + DateInstance *date; > + > + if(!(date = date_this(jsthis))) > + return throw_type_error(ctx, JS_E_DATE_EXPECTED, NULL); It's guaranteed that jsthis is of DataInstance type in case of *_value functions, so there is no need to check that in runtime. You may simply cast it here. Jacek

1 0