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

Re: user32: If the listbox loses focus while holding capture, release it by essentially simulating a button up event.

by Nikolay Sivov

On 2/20/2014 16:01, Huw Davies wrote: > On Thu, Feb 20, 2014 at 03:46:26PM +0400, Nikolay Sivov wrote: >> On 2/20/2014 15:35, Huw Davies wrote: >>> --- >>> dlls/user32/listbox.c | 1 + >>> dlls/user32/tests/listbox.c | 30 ++++++++++++++++++++++++++++++ >>> 2 files changed, 31 insertions(+) >>> >>> case WM_KILLFOCUS: >>> + LISTBOX_HandleLButtonUp( descr ); /* Release capture if we have it */ >>> descr->in_focus = FALSE; >>> descr->wheel_remain = 0; >> This isn't totally correct. It's fine for when you press and hold >> left button and then change focus with Tab for example, >> LBN_SELCHANGE does indeed happen in this case. But when you just Tab >> away from a list with no mouse commands you shouldn't send >> LBN_SELCHANGE. > Right, LBN_SELCHANGE should only get sent if we release the capture. > Isn't that what this does? Yes, I tested it, looks fine. Sorry for a noise. > > Huw. >

Feb. 20, 2014

Re: [PATCH 2/2] oleaut32: Fix VariantCopy() for VT_RECORD variants (resent)

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > --- > dlls/oleaut32/tests/vartest.c | 46 ++++++++++++++++++++++--- > dlls/oleaut32/variant.c | 79 ++++++++++++++++++++----------------------- > 2 files changed, 79 insertions(+), 46 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M jscript.dll -p jscript_test.exe.so run && touch run.ok wine: Unhandled page fault on read access to 0x00000001 at address 0x686c7866 (thread 007f), starting debugger... Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x686c7866). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:686c7866 ESP:0032f6a0 EBP:0032f6d8 EFLAGS:00010202( R- -- I - - - ) EAX:0032f720 EBX:687a01ec ECX:0032f6f0 EDX:00000001 ESI:00000000 EDI:0032f720 Stack dump: 0x0032f6a0: 001d0ca8 000012e0 0032f6e8 686c6914 0x0032f6b0: 00000020 00000000 001d0da8 0032f758 0x0032f6c0: 4d430003 00000000 0032f6f0 687a01ec 0x0032f6d0: 558b6bc0 00000000 0032f748 686c8eed 0x0032f6e0: 00000018 00000000 00000000 686c8eed 0x0032f6f0: 003315c0 0032f720 00000080 0032f70c Backtrace: =>0 0x686c7866 SafeArrayGetRecordInfo+0x46(psa=<couldn't compute location>, pRinfo=<couldn't compute location>) [/home/julliard/wine/wine/dlls/oleaut32/../../include/oaidl.h:4140] in oleaut32 (0x0032f6d8) 1 0x686c8eed SAFEARRAY_CopyData+0x28c(psa=0x3315c0, dest=0x331e78) [/home/julliard/wine/wine/dlls/oleaut32/safearray.c:409] in oleaut32 (0x0032f748) 2 0x686c91e6 SafeArrayCopy+0x145(psa=<couldn't compute location>, ppsaOut=<couldn't compute location>) [/home/julliard/wine/wine/dlls/oleaut32/safearray.c:1409] in oleaut32 (0x0032f7a8) 3 0x5589c671 VBArrayConstr_value+0x140(ctx=0x1ba150, vthis=0x32f838, flags=0x4000, argc=0x1, argv=0x1e5b50, r=0x32fa38) [/home/julliard/wine/wine/dlls/jscript/vbarray.c:308] in jscript (0x0032f808) 4 0x5587810b invoke_value_proc.isra+0x6a() in jscript (0x0032f858) 5 0x55878a57 Function_invoke+0x66(func_this=0x1d0d60, jsthis=(nil), flags=0x4000, argc=0x1, argv=0x1e5b50, r=0x32fa38) [/home/julliard/wine/wine/dlls/jscript/function.c:351] in jscript (0x0032f8a8) 6 0x5586b089 jsdisp_call_value+0xd8(jsfunc=0x1d0d60, jsthis=(nil), flags=0x4000, argc=0x1, argv=0x1e5b50, r=0x32fa38) [/home/julliard/wine/wine/dlls/jscript/dispex.c:1061] in jscript (0x0032f8f8) 7 0x5586b1a1 disp_call_value+0xb0(ctx=0x1ba150, disp=0x1d0d60, jsthis=(nil), flags=0x4000, argc=0x1, argv=0x1e5b50, r=0x32fa38) [/home/julliard/wine/wine/dlls/jscript/dispex.c:1200] in jscript (0x0032f9f8) 8 0x5586ef84 interp_new+0xc3(ctx=<is not available>) [/home/julliard/wine/wine/dlls/jscript/engine.c:985] in jscript (0x0032fa58) 9 0x55874a94 exec_source+0x1e3(ctx=<is not available>, code=<is not available>, func=<is not available>, from_eval=<is not available>, ret=<is not available>) [/home/julliard/wine/wine/dlls/jscript/engine.c:2462] in jscript (0x0032fad8) 10 0x5587eb46 exec_global_code.isra+0x85() in jscript (0x0032fb18) 11 0x5587ee19 JScriptParse_ParseScriptText+0x2a8(iface=<couldn't compute location>, pstrCode=<couldn't compute location>, pstrItemName=<couldn't compute location>, punkContext=<couldn't compute location>, pstrDelimiter=<couldn't compute location>, dwSourceContextCookie=<couldn't compute location>, ulStartingLine=<couldn't compute location>, dwFlags=<couldn't compute location>, pvarResult=<couldn't compute location>, pexcepinfo=<couldn't compute location>) [/home/julliard/wine/wine/dlls/jscript/jscript.c:805] in jscript (0x0032fba8) -- Alexandre Julliard julliard(a)winehq.org

Feb. 20, 2014

Re: user32: If the listbox loses focus while holding capture, release it by essentially simulating a button up event.

by Huw Davies

On Thu, Feb 20, 2014 at 03:46:26PM +0400, Nikolay Sivov wrote: > On 2/20/2014 15:35, Huw Davies wrote: > >--- > > dlls/user32/listbox.c | 1 + > > dlls/user32/tests/listbox.c | 30 ++++++++++++++++++++++++++++++ > > 2 files changed, 31 insertions(+) > > > > case WM_KILLFOCUS: > >+ LISTBOX_HandleLButtonUp( descr ); /* Release capture if we have it */ > > descr->in_focus = FALSE; > > descr->wheel_remain = 0; > This isn't totally correct. It's fine for when you press and hold > left button and then change focus with Tab for example, > LBN_SELCHANGE does indeed happen in this case. But when you just Tab > away from a list with no mouse commands you shouldn't send > LBN_SELCHANGE. Right, LBN_SELCHANGE should only get sent if we release the capture. Isn't that what this does? Huw.

Feb. 20, 2014

Re: user32: If the listbox loses focus while holding capture, release it by essentially simulating a button up event.

by Nikolay Sivov

On 2/20/2014 15:35, Huw Davies wrote: > --- > dlls/user32/listbox.c | 1 + > dlls/user32/tests/listbox.c | 30 ++++++++++++++++++++++++++++++ > 2 files changed, 31 insertions(+) > > case WM_KILLFOCUS: > + LISTBOX_HandleLButtonUp( descr ); /* Release capture if we have it */ > descr->in_focus = FALSE; > descr->wheel_remain = 0; This isn't totally correct. It's fine for when you press and hold left button and then change focus with Tab for example, LBN_SELCHANGE does indeed happen in this case. But when you just Tab away from a list with no mouse commands you shouldn't send LBN_SELCHANGE.

Feb. 20, 2014

Re: [PATCH 2/2] oleaut32: Fix VariantCopy() for VT_RECORD variants (resent)

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://newtestbot.winehq.org/JobDetails.pl?Key=5039 Your paranoid android. === wvistau64 (64 bit vartest) === No test summary line found === w2008s64 (64 bit vartest) === No test summary line found === w7pro64 (64 bit vartest) === No test summary line found

Feb. 20, 2014

