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

Re: user32: Protect from setting as a window owner one of window's succesors.

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4287 Your paranoid android. === W98SE (32 bit win) === win.c:110: Test failed: Wrong result for GWL_HWNDPARENT 0000076C expected 00000000 win.c:114: Test failed: Wrong result for GW_OWNER 0000076C expected 00000000 win.c:388: Test failed: GWL_HWNDPARENT return value 0000076C expected 0 === W7PRO (32 bit win) === win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 006E01AE fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 007001AE fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000501A0 fg 00030050 in hook HCBT_SETFOCUS win.c:2668: Test failed: GetActiveWindow() = 00000000 win.c:2668: Test failed: GetFocus() = 00000000 win.c:2694: Test failed: GetActiveWindow() = 00000000 win.c:2694: Test failed: GetFocus() = 00000000 win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000601A0 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000501A2 fg 00030050 in hook HCBT_SETFOCUS win.c:2753: Test failed: GetActiveWindow() = 00000000 win.c:2753: Test failed: GetFocus() = 00000000 win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000C016C fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 002E01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 002F01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000401A4 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000801A4 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000901A4 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 001801A0 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000401A8 fg 00030050 in hook HCBT_SETFOCUS win.c:827: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000C016C fg 00030050 in hook HCBT_SETFOCUS

Aug. 4, 2010

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

by Stefan Dösinger

Am 04.08.2010 um 12:29 schrieb Alexandre Julliard: > Oldřich Jedlička <oldium.pro(a)seznam.cz> writes: > >> + __TRY >> + { >> + hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL); >> + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return 0x%08x, but 0x%08x\n", >> + DDERR_INVALIDPARAMS, hr); >> + } >> + __EXCEPT_PAGE_FAULT >> + { >> + todo_wine ok(FALSE, "IDirectDraw_CreateSurface dereferenced NULL pointer\n"); >> + } >> + __ENDTRY > > You can't use Wine exception macros in tests. In this case it is better not to include the NULL pointer tests in this patch and add them in the patch that adds the NULL pointer checks in ddraw. @Alexandre: I didn't know about that either, otherwise I'd have caught it when looking at the patch.

Aug. 4, 2010

Re: [PATCH] kernel32/tests: Try harder to crash in the debugger test.

by Octavian Voicu

Please ignore this patch. It seems that it does crash all the time, just that sometimes the debugger won't kick in on win64. There is a bug but it's somewhere else. Octavian

Aug. 4, 2010

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

by Alexandre Julliard

Oldřich Jedlička <oldium.pro(a)seznam.cz> writes: > + __TRY > + { > + hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return 0x%08x, but 0x%08x\n", > + DDERR_INVALIDPARAMS, hr); > + } > + __EXCEPT_PAGE_FAULT > + { > + todo_wine ok(FALSE, "IDirectDraw_CreateSurface dereferenced NULL pointer\n"); > + } > + __ENDTRY You can't use Wine exception macros in tests. -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

Re: [PATCH 2/2 (resend)] shell32: Also compare UNIX realpaths in SHChangeNotify

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > This fixes bug 18606. > > It's possible to refer to the same file in two different ways with PIDLs > in Wine. This can cause notifications via SHChangeNotify to fail to > trigger. To ensure an apples-to-apples comparison, we convert the > incoming PIDLs and the filters to UNIX paths and compare those if the > PIDLs fail to match. You should never compare Unix paths. If you want to compare file identity you should use stat and compare device+inode. But it's not clear to me that this is the right thing to do here, what is the exact case that is failing? -- Alexandre Julliard julliard(a)winehq.org

Aug. 4, 2010

Re: shdocvw: Update Italian translation

by Austin English

On Wed, Aug 4, 2010 at 3:17 PM, Luca Bennati <lucak3(a)gmail.com> wrote: Please send patches to wine-patches(a)winehq.org, they are not picked up here. Thanks! -- -Austin

Aug. 4, 2010

Re: d3dx9_36/tests: Added HLSL test suite. (try 3)

by Henri Verbeet

On 3 August 2010 21:07, Travis Athougies <iammisc(a)gmail.com> wrote: > dlls/d3dx9_36/tests/Makefile.in | 1 + > dlls/d3dx9_36/tests/hlsl.c | 666 +++++++++++++++++++++++++++++++++++++++ > include/d3dx9shader.h | 11 + > 3 files changed, 678 insertions(+), 0 deletions(-) > create mode 100644 dlls/d3dx9_36/tests/hlsl.c > Needs splitting.

Aug. 4, 2010

Re: [PATCH 07/10] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 3)