Re: [PATCH 1/2] oleaut32/tests: Test for VariantClear() on VT_RECORD variant (try2)

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://newtestbot.winehq.org/JobDetails.pl?Key=5038 Your paranoid android. === wvistau64 (64 bit vartest) === No test summary line found === w2008s64 (64 bit vartest) === No test summary line found === w7pro64 (64 bit vartest) === No test summary line found

Feb. 20, 2014

Re: msi: Dont crash on installation of services without component KeyPath

by Dmitry Timoshkov

Francois Gouget <fgouget(a)codeweavers.com> wrote: > You're in luck then. The new testbot now has a Windows 2000 VM... Probably it's time then to make testbot process the tasks slightly faster, currently it's speed is completely unacceptable. For that reason I was using old testbot instead, but since it's no longer available this creates additional problems and prevents productive work. -- Dmitry.

Feb. 20, 2014

Re: [idea]wine support for Chrome OS

by 中川祥

So,you think wine behaves as if runnig vulnerable code itself? Like the oldest Java did? Then as the latest Java does,compile windows code to Linux .so files, and NaCl scans it. 2014-02-20 1:06 GMT+09:00 Vincent Povirk <madewokherd(a)gmail.com>: > I don't think it's possible for existing Windows code to run in Native > Client. As I understand it, NaCl verifies all x86 code to make sure > it's safe before executing it, and Wine needs to load x86 code > compiled for Windows directly, which will not be using the safe subset > of x86 that NaCl requires. > > One would need a proper virtual machine to make that work, something > like qemu perhaps. > > However, the pipelight project may be interested in support for PPAPI. >

Feb. 20, 2014

Re: [PATCH 2/2] oleaut32: Fix VariantCopy() for VT_RECORD variants

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://newtestbot.winehq.org/JobDetails.pl?Key=5036 Your paranoid android. === wvistau64 (64 bit vartest) === No test summary line found === w2008s64 (64 bit vartest) === No test summary line found === w7pro64 (64 bit vartest) === No test summary line found

Feb. 20, 2014

Re: [1/2] shell32: Correct create flags when SEE_MASK_NO_CONSOLE isn't specified (resend)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi Alexandre, > > On 20/02/2014 3:31 AM, Alexandre Julliard wrote: >> There's more to it than that, now it's popping up consoles all over the >> place during make test. >> > When I ran the test on windows consoles popup all over the place so > how is it different to WINE? Well, the test should be fixed to use SEE_MASK_NO_CONSOLE, and then you get no consoles on Windows but you still get them on Wine. -- Alexandre Julliard julliard(a)winehq.org

Feb. 20, 2014

Re: [PATCH 1/2] oleaut32/tests: Test for VariantClear() on VT_RECORD variant

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://newtestbot.winehq.org/JobDetails.pl?Key=5035 Your paranoid android. === wvistau64 (64 bit vartest) === No test summary line found === w2008s64 (64 bit vartest) === No test summary line found === w7pro64 (64 bit vartest) === No test summary line found

Feb. 20, 2014

Re: msi: Dont crash on installation of services without component KeyPath

by Francois Gouget

On Thu, 20 Feb 2014, Aric Stewart wrote: [...] > Unfortunately it only tries to install the service on windows 2000 or > older. (this is an old applications that I was installing in a windows > 2000 prefix) I do not have a windows 2000 machine to test the install > on. You're in luck then. The new testbot now has a Windows 2000 VM... -- Francois Gouget <fgouget(a)codeweavers.com>

Feb. 20, 2014

Re: [1/2] shell32: Correct create flags when SEE_MASK_NO_CONSOLE isn't specified (resend)

by Alistair Leslie-Hughes

Hi Alexandre, On 20/02/2014 3:31 AM, Alexandre Julliard wrote: > There's more to it than that, now it's popping up consoles all over the > place during make test. > When I ran the test on windows consoles popup all over the place so how is it different to WINE? Are the consoles not closing? Best Regards Alistair Leslie-Hughes

Feb. 20, 2014

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries

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://newtestbot.winehq.org/JobDetails.pl?Key=5034 Your paranoid android. === build (build) === Patch failed to apply

Feb. 20, 2014

Re: (try 3)winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 20, 2014, at 12:28 AM, Aric Stewart wrote: > --- > dlls/winemac.drv/ime.c | 15 +++++---------- > 1 file changed, 5 insertions(+), 10 deletions(-) Looks good to me. -Ken

Feb. 20, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 14:22, Ken Thomases wrote: > On Feb 19, 2014, at 11:19 PM, Aric Stewart wrote: > >> On 2014/02/20 14:14, Ken Thomases wrote: >>> On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: >>> >>>> + gti.rcCaret.right = gti.rcCaret.left + 1; >>> >>> Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) >>> >>> Otherwise, this looks good to me. >>> >> No strong reason other than to have a known width, as the mac at least appears to center the candidate window above/below the point. >> >> I can leave the returned width if you feel that to be better. > > Do you have the ability to test an input method with right-to-left input with an app that's known to use this code path? Also, have you inspected the caret width to know if it's supplying a sensible width? I have failed to find a right-to-left input method that makes use of the candidate window stuff. So I have not been able to investigate that. The caret window size does appear to be pretty logical. (always about 1 pixel but still logical) I was just not relying on it, mostly because of the comment in the MSDN page that made me worry that it could potentially be an invalid rect (right side less than left) in some cases. But rereading it I do not thing that is what is being implied. I also never saw that to be the case. -aric

Feb. 19, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 11:19 PM, Aric Stewart wrote: > On 2014/02/20 14:14, Ken Thomases wrote: >> On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: >> >>> + gti.rcCaret.right = gti.rcCaret.left + 1; >> >> Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) >> >> Otherwise, this looks good to me. >> > No strong reason other than to have a known width, as the mac at least appears to center the candidate window above/below the point. > > I can leave the returned width if you feel that to be better. Do you have the ability to test an input method with right-to-left input with an app that's known to use this code path? Also, have you inspected the caret width to know if it's supplying a sensible width? -Ken

Feb. 19, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 14:14, Ken Thomases wrote: > On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: > >> + gti.rcCaret.right = gti.rcCaret.left + 1; > > Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) > > Otherwise, this looks good to me. > No strong reason other than to have a known width, as the mac at least appears to center the candidate window above/below the point. I can leave the returned width if you feel that to be better. -aric

Feb. 19, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: > + gti.rcCaret.right = gti.rcCaret.left + 1; Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) Otherwise, this looks good to me. -Ken

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 12:12, Ken Thomases wrote: > On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: > >> GetGUIThreadInfo is totally the correct way to go. It is giving me correct caret rects for both notepad and the Japanese applications I am trying to fix. I can worry less about the not about caret insertion points because i do not care about the width, just the height and position. so a width of 1 is fine. > > Well the note wasn't about the caret width, it was about the proper computation of the left edge. According to MSDN, rcCaret.left is not correct as given. As I said, though, I'm not sure Wine is doing the right thing with that, anyway. The problem may only show up with right-to-left or Thai input. *shrug* > True, but I am not really worried about the insertion point to that degree of accuracy. Just the location of the cursor itself and the height. Both of which appear to be correct. Thanks for the tip on this. -aric

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: > GetGUIThreadInfo is totally the correct way to go. It is giving me correct caret rects for both notepad and the Japanese applications I am trying to fix. I can worry less about the not about caret insertion points because i do not care about the width, just the height and position. so a width of 1 is fine. Well the note wasn't about the caret width, it was about the proper computation of the left edge. According to MSDN, rcCaret.left is not correct as given. As I said, though, I'm not sure Wine is doing the right thing with that, anyway. The problem may only show up with right-to-left or Thai input. *shrug* Anyway, glad it's giving useful results. -Ken

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 7:46, Ken Thomases wrote: > On Feb 19, 2014, at 4:19 PM, Aric Stewart wrote: > >> humm, so how should i determine line height? > > I don't think you can. It's not a well-formed concept. Windows don't have any inherent line height property (directly or indirectly). > > Have you tried the GetGUIThreadInfo() approach and rcCaret? You're trying to fix the case when using GetCaretPos() but maybe we shouldn't be using that. > > If you're thinking forward to IMC_SETCANDIDATEPOS, then a horrible kludge might be to return a rect whose bottom left is at the specified point and which extends up and to the right to the screen boundaries. The idea is to try to make the input method position its candidate window so its top-left is at the specified point. It will likely align its left side with the left side of the character rect we return (for left-to-right languages, at least) and, by taking up the area of the screen above and to the right of that point, you force the candidate window to be below the rect. > > -Ken > GetGUIThreadInfo is totally the correct way to go. It is giving me correct caret rects for both notepad and the Japanese applications I am trying to fix. I can worry less about the not about caret insertion points because i do not care about the width, just the height and position. so a width of 1 is fine. I will resubmit the patch with this logic. Thanks! -aric

Feb. 19, 2014

Re: [PATCH 8/8] ddraw/tests: Test that DirectDraw doesn't modify the pixel format of the window it targets. (try 2, resend)

by Ken Thomases

On Feb 19, 2014, at 7:22 PM, Marvin wrote: > === w2000pro (32 bit ddraw2) === > ddraw2.c:2405: Test failed: SetDisplayMode failed, hr 0x80004001. > … > > === w8 (32 bit ddraw2) === > No test summary line found > Failure running script in VM: network read timed out > > === w2000pro (32 bit ddraw1) === > ddraw1.c:2194: Test failed: SetDisplayMode failed, hr 0x80004001. > … > > === w8 (32 bit ddraw1) === > ddraw1.c:4115: Test failed: Got unexpected refcount 3. > … > > === w2000pro (32 bit ddraw7) === > ddraw7.c:2255: Test failed: SetDisplayMode failed, hr 0x80004001. > … > > === w8 (32 bit ddraw7) === > Timeout > Failure running script in VM: network read timed out > > === w2000pro (32 bit ddraw4) === > ddraw4.c:2529: Test failed: SetDisplayMode failed, hr 0x80004001. > … > > === w8 (32 bit ddraw4) === > Failure running script in VM: timed out waiting for the child process Not related to my patch. -Ken

Feb. 19, 2014

Re: [PATCH 7/8] d3d8/tests: Test that Direct3D8 doesn't modify the pixel format of the window it targets. (try 2, resend)

by Ken Thomases

On Feb 19, 2014, at 6:20 PM, Marvin wrote: > === w8 (32 bit device) === > device.c:2572: Test failed: Expected foreground window 00030180, got 00010048. > device.c:3268: Test failed: Expected wndproc 0x410530, got 0x410530. Not related to my patch. -Ken

Feb. 19, 2014

Re: [PATCH 6/8] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4, resend)

by Ken Thomases

On Feb 19, 2014, at 6:07 PM, Marvin wrote: > === w2000pro (32 bit device) === > device.c:321: Test failed: Failed to create IDirect3D9Device (8876086c) > device.c:494: Test failed: Failed to create IDirect3D9Device (8876086c) > device.c:209: Test failed: Failed to create IDirect3D9Device (8876086c) > device.c:257: Test failed: Failed to create IDirect3D9Device (8876086c) > device.c:815: Test failed: Failed to create IDirect3D9Device (8876086c) > device.c:1484: Test failed: IDirect3D9_CreateDevice failed with 8876086c > device.c:1642: Test failed: IDirect3D9_CreateDevice failed with 8876086c > device.c:1715: Test failed: IDirect3D9_CreateDevice failed with 8876086c > device.c:2063: Test failed: IDirect3D9_CreateDevice failed with 8876086c Not related to my patch. -Ken

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 7:46, Ken Thomases wrote: > On Feb 19, 2014, at 4:19 PM, Aric Stewart wrote: > >> humm, so how should i determine line height? > > I don't think you can. It's not a well-formed concept. Windows don't have any inherent line height property (directly or indirectly). > > Have you tried the GetGUIThreadInfo() approach and rcCaret? You're trying to fix the case when using GetCaretPos() but maybe we shouldn't be using that. > > If you're thinking forward to IMC_SETCANDIDATEPOS, then a horrible kludge might be to return a rect whose bottom left is at the specified point and which extends up and to the right to the screen boundaries. The idea is to try to make the input method position its candidate window so its top-left is at the specified point. It will likely align its left side with the left side of the character rect we return (for left-to-right languages, at least) and, by taking up the area of the screen above and to the right of that point, you force the candidate window to be below the rect. I am thinking forward to the IMC_SETCANDIDATEPOS implementation, but on the way found that our caret pos version was seriously bad and was working on that first. The issue with simply kludging the rect like that is that it appears that the caret position that we are given is in the middle of the line (not the bottom where it would be useful) so we end up clipping the bottom half of the composition string with the selection dialog. Again lending to the need to be able to at least guess at a line height to shift the box down by. -aric

Feb. 19, 2014

Re: msi: Dont crash on installation of services without component KeyPath

by Aric Stewart

On 2014/02/19 20:28, Hans Leidekker wrote: > On Wed, 2014-02-19 at 20:03 +0900, Aric Stewart wrote: >> I have not dug into the details, but I know it does not crash and the >> overall install does succeed. >> >> I can try investigating further on windows, Is there an easy way to >> determine what service this is and if it gets successfully installed on windows? > > A +msi,+service trace should reveal the service name. "sc query" will list > installed services, for example. > Unfortunately it only tries to install the service on windows 2000 or older. (this is an old applications that I was installing in a windows 2000 prefix) I do not have a windows 2000 machine to test the install on. Using an XP prefix gets around the problem by not trying to install the service. But I am unable to determine what is the correct method to fix this issue. You are more of the expert Hans, so I will leave it up to you if we should fail to install the service or install the service without an image path. -aric

Feb. 19, 2014