by Stefan Dösinger

Am 03.08.2010 um 21:26 schrieb Oldřich Jedlička: > DirectX 1 interface allowed creation of explicit back buffers, so move the > restrictive checks to DirectX 2+ implementations. Don't permit creating of > primary surface back buffer. The patch(as well as 9 and 10) look OK to me. Patch 6 is OK too. Patch 8 is missing a call to wined3d to tell it about the new backbuffer. (Apps will likely still work with the GDI renderer, but not the opengl ddraw renderer)

Aug. 4, 2010

Re: [PATCH 04/10] ddraw/tests: New visual back buffer flipping tests. (try 3)

by Stefan Dösinger

Am 03.08.2010 um 21:26 schrieb Oldřich Jedlička: > + whiteBrush = CreateSolidBrush(white); > + ok(whiteBrush != NULL, "CreateBrush returned: %p\n", whiteBrush); > + redBrush = CreateSolidBrush(red); > + ok(redBrush != NULL, "CreateBrush returned: %p\n", redBrush); > + > + hr = IDirectDrawSurface_GetDC(Backbuffer, &dc); > + ok(hr == DD_OK, "IDirectDrawSurface_GetDC returned: %x\n", hr); > + ret = FillRect(dc, &rect, redBrush); > + ok(ret != 0, "FillRect failed\n"); > + hr = IDirectDrawSurface_ReleaseDC(Backbuffer, dc); > + ok(hr == DD_OK, "IDirectDrawSurface_ReleaseDC returned: %x\n", hr); It would be more directdraw-ish to use a colorfill blit instead of getDC + gdi drawing. Tests 1-3 and 5 look OK though.

Aug. 4, 2010

shdocvw: Update Italian translation

by Luca Bennati

Aug. 4, 2010

Re: [PATCH 09/10] ddraw: Add checking of SURFACEDESC type into CreateSurface methods. (try 3)

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4262 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH 08/10] ddraw: Allow attaching backbuffers and primaries. (try 3)

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4261 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH 07/10] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 3)

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4260 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: tools/winebuild: add missing separators

by Andrew Nguyen

On Tue, Aug 3, 2010 at 9:57 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > > The colons aren't decorative separators, but rather determine which short arguments expect a parameter as per the requirements of getopt/getopt_long. With your patch applied: $ tools/winebuild/winebuild -h tools/winebuild/winebuild: option requires an argument -- 'h'

Aug. 4, 2010

Re: [PATCH 04/10] ddraw/tests: New visual back buffer flipping tests. (try 3)

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4251 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1497: Test failed: Got color 000a246a, expected 000000ff or near visual.c:1503: Test failed: Got color 006b8bbd, expected 000000ff or near visual.c:1509: Test failed: Got color 00ffffff, expected 00000080 or near visual.c:1515: Test failed: Got color 00ffffff, expected 00000080 or near

Aug. 4, 2010

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4250 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH] kernel32/tests: Try harder to crash in the debugger test.

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4248 Your paranoid android. === W7PROX64 (64 bit debugger) === debugger.c:309: Test failed: Timed out waiting for the child to crash debugger.c:323: Test failed: wrong exit code : 00000103 debugger.c:334: Test failed: Timed out waiting for the debugger debugger.c:149: Test failed: wrong size for 'C:\Users\winetest\AppData\Local\Temp\wtD67.tmp': read=0 debugger.c:339: Test failed: wrong debugger argument count: -32297584 debugger.c:340: Test failed: the child and debugged pids don't match: 2284 != 2046 debugger.c:309: Test failed: Timed out waiting for the child to crash debugger.c:316: Test failed: wrong exit code : 00000103 debugger.c:334: Test failed: Timed out waiting for the debugger debugger.c:149: Test failed: wrong size for 'C:\Users\winetest\AppData\Local\Temp\wtE239.tmp': read=0 debugger.c:339: Test failed: wrong debugger argument count: -32297584 debugger.c:340: Test failed: the child and debugged pids don't match: 2384 != 2046 Timeout

Aug. 4, 2010

Re: [PATCH 02/10] ddraw/tests: New attachment/flipping tests for back buffers. (try 3)

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4246 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: [PATCH 01/10] ddraw/tests: New CreateSurface for DDSCAPS_BACKBUFFER tests. (try 3)

by testbot＠testbot.winehq.org

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 http://testbot.winehq.org/JobDetails.pl?Key=4245 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 4, 2010

Re: regedit: Added Hebrew translation

by Charles Davis