Re: [PATCH 8/8] ddraw/tests: Test that DirectDraw doesn't modify the pixel format of the window it targets. (try 2, resend)

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://newtestbot.winehq.org/JobDetails.pl?Key=5032 Your paranoid android. === w2000pro (32 bit ddraw2) === ddraw2.c:2405: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2407: Test failed: Expected message 0x46, but didn't receive it. ddraw2.c:2409: Test failed: Expected screen size 640x480, got 0x0. ddraw2.c:2414: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw2.c:2435: Test failed: Expected surface width 640, got 1024. ddraw2.c:2437: Test failed: Expected surface height 480, got 768. ddraw2.c:2441: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw2.c:2452: Test failed: Expected message 0x46, but didn't receive it. ddraw2.c:2454: Test failed: Expected screen size 1024x768, got 0x0. ddraw2.c:2465: Test failed: Expected surface width 640, got 1024. ddraw2.c:2467: Test failed: Expected surface height 480, got 768. ddraw2.c:2530: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2540: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2566: Test failed: Expected surface width 640, got 1024. ddraw2.c:2568: Test failed: Expected surface height 480, got 768. ddraw2.c:2583: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2594: Test failed: Expected surface width 640, got 1024. ddraw2.c:2596: Test failed: Expected surface height 480, got 768. ddraw2.c:2662: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2664: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2690: Test failed: Expected surface width 640, got 1024. ddraw2.c:2692: Test failed: Expected surface height 480, got 768. ddraw2.c:2707: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2718: Test failed: Expected surface width 640, got 1024. ddraw2.c:2720: Test failed: Expected surface height 480, got 768. ddraw2.c:2748: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2757: Test failed: Expected message 0x5, but didn't receive it. ddraw2.c:2759: Test failed: Expected screen size 1024x768, got 0x0. ddraw2.c:2787: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2801: Test failed: Expected surface width 640, got 1024. ddraw2.c:2803: Test failed: Expected surface height 480, got 768. ddraw2.c:2814: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2825: Test failed: Expected message 0x5, but didn't receive it. ddraw2.c:2829: Test failed: Expected screen size 2 1024x768, got 0x0. ddraw2.c:2834: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw2.c:2838: Test failed: Expected {0, 0, 1024, 768}, got {0, 0, 112, 100}. ddraw2.c:2861: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw2.c:2896: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2906: Test failed: Got unexpected screen width 1024. ddraw2.c:2908: Test failed: Got unexpected screen height 768. ddraw2.c:2921: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2923: Test failed: Got unexpected screen width 1024. ddraw2.c:2925: Test failed: Got unexpected screen height 768. ddraw2.c:2929: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2931: Test failed: Got unexpected screen width 1024. ddraw2.c:2933: Test failed: Got unexpected screen height 768. ddraw2.c:2952: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2954: Test failed: Got unexpected screen width 1024. ddraw2.c:2956: Test failed: Got unexpected screen height 768. ddraw2.c:2960: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2962: Test failed: Got unexpected screen width 1024. ddraw2.c:2964: Test failed: Got unexpected screen height 768. ddraw2.c:2984: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:2986: Test failed: Got unexpected screen width 1024. ddraw2.c:2988: Test failed: Got unexpected screen height 768. ddraw2.c:2993: Test failed: Got unexpected screen width 1024. ddraw2.c:2995: Test failed: Got unexpected screen height 768. ddraw2.c:3008: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3010: Test failed: Got unexpected screen width 1024. ddraw2.c:3012: Test failed: Got unexpected screen height 768. ddraw2.c:3016: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3018: Test failed: Got unexpected screen width 1024. ddraw2.c:3020: Test failed: Got unexpected screen height 768. ddraw2.c:3028: Test failed: Got unexpected screen width 1024. ddraw2.c:3030: Test failed: Got unexpected screen height 768. ddraw2.c:3042: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3044: Test failed: Got unexpected screen width 1024. ddraw2.c:3046: Test failed: Got unexpected screen height 768. ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3277: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3290: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3306: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:3325: Test failed: Display mode restored after ddraw1-ddraw2 SetCooperativeLevel() call sequence ddraw2.c:3231: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw2.c:4536: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:4754: Test failed: Failed to create surface, hr 0x88760091. ddraw2: unhandled exception c0000005 at 00426825 === w8 (32 bit ddraw2) === No test summary line found Failure running script in VM: network read timed out === w2000pro (32 bit ddraw1) === ddraw1.c:2194: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2196: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2198: Test failed: Expected screen size 640x480, got 0x0. ddraw1.c:2203: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw1.c:2224: Test failed: Expected surface width 640, got 1024. ddraw1.c:2226: Test failed: Expected surface height 480, got 768. ddraw1.c:2230: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw1.c:2241: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2243: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2254: Test failed: Expected surface width 640, got 1024. ddraw1.c:2256: Test failed: Expected surface height 480, got 768. ddraw1.c:2319: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2329: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2355: Test failed: Expected surface width 640, got 1024. ddraw1.c:2357: Test failed: Expected surface height 480, got 768. ddraw1.c:2372: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2383: Test failed: Expected surface width 640, got 1024. ddraw1.c:2385: Test failed: Expected surface height 480, got 768. ddraw1.c:2451: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2453: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2479: Test failed: Expected surface width 640, got 1024. ddraw1.c:2481: Test failed: Expected surface height 480, got 768. ddraw1.c:2496: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2507: Test failed: Expected surface width 640, got 1024. ddraw1.c:2509: Test failed: Expected surface height 480, got 768. ddraw1.c:2537: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2551: Test failed: Expected surface width 640, got 1024. ddraw1.c:2553: Test failed: Expected surface height 480, got 768. ddraw1.c:2563: Test failed: Expected {0, 0, 1024, 768}, got {0, 0, 1024, 768}. ddraw1.c:2596: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2606: Test failed: Got unexpected screen width 1024. ddraw1.c:2608: Test failed: Got unexpected screen height 768. ddraw1.c:2621: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2623: Test failed: Got unexpected screen width 1024. ddraw1.c:2625: Test failed: Got unexpected screen height 768. ddraw1.c:2629: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2631: Test failed: Got unexpected screen width 1024. ddraw1.c:2633: Test failed: Got unexpected screen height 768. ddraw1.c:2652: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2654: Test failed: Got unexpected screen width 1024. ddraw1.c:2656: Test failed: Got unexpected screen height 768. ddraw1.c:2660: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2662: Test failed: Got unexpected screen width 1024. ddraw1.c:2664: Test failed: Got unexpected screen height 768. ddraw1.c:2684: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2686: Test failed: Got unexpected screen width 1024. ddraw1.c:2688: Test failed: Got unexpected screen height 768. ddraw1.c:2693: Test failed: Got unexpected screen width 1024. ddraw1.c:2695: Test failed: Got unexpected screen height 768. ddraw1.c:2708: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2710: Test failed: Got unexpected screen width 1024. ddraw1.c:2712: Test failed: Got unexpected screen height 768. ddraw1.c:2716: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2718: Test failed: Got unexpected screen width 1024. ddraw1.c:2720: Test failed: Got unexpected screen height 768. ddraw1.c:2728: Test failed: Got unexpected screen width 1024. ddraw1.c:2730: Test failed: Got unexpected screen height 768. ddraw1.c:2742: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw1.c:2744: Test failed: Got unexpected screen width 1024. ddraw1.c:2746: Test failed: Got unexpected screen height 768. ddraw1.c:3855: Test failed: Failed to set display mode, hr 0x80004001. === w8 (32 bit ddraw1) === ddraw1.c:4115: Test failed: Got unexpected refcount 3. ddraw1.c:4134: Test failed: Got unexpected refcount 3. ddraw1.c:4141: Test failed: Got unexpected hr 0. ddraw1.c:4144: Test failed: Got unexpected refcount 3. ddraw1.c:4146: Test failed: Got unexpected refcount 2. ddraw1.c:4152: Test failed: Got unexpected hr 0. ddraw1.c:4155: Test failed: Got unexpected refcount 2. ddraw1.c:4157: Test failed: Got unexpected refcount 1. === w2000pro (32 bit ddraw7) === ddraw7.c:2255: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2257: Test failed: Expected message 0x46, but didn't receive it. ddraw7.c:2259: Test failed: Expected screen size 640x480, got 0x0. ddraw7.c:2264: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw7.c:2285: Test failed: Expected surface width 640, got 1024. ddraw7.c:2287: Test failed: Expected surface height 480, got 768. ddraw7.c:2291: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw7.c:2302: Test failed: Expected message 0x46, but didn't receive it. ddraw7.c:2304: Test failed: Expected screen size 1024x768, got 0x0. ddraw7.c:2315: Test failed: Expected surface width 640, got 1024. ddraw7.c:2317: Test failed: Expected surface height 480, got 768. ddraw7.c:2380: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2382: Test failed: Expected message 0x7e, but didn't receive it. ddraw7.c:2408: Test failed: Expected surface width 640, got 1024. ddraw7.c:2410: Test failed: Expected surface height 480, got 768. ddraw7.c:2425: Test failed: Expected message 0x7e, but didn't receive it. ddraw7.c:2436: Test failed: Expected surface width 640, got 1024. ddraw7.c:2438: Test failed: Expected surface height 480, got 768. ddraw7.c:2504: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2506: Test failed: Expected message 0x7e, but didn't receive it. ddraw7.c:2532: Test failed: Expected surface width 640, got 1024. ddraw7.c:2534: Test failed: Expected surface height 480, got 768. ddraw7.c:2549: Test failed: Expected message 0x7e, but didn't receive it. ddraw7.c:2560: Test failed: Expected surface width 640, got 1024. ddraw7.c:2562: Test failed: Expected surface height 480, got 768. ddraw7.c:2590: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2599: Test failed: Expected message 0x5, but didn't receive it. ddraw7.c:2601: Test failed: Expected screen size 1024x768, got 0x0. ddraw7.c:2629: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2643: Test failed: Expected surface width 640, got 1024. ddraw7.c:2645: Test failed: Expected surface height 480, got 768. ddraw7.c:2656: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2667: Test failed: Expected message 0x5, but didn't receive it. ddraw7.c:2671: Test failed: Expected screen size 2 1024x768, got 0x0. ddraw7.c:2676: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw7.c:2680: Test failed: Expected {0, 0, 1024, 768}, got {0, 0, 112, 100}. ddraw7.c:2703: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw7.c:2737: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2739: Test failed: Got unexpected screen width 1024. ddraw7.c:2741: Test failed: Got unexpected screen height 768. ddraw7.c:2754: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2756: Test failed: Got unexpected screen width 1024. ddraw7.c:2758: Test failed: Got unexpected screen height 768. ddraw7.c:2762: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2764: Test failed: Got unexpected screen width 1024. ddraw7.c:2766: Test failed: Got unexpected screen height 768. ddraw7.c:2785: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2787: Test failed: Got unexpected screen width 1024. ddraw7.c:2789: Test failed: Got unexpected screen height 768. ddraw7.c:2793: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2795: Test failed: Got unexpected screen width 1024. ddraw7.c:2797: Test failed: Got unexpected screen height 768. ddraw7.c:2817: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2819: Test failed: Got unexpected screen width 1024. ddraw7.c:2821: Test failed: Got unexpected screen height 768. ddraw7.c:2826: Test failed: Got unexpected screen width 1024. ddraw7.c:2828: Test failed: Got unexpected screen height 768. ddraw7.c:2841: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2843: Test failed: Got unexpected screen width 1024. ddraw7.c:2845: Test failed: Got unexpected screen height 768. ddraw7.c:2849: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2851: Test failed: Got unexpected screen width 1024. ddraw7.c:2853: Test failed: Got unexpected screen height 768. ddraw7.c:2861: Test failed: Got unexpected screen width 1024. ddraw7.c:2863: Test failed: Got unexpected screen height 768. ddraw7.c:2875: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:2877: Test failed: Got unexpected screen width 1024. ddraw7.c:2879: Test failed: Got unexpected screen height 768. ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:3231: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:3244: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:3260: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:3279: Test failed: Display mode restored after ddraw1-ddraw7 SetCooperativeLevel() call sequence ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw7.c:5017: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:5236: Test failed: Failed to create surface, hr 0x88760091. ddraw7: unhandled exception c0000005 at 0045BF78 === w8 (32 bit ddraw7) === Timeout Failure running script in VM: network read timed out === w2000pro (32 bit ddraw4) === ddraw4.c:2529: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:2531: Test failed: Expected message 0x46, but didn't receive it. ddraw4.c:2533: Test failed: Expected screen size 640x480, got 0x0. ddraw4.c:2538: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw4.c:2559: Test failed: Expected surface width 640, got 1024. ddraw4.c:2561: Test failed: Expected surface height 480, got 768. ddraw4.c:2565: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw4.c:2576: Test failed: Expected message 0x46, but didn't receive it. ddraw4.c:2578: Test failed: Expected screen size 1024x768, got 0x0. ddraw4.c:2589: Test failed: Expected surface width 640, got 1024. ddraw4.c:2591: Test failed: Expected surface height 480, got 768. ddraw4.c:2654: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:2656: Test failed: Expected message 0x7e, but didn't receive it. ddraw4.c:2682: Test failed: Expected surface width 640, got 1024. ddraw4.c:2684: Test failed: Expected surface height 480, got 768. ddraw4.c:2699: Test failed: Expected message 0x7e, but didn't receive it. ddraw4.c:2710: Test failed: Expected surface width 640, got 1024. ddraw4.c:2712: Test failed: Expected surface height 480, got 768. ddraw4.c:2778: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:2780: Test failed: Expected message 0x7e, but didn't receive it. ddraw4.c:2806: Test failed: Expected surface width 640, got 1024. ddraw4.c:2808: Test failed: Expected surface height 480, got 768. ddraw4.c:2823: Test failed: Expected message 0x7e, but didn't receive it. ddraw4.c:2834: Test failed: Expected surface width 640, got 1024. ddraw4.c:2836: Test failed: Expected surface height 480, got 768. ddraw4.c:2864: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:2873: Test failed: Expected message 0x5, but didn't receive it. ddraw4.c:2875: Test failed: Expected screen size 1024x768, got 0x0. ddraw4.c:2903: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:2917: Test failed: Expected surface width 640, got 1024. ddraw4.c:2919: Test failed: Expected surface height 480, got 768. ddraw4.c:2930: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:2941: Test failed: Expected message 0x5, but didn't receive it. ddraw4.c:2945: Test failed: Expected screen size 2 1024x768, got 0x0. ddraw4.c:2950: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw4.c:2954: Test failed: Expected {0, 0, 1024, 768}, got {0, 0, 112, 100}. ddraw4.c:2977: Test failed: Expected {0, 0, 640, 480}, got {0, 0, 1024, 768}. ddraw4.c:3011: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3013: Test failed: Got unexpected screen width 1024. ddraw4.c:3015: Test failed: Got unexpected screen height 768. ddraw4.c:3028: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3030: Test failed: Got unexpected screen width 1024. ddraw4.c:3032: Test failed: Got unexpected screen height 768. ddraw4.c:3036: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3038: Test failed: Got unexpected screen width 1024. ddraw4.c:3040: Test failed: Got unexpected screen height 768. ddraw4.c:3059: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3061: Test failed: Got unexpected screen width 1024. ddraw4.c:3063: Test failed: Got unexpected screen height 768. ddraw4.c:3067: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3069: Test failed: Got unexpected screen width 1024. ddraw4.c:3071: Test failed: Got unexpected screen height 768. ddraw4.c:3091: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3093: Test failed: Got unexpected screen width 1024. ddraw4.c:3095: Test failed: Got unexpected screen height 768. ddraw4.c:3100: Test failed: Got unexpected screen width 1024. ddraw4.c:3102: Test failed: Got unexpected screen height 768. ddraw4.c:3115: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3117: Test failed: Got unexpected screen width 1024. ddraw4.c:3119: Test failed: Got unexpected screen height 768. ddraw4.c:3123: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3125: Test failed: Got unexpected screen width 1024. ddraw4.c:3127: Test failed: Got unexpected screen height 768. ddraw4.c:3135: Test failed: Got unexpected screen width 1024. ddraw4.c:3137: Test failed: Got unexpected screen height 768. ddraw4.c:3149: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3151: Test failed: Got unexpected screen width 1024. ddraw4.c:3153: Test failed: Got unexpected screen height 768. ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3508: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3521: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3537: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:3556: Test failed: Display mode restored after ddraw1-ddraw4 SetCooperativeLevel() call sequence ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001. ddraw4.c:5139: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:5358: Test failed: Failed to create surface, hr 0x88760091. ddraw4: unhandled exception c0000005 at 00440B85 === w8 (32 bit ddraw4) === Failure running script in VM: timed out waiting for the child process

Feb. 19, 2014

Re: [PATCH 7/8] d3d8/tests: Test that Direct3D8 doesn't modify the pixel format of the window it targets. (try 2, resend)

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://newtestbot.winehq.org/JobDetails.pl?Key=5031 Your paranoid android. === w8 (32 bit device) === device.c:2572: Test failed: Expected foreground window 00030180, got 00010048. device.c:3268: Test failed: Expected wndproc 0x410530, got 0x410530.

Feb. 19, 2014

Re: [PATCH 6/8] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4, resend)

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://newtestbot.winehq.org/JobDetails.pl?Key=5030 Your paranoid android. === w2000pro (32 bit device) === device.c:321: Test failed: Failed to create IDirect3D9Device (8876086c) device.c:494: Test failed: Failed to create IDirect3D9Device (8876086c) device.c:209: Test failed: Failed to create IDirect3D9Device (8876086c) device.c:257: Test failed: Failed to create IDirect3D9Device (8876086c) device.c:815: Test failed: Failed to create IDirect3D9Device (8876086c) device.c:1484: Test failed: IDirect3D9_CreateDevice failed with 8876086c device.c:1642: Test failed: IDirect3D9_CreateDevice failed with 8876086c device.c:1715: Test failed: IDirect3D9_CreateDevice failed with 8876086c device.c:2063: Test failed: IDirect3D9_CreateDevice failed with 8876086c

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 4:19 PM, Aric Stewart wrote: > humm, so how should i determine line height? I don't think you can. It's not a well-formed concept. Windows don't have any inherent line height property (directly or indirectly). Have you tried the GetGUIThreadInfo() approach and rcCaret? You're trying to fix the case when using GetCaretPos() but maybe we shouldn't be using that. If you're thinking forward to IMC_SETCANDIDATEPOS, then a horrible kludge might be to return a rect whose bottom left is at the specified point and which extends up and to the right to the screen boundaries. The idea is to try to make the input method position its candidate window so its top-left is at the specified point. It will likely align its left side with the left side of the character rect we return (for left-to-right languages, at least) and, by taking up the area of the screen above and to the right of that point, you force the candidate window to be below the rect. -Ken

Feb. 19, 2014

FFE (force feedback) file format reverse engineered

by Elias Vanderstuyft