On 8/3/10 4:58 AM, Yaron Shahrabani wrote: > How can I compile a single RC file? After configuring Wine, go to the directory containing the RC file and type in a Terminal: make <basename>.res where <basename> is the part of the filename before the '.rc' extension. So if you wanted to compile only He.rc for regedit, you'd first 'cd' to <wine-src>/programs/regedit and then type 'make He.res'. Chip

Aug. 3, 2010

Re: Should we expect Liberation fonts to be installed?

by Scott Ritchie

On 08/03/2010 03:09 PM, David Gerard wrote: > On 3 August 2010 21:57, Scott Ritchie <scott(a)open-vote.org> wrote: > >> This bug, for instance, prevents Photoshop from working unless there is >> an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 >> Wine doesn't seem to respect system-level fontconfig aliases, so even >> though Liberation Sans is installed on the system Photoshop won't try to >> use it in place of Arial. > > > This is an excellent idea, except that the Liberation fonts are really > horrible. I've *tried* using them for general text use and they make > me want to gouge my eyes out. > > Is there really no reasonable way to detect the system font settings > in GNOME or KDE? And where detection fails, a Wine control panel > perhaps? > > > - d. Well, if we did use the fontconfig aliases, you'd be seeing the Liberation fonts unless you had the real Arial installed ;) Thanks, Scott Ritchie

Aug. 3, 2010

Re: Should we expect Liberation fonts to be installed?

by David Gerard

On 3 August 2010 21:57, Scott Ritchie <scott(a)open-vote.org> wrote: > This bug, for instance, prevents Photoshop from working unless there is > an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 > Wine doesn't seem to respect system-level fontconfig aliases, so even > though Liberation Sans is installed on the system Photoshop won't try to > use it in place of Arial. This is an excellent idea, except that the Liberation fonts are really horrible. I've *tried* using them for general text use and they make me want to gouge my eyes out. Is there really no reasonable way to detect the system font settings in GNOME or KDE? And where detection fails, a Wine control panel perhaps? - d.

Aug. 3, 2010

Should we expect Liberation fonts to be installed?

by Scott Ritchie

I was looking through our fairly large collection of open font bugs and realized that things might be a lot simpler if we took some opinionated positions and just declared certain fonts to be dependencies and expected all packagers to provide them. This is similar to bundling our own Tahoma, except much less work. This bug, for instance, prevents Photoshop from working unless there is an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623 Wine doesn't seem to respect system-level fontconfig aliases, so even though Liberation Sans is installed on the system Photoshop won't try to use it in place of Arial. But if however we assumed that Liberation Sans was installed, we could make things much better: a link/substitution for Arial->Liberation Sans could be provided in our own registry (and similarly for Times New Roman and Courier). An alternative is to simply symlink to the Liberation Fonts in /usr/share/wine/fonts as though they were our own shipped fonts (like Tahoma). This would make Photoshop think Arial was present and keep it functional. Ideally the real Arial would be displayed if it was installed (eg through winetricks corefonts or by installing the distro-provided corefonts package). A related question is whether to show "Arial" in the list of fonts (eg notepad) when we're actually just providing a substituted Arial. My inclination says no, however I'm not sure how it works internally and what an application would expect. Thanks, Scott Ritchie

Aug. 3, 2010

Re: [PATCH 2/4] include/shlobj.h: SHILCreateFromPath takes both CSTR and WSTR

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > This is different from the latest PSDK, but Wine's SHILCreateFromPath > accepts both types, so we shouldn't make compiler warnings about it. If there are warnings with the Windows headers there should be warnings with the Wine ones too. -- Alexandre Julliard julliard(a)winehq.org

Aug. 3, 2010

Re: wiki slightly broken still?

by David Gerard

[to list as well] On 3 August 2010 15:07, Dimi Paun <dimi(a)lattica.com> wrote: > On Tue, 2010-08-03 at 14:30 +0200, Alexandru Băluț wrote: >> How difficult would it be to use ReCaptcha? >> http://www.google.com/recaptcha > Hm, don't know. We could hack our version to support recaptcha, > but I'm not familiar with the code base, and I don't have the > time right now. But I can take patches if someone is willing > to do it. The MoinMoin developers consider TextCHA inherently superior and so have no interest in writing a reCaptcha interface: http://moinmo.in/FeatureRequests/ReCaptcha (Note also the problems people have had with TextCHA: it becomes too much work to write the questions and to answer the questions.) If someone wants reCaptcha in MoinMoin, it appears they will need to write it all themselves. - d.

Aug. 3, 2010