Hi, Two weeks ago, I started working on reverse engineering the FFE file format, because the functionality to load and write is currently not available in Wine: http://wiki.winehq.org/ForceFeedbackSummerOfCode2005Summary " Missing functionality: - Reading and writing FF effects to files (IDirectInputDevice8::WriteEffectToFile and IDirectInputDevice8::EnumEffectsInFile) have not been implemented. They are stored in a RIFF file, the details of which are undocumented. Given the nature of RIFF, it should be relatively simple (albeit time-consuming) to determine the exact format of the effect files. " So I wrote a Python program that can read and validate FFE files, based on my assumption of the file format structure. In the Python file: - I tried to maximally expose the relation of the FFE file contents and the RIFF structure. - Every single bit in the FFE file will be tested/validated, and the program will throw a 'Warning' when something odd/against my assumptions, occurred with the file of interest. I did not yet implement write functionality in the Python file, but it should not be difficult (~inverse operation of read). For the CustomForce effect, my assumptions are hypothetical: there was no way to test it, because: - I did not find any file containing such effect - I couldn't create such file, because FEdit.exe does not support CustomForce effects to be created. This should be a starting point to implement these read and write stubs in Wine. I don't have time to do that now, so, maybe someone else is interested to do so? Any feedback is welcome, Best regards, Elias

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 6:57, Ken Thomases wrote: > On Feb 19, 2014, at 3:42 PM, Aric Stewart wrote: > >> On 2014/02/20 0:32, Ken Thomases wrote: >>> I don't think this does what you want. GetDC() typically returns a DC whose parameters were reset. It doesn't know what font has previously been used in the window. So, you're basically getting the metrics for the System font. I suppose that may be better than nothing. >> >> I never knew that about GetDC, I did not see anything about reset parameters in MSDN. > > It's the first paragraph of the Remarks. <http://msdn.microsoft.com/en-us/library/windows/desktop/dd144871%28v=vs.85%…> Don't be confused by the last sentence with its mention of GetTextFace(). That's not a solution to the problem described in the rest of the paragraph; it's a non sequitur. > >> It was working for me pretty accurately in my testing even with different fonts. Is there a way to get the font metrics from a window handle? > > No. This isn't a property of the window in the common case. It's only a property of the DC, which may exist only temporarily while drawing. And one may select various fonts into the DC at different times to draw different parts of the window. > humm, so how should i determine line height? -aric

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Elias Vanderstuyft

On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov <dmitry.torokhov(a)gmail.com> wrote: > On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: >> (added Dmitry to CC) >> >> 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: >> > Hi, >> > >> >> Hi, >> >> > In the process of reviewing the Wine DInput translation layer, I >> > noticed an inconvenience (in the ff-core implementation?) that can >> > possibly lead to confusing problems to application developers (not >> > only for Wine), in short: >> > If a new (id==-1) effect was uploaded (look at >> > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), >> > ff-core will have assigned a positive number to the effect id. This >> > can be confusing because the dev->ff->effects[] array will not contain >> > an element at the index of that new effect id. >> >> I agree that this is a bit confusing, and the kernel code should >> probably be modified to not clobber the ioctl-provided effect on failure >> (effect->id is set to an "undefined" value, i.e. next free effect slot). >> >> Dmitry, WDYT? > > Yeah, it looks like we need to change evdev.c to read: > > error = input_ff_upload(dev, &effect, file); > if (error) > return error; > > if (put_user(effect.id, &(((struct ff_effect __user *)p)->id))) > return -EFAULT; > > return 0; Alright, who will create the patch? Do I may / have to do it? > > Unfortunately applications should still expect changed effect ID for > quite some time. > > Thanks. > > -- > Dmitry Best regards, Elias

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 3:42 PM, Aric Stewart wrote: > On 2014/02/20 0:32, Ken Thomases wrote: >> I don't think this does what you want. GetDC() typically returns a DC whose parameters were reset. It doesn't know what font has previously been used in the window. So, you're basically getting the metrics for the System font. I suppose that may be better than nothing. > > I never knew that about GetDC, I did not see anything about reset parameters in MSDN. It's the first paragraph of the Remarks. <http://msdn.microsoft.com/en-us/library/windows/desktop/dd144871%28v=vs.85%…> Don't be confused by the last sentence with its mention of GetTextFace(). That's not a solution to the problem described in the rest of the paragraph; it's a non sequitur. > It was working for me pretty accurately in my testing even with different fonts. Is there a way to get the font metrics from a window handle? No. This isn't a property of the window in the common case. It's only a property of the DC, which may exist only temporarily while drawing. And one may select various fonts into the DC at different times to draw different parts of the window. -Ken

Feb. 19, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 0:32, Ken Thomases wrote: > On Feb 19, 2014, at 3:08 AM, Aric Stewart wrote: > >> diff --git a/dlls/winemac.drv/ime.c b/dlls/winemac.drv/ime.c >> index 2c74f6e..066c77a 100644 >> --- a/dlls/winemac.drv/ime.c >> +++ b/dlls/winemac.drv/ime.c >> @@ -1585,14 +1585,20 @@ BOOL query_ime_char_rect(macdrv_query* query) >> if (focus && (focus == hwnd || IsChild(hwnd, focus)) && >> GetClientRect(focus, &charpos.rcDocument)) >> { >> + HDC hdc = GetDC(focus); >> + TEXTMETRICA tm; >> + >> if (!GetCaretPos((POINT*)&charpos.rcDocument)) >> charpos.rcDocument.left = charpos.rcDocument.top = 0; >> >> + GetTextMetricsA(hdc, &tm); >> charpos.rcDocument.right = charpos.rcDocument.left + 1; >> + charpos.rcDocument.bottom = charpos.rcDocument.top + tm.tmHeight; >> MapWindowPoints(focus, 0, (POINT*)&charpos.rcDocument, 2); >> >> *rect = cgrect_from_rect(charpos.rcDocument); >> ret = TRUE; >> + ReleaseDC(focus, hdc); >> } >> } > > I don't think this does what you want. GetDC() typically returns a DC whose parameters were reset. It doesn't know what font has previously been used in the window. So, you're basically getting the metrics for the System font. I suppose that may be better than nothing. I never knew that about GetDC, I did not see anything about reset parameters in MSDN. It was working for me pretty accurately in my testing even with different fonts. Is there a way to get the font metrics from a window handle? I am going to need that for when I am implementing the Candidate Window stuff also. > > Also, you don't check if GetTextMetricsA() succeeded. > True. > > Perhaps using GetGUIThreadInfo() and the rcCaret field of the GUITHREADINFO structure would be better than using GetCaretPos(). In that case, you'd map the coordinates from hwndCaret (which may be different from "focus") to the screen. Be sure to read the remarks in the MSDN docs for the GetGUIThreadInfo() function about how to use rcCaret, although it's not clear to me if Wine implements this faithfully. > I will look into this, I have a number of programs where GetCaretPos is not returning correct information anyway so an alternative would be useful. -aric

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Dmitry Torokhov

On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: > (added Dmitry to CC) > > 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: > > Hi, > > > > Hi, > > > In the process of reviewing the Wine DInput translation layer, I > > noticed an inconvenience (in the ff-core implementation?) that can > > possibly lead to confusing problems to application developers (not > > only for Wine), in short: > > If a new (id==-1) effect was uploaded (look at > > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), > > ff-core will have assigned a positive number to the effect id. This > > can be confusing because the dev->ff->effects[] array will not contain > > an element at the index of that new effect id. > > I agree that this is a bit confusing, and the kernel code should > probably be modified to not clobber the ioctl-provided effect on failure > (effect->id is set to an "undefined" value, i.e. next free effect slot). > > Dmitry, WDYT? Yeah, it looks like we need to change evdev.c to read: error = input_ff_upload(dev, &effect, file); if (error) return error; if (put_user(effect.id, &(((struct ff_effect __user *)p)->id))) return -EFAULT; return 0; Unfortunately applications should still expect changed effect ID for quite some time. Thanks. -- Dmitry

Feb. 19, 2014

Re: [PATCH] user32: Fix RealGetWindowClass() to return what it's supposed to for same process windows (try3)

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -1098,22 +1098,81 @@ INT WINAPI GetClassNameW( HWND hwnd, LPWSTR buffer, INT count ) > return ret; > } > > +static const struct builtin_class_descr *builtin_classes[] = > +{ > + &BUTTON_builtin_class, > + &COMBO_builtin_class, > + &DIALOG_builtin_class, > + &EDIT_builtin_class, > + &LISTBOX_builtin_class, > + &MDICLIENT_builtin_class, > + &SCROLL_builtin_class, > + &STATIC_builtin_class > +}; There's no need to add this either, you can simply store the pointer. -- Alexandre Julliard julliard(a)winehq.org

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Elias Vanderstuyft

On Wed, Feb 19, 2014 at 8:32 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Wed, Feb 19, 2014 at 06:32:54PM +0100, Elias Vanderstuyft wrote: >> I'll include the code (with effectId_old variable) and this discussion >> when I submit my whole patchset for Wine's DInput libs to Wine-devel >> mailing list. Right now, I don't know who I should personally mail to. >> > > Patches ready to be included in Wine should go to > wine-patches(a)winehq.org. I've done a bit of work in dinput myself, so > you can feel free to send them to me and/or wine-devel first if you'd > like a review. <offtopic> Alright, thanks Andrew! I've also done some work on reverse engineering the FFE file format, which is needed to complete some missing functionality (http://wiki.winehq.org/ForceFeedbackSummerOfCode2005Summary) of the following functions: IDirectInputDevice8::WriteEffectToFile and IDirectInputDevice8::EnumEffectsInFile. Can I send it to you (in a new mail subject, of course) and cc wine-devel? </offtopic> > > Andrew Elias

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Andrew Eikum

On Wed, Feb 19, 2014 at 06:32:54PM +0100, Elias Vanderstuyft wrote: > I'll include the code (with effectId_old variable) and this discussion > when I submit my whole patchset for Wine's DInput libs to Wine-devel > mailing list. Right now, I don't know who I should personally mail to. > Patches ready to be included in Wine should go to wine-patches(a)winehq.org. I've done a bit of work in dinput myself, so you can feel free to send them to me and/or wine-devel first if you'd like a review. Andrew

Feb. 19, 2014

Re: [PATCH 2/4] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4)

by Henri Verbeet

On 19 February 2014 20:06, Ken Thomases <ken(a)codeweavers.com> wrote: > Hmm. The one issue is that, if the context_set_pixel_format() in context_update_window() fails, the context is marked as invalid and left that way. If we simply set needs_set instead, then context_acquire() will call context_set_gl_context(). That will try context_set_pixel_format() again but this time, if it fails, it will try the swapchain backup DC. I don't really know if that's desired. I assume the code is structured the way it is for a reason (i.e. a call to context_set_pixel_format() immediately before a call to context_set_gl_context(), which already begins with a call to the former). > Trying the backup DC would be correct. I probably just forgot to get rid of the context_set_pixel_format() call in context_update_window() back when I made context_restore_gl_context() try to restore the pixel format as well. The backup DC code was added even later by Matteo.

Feb. 19, 2014

Re: [PATCH 2/4] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4)

by Henri Verbeet

On 19 February 2014 19:25, Ken Thomases <ken(a)codeweavers.com> wrote: >> I think that mostly works, but you'll probably want to clear needs_set >> in context_set_gl_context() instead of in context_release(). > > Hmm. The old logic had context_acquire() doing context_set_gl_context() each time if context_enter() had set restore_ctx at the outmost level. I didn't want to change that because I wasn't confident it was superfluous. > If you only clear it in the outer context_release(), inner context_acquire() calls will call context_set_gl_context() without needing to. >> I think >> there's also an argument somewhere that context_update_window() should >> set needs_set instead of calling context_set_pixel_format() and >> context_set_gl_context(). > > Yeah, it could do that. Actually, looking at the current code, context_acquire() calls context_update_window() before context_enter(). Couldn't that screw up context_enter()'s ability to a) notice that it needs to restore the context, or b) record the proper context to restore? > Yeah, I think so. > > I have to say that my approach would be to record the state to restore at exactly the place where it is changed. So, the old WGL context and DC would be remembered at the call to wglMakeCurrent() or wglMakeContextCurrentARB(). In my pixel format patch, the old pixel format is remembered at the call to SetPixelFormat(). Etc. It's conceptually not that different, context_acquire() / context_enter() is the wined3d equivalent of wglMakeCurrent(). The split between context_acquire() and context_enter() may have room for improvement. Also note that some parts are just left over from back when we still had ActivateContext().

Feb. 19, 2014

Re: [PATCH 2/4] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4)

by Ken Thomases

On Feb 19, 2014, at 12:25 PM, Ken Thomases wrote: > On Feb 19, 2014, at 4:36 AM, Henri Verbeet wrote: > >> I think >> there's also an argument somewhere that context_update_window() should >> set needs_set instead of calling context_set_pixel_format() and >> context_set_gl_context(). Hmm. The one issue is that, if the context_set_pixel_format() in context_update_window() fails, the context is marked as invalid and left that way. If we simply set needs_set instead, then context_acquire() will call context_set_gl_context(). That will try context_set_pixel_format() again but this time, if it fails, it will try the swapchain backup DC. I don't really know if that's desired. I assume the code is structured the way it is for a reason (i.e. a call to context_set_pixel_format() immediately before a call to context_set_gl_context(), which already begins with a call to the former). -Ken

Feb. 19, 2014

Re: [PATCH 2/4] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4)

by Ken Thomases

On Feb 19, 2014, at 4:36 AM, Henri Verbeet wrote: > On 19 February 2014 04:30, Ken Thomases <ken(a)codeweavers.com> wrote: > >> @@ -3051,7 +3055,7 @@ struct wined3d_context *context_acquire(const struct wined3d_device *device, str >> if (!context_set_current(context)) >> ERR("Failed to activate the new context.\n"); >> } >> - else if (context->restore_ctx) >> + else if (context->needs_set) >> { >> context_set_gl_context(context); >> } > I think that mostly works, but you'll probably want to clear needs_set > in context_set_gl_context() instead of in context_release(). Hmm. The old logic had context_acquire() doing context_set_gl_context() each time if context_enter() had set restore_ctx at the outmost level. I didn't want to change that because I wasn't confident it was superfluous. > I think > there's also an argument somewhere that context_update_window() should > set needs_set instead of calling context_set_pixel_format() and > context_set_gl_context(). Yeah, it could do that. Actually, looking at the current code, context_acquire() calls context_update_window() before context_enter(). Couldn't that screw up context_enter()'s ability to a) notice that it needs to restore the context, or b) record the proper context to restore? I have to say that my approach would be to record the state to restore at exactly the place where it is changed. So, the old WGL context and DC would be remembered at the call to wglMakeCurrent() or wglMakeContextCurrentARB(). In my pixel format patch, the old pixel format is remembered at the call to SetPixelFormat(). Etc. You'd check to make sure that something isn't already remembered, of course, so you don't overwrite the remembered app-set state with wined3d-set state. My approach can be less efficient because you check the state too often. The current code uses the context->level transition from 0 to 1 to limit it. But we can use flags (something like "restore_ctx_valid", for example) to remember if we've checked since that transition and avoid checking again (even though restore_ctx itself may remain NULL). -Ken

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Elias Vanderstuyft

On Wed, Feb 19, 2014 at 5:49 PM, Anssi Hannula <anssi.hannula(a)iki.fi> wrote: > (added Dmitry to CC) > > 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: >> Hi, >> > > Hi, > >> In the process of reviewing the Wine DInput translation layer, I >> noticed an inconvenience (in the ff-core implementation?) that can >> possibly lead to confusing problems to application developers (not >> only for Wine), in short: >> If a new (id==-1) effect was uploaded (look at >> ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), >> ff-core will have assigned a positive number to the effect id. This >> can be confusing because the dev->ff->effects[] array will not contain >> an element at the index of that new effect id. > > I agree that this is a bit confusing, and the kernel code should > probably be modified to not clobber the ioctl-provided effect on failure > (effect->id is set to an "undefined" value, i.e. next free effect slot). > > Dmitry, WDYT? > > The downside is that if changed, any new userspace code may unknowingly > depend on the fixed non-clobbering behavior (though apparently they > already do, as evidenced by Wine DInput, so might not be much of an > argument...). I don't think that's a problem. Something that can be more problematic, is that a newer application assumes the fixed non-clobbering behaviour, but runs on a kernel with the old clobbering behaviour, could experience problems. > >> Here is a more elaborated description/discussion: >> - This is a bug that is either the responsibility of the Linux kernel, >> or of Wine (and possibly other applications that do the same thing as >> described below): >> It is caused by the following situation: >> When uploading an effect, the specific kernel device driver >> may return an error, >> e.g. EINVAL for example when a periodic's effect period is set to zero. >> This error will then be returned by "ioctl(*(This->fd), >> EVIOCSFF, &This->effect)". >> With or without error, one can find out that >> /drivers/input/ff-core.c:input_ff_upload(...) is called, >> which will set effect->id >= 0, if it was set to -1 (=> new >> effect created) by the user. >> >> But in case of an error: >> - Assume effect->id was set to -1 by the user: >> The error is reported by ff->upload(...) at >> /drivers/input/ff-core.c:167, >> the effect->id will also be set >= 0 (*). >> The offending effect will not be saved in the >> ff->effects[] array (***). >> - Assume effect->id was set >= 0 by the user (and >> ff->effects[effect->id] is a valid existing effect): >> The error is reported by ff->upload(...) at >> /drivers/input/ff-core.c:167, >> the effect->id will remain unchanged (**). >> The offending effect will not overwrite the >> ff->effects[effect->id] element (****). >> >> Is this (see *, **, *** and ****) desired behaviour? >> - If yes: >> Change the following in Wine's dinput/effect_linuxinput.c:90 : >> if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { >> to : >> int effectId_old = This->effect.id; >> if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { >> This->effect.id = effectId_old; >> - If no for *: >> Kernel code /drivers/input/ff-core.c:input_ff_upload(...) >> has to be patched to revert "effect->id" back to its original value >> set by the user, >> which is only needed when the initial (by user) value of >> "effect->id" was equal to -1. >> - If no for **** (or maybe also ***): >> ff->effects[effect->id] could be replaced by an 'empty' >> effect (however this can get complex because the effect's type has to >> remain unchanged) >> This would be a change in the kernel code >> /drivers/input/ff-core.c:input_ff_upload(...). >> - If no for **: >> I don't really know. Discussion is needed. >> >> - In my opinion, **, *** and **** are desired behaviour, while >> * should leave the effect->id at -1. > > Right. > >> In that case, Wine's dinput implementation does not have >> to be patched, and the kernel code only should apply a minor patch. > > Well, maybe better to change dinput anyway so that it can work properly > with current kernel versions (assuming this gets changed in the future)? > Not my call, though. Yes, agreed. I'll include the code (with effectId_old variable) and this discussion when I submit my whole patchset for Wine's DInput libs to Wine-devel mailing list. Right now, I don't know who I should personally mail to. > > -- > Anssi Hannula Elias

Feb. 19, 2014

Re: [PATCH 2/4] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4)

by Henri Verbeet

On 19 February 2014 17:10, Ken Thomases <ken(a)codeweavers.com> wrote: > But wined3d doesn't always restore when returning to the app (because the app hadn't made a GL context current) and then doesn't set its context when the app calls back into it. But between those points, the app could set a pixel format on a window. > Well, no, because SetPixelFormat() can't set the pixel format after wined3d did. (Ignoring hypothetical applications that know about WGL_WINE_pixel_format_passthrough.)

Feb. 19, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Anssi Hannula

(added Dmitry to CC) 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: > Hi, > Hi, > In the process of reviewing the Wine DInput translation layer, I > noticed an inconvenience (in the ff-core implementation?) that can > possibly lead to confusing problems to application developers (not > only for Wine), in short: > If a new (id==-1) effect was uploaded (look at > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), > ff-core will have assigned a positive number to the effect id. This > can be confusing because the dev->ff->effects[] array will not contain > an element at the index of that new effect id. I agree that this is a bit confusing, and the kernel code should probably be modified to not clobber the ioctl-provided effect on failure (effect->id is set to an "undefined" value, i.e. next free effect slot). Dmitry, WDYT? The downside is that if changed, any new userspace code may unknowingly depend on the fixed non-clobbering behavior (though apparently they already do, as evidenced by Wine DInput, so might not be much of an argument...). > Here is a more elaborated description/discussion: > - This is a bug that is either the responsibility of the Linux kernel, > or of Wine (and possibly other applications that do the same thing as > described below): > It is caused by the following situation: > When uploading an effect, the specific kernel device driver > may return an error, > e.g. EINVAL for example when a periodic's effect period is set to zero. > This error will then be returned by "ioctl(*(This->fd), > EVIOCSFF, &This->effect)". > With or without error, one can find out that > /drivers/input/ff-core.c:input_ff_upload(...) is called, > which will set effect->id >= 0, if it was set to -1 (=> new > effect created) by the user. > > But in case of an error: > - Assume effect->id was set to -1 by the user: > The error is reported by ff->upload(...) at > /drivers/input/ff-core.c:167, > the effect->id will also be set >= 0 (*). > The offending effect will not be saved in the > ff->effects[] array (***). > - Assume effect->id was set >= 0 by the user (and > ff->effects[effect->id] is a valid existing effect): > The error is reported by ff->upload(...) at > /drivers/input/ff-core.c:167, > the effect->id will remain unchanged (**). > The offending effect will not overwrite the > ff->effects[effect->id] element (****). > > Is this (see *, **, *** and ****) desired behaviour? > - If yes: > Change the following in Wine's dinput/effect_linuxinput.c:90 : > if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { > to : > int effectId_old = This->effect.id; > if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { > This->effect.id = effectId_old; > - If no for *: > Kernel code /drivers/input/ff-core.c:input_ff_upload(...) > has to be patched to revert "effect->id" back to its original value > set by the user, > which is only needed when the initial (by user) value of > "effect->id" was equal to -1. > - If no for **** (or maybe also ***): > ff->effects[effect->id] could be replaced by an 'empty' > effect (however this can get complex because the effect's type has to > remain unchanged) > This would be a change in the kernel code > /drivers/input/ff-core.c:input_ff_upload(...). > - If no for **: > I don't really know. Discussion is needed. > > - In my opinion, **, *** and **** are desired behaviour, while > * should leave the effect->id at -1. Right. > In that case, Wine's dinput implementation does not have > to be patched, and the kernel code only should apply a minor patch. Well, maybe better to change dinput anyway so that it can work properly with current kernel versions (assuming this gets changed in the future)? Not my call, though. -- Anssi Hannula

Feb. 19, 2014

Re: [1/2] shell32: Correct create flags when SEE_MASK_NO_CONSOLE isn't specified (resend)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > > > Changelog: > shell32: Correct create flags when SEE_MASK_NO_CONSOLE isn't specified There's more to it than that, now it's popping up consoles all over the place during make test. -- Alexandre Julliard julliard(a)winehq.org

Feb. 19, 2014

Re: [PATCH 2/4] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 4)

by Ken Thomases

On Feb 19, 2014, at 4:36 AM, Henri Verbeet wrote: > On 19 February 2014 02:53, Ken Thomases <ken(a)codeweavers.com> wrote: >> OK, I can see how that would happen. However, my wined3d patch didn't change that part of the logic. I think my test just exposed a pre-existing bug. It doesn't show up without my wined3d patch applied because, in that case, wined3d fails to restore the window's pixel format and leaves it with a double-buffered pixel format. The two bugs cancel each other out and fixing one allowed the other to be revealed. >> > With the current code, the pixel format only needs changing if the GL > context also does, that's just an implication of setting/restoring > both at the same time. But wined3d doesn't always restore when returning to the app (because the app hadn't made a GL context current) and then doesn't set its context when the app calls back into it. But between those points, the app could set a pixel format on a window. -Ken

Feb. 19, 2014

Re: [idea]wine support for Chrome OS

by Vincent Povirk

I don't think it's possible for existing Windows code to run in Native Client. As I understand it, NaCl verifies all x86 code to make sure it's safe before executing it, and Wine needs to load x86 code compiled for Windows directly, which will not be using the safe subset of x86 that NaCl requires. One would need a proper virtual machine to make that work, something like qemu perhaps. However, the pipelight project may be interested in support for PPAPI.

Feb. 19, 2014