January 2009 - Wine-Devel - list.winehq.org

RE: First complete test run passing on a Windows platform

by Ge van Geldorp

> From: Ge van Geldorp [mailto:ge(a)gse.nl] On Behalf Of 'Florian Köberle' Sorry, I messed up the headers. The previous message containing: > BTW, this causes failures also with my own fix applied (althoug only a > single failure instead of a bunch), so my own fix wasn't correct either. was sent by me, not by Florian. Gé

Jan. 30, 2009

RE: First complete test run passing on a Windows platform

by 'Florian Köberle'

> From: Ge van Geldorp [mailto:ge(a)gse.nl] > I've done some more experimenting and can get the problem to > reproduce more consistently (like 95% of the time instead of > 25%) by launching my shortcut twice (so I have two test runs > going at the same time). Then both of the runs will usually > show problems. BTW, this causes failures also with my own fix applied (althoug only a single failure instead of a bunch), so my own fix wasn't correct either. Gé.

Jan. 30, 2009

RE: First complete test run passing on a Windows platform

by Ge van Geldorp

Florian, > From: Florian Köberle [mailto:florian(a)fkoeberle.de] > How many cores do your processor have? > I have a dual core which might make the difference. I ran inside a VM that had 1 CPU assigned, so single core. > How exactly do you execute the tests? > I executed "../../../tools/runtest -q menu" about 20 times > without any failure. I copied user32_crosstest.exe to C:\winetest, then created a small batch file runtest.cmd: @echo off cd \winetest user32_crosstest menu pause Put a shortcut to runtest.cmd on the desktop and then set the shortcut to run Minimized (during my regular test runs the console is minimized too, so I thought I'd mimic that as much as possible). Then double click the shortcut, wait until the test is done, restore the console window and look at the results. > Did my patch reduce the number of failures? > I am asking as I wonder, if I should send the patch anyway to > wine-patches or not. It's hard to say because it doesn't reproduce consistently. My feeling is that it doesn't reduce the number of failures, but no hard data to back that up. > Does removing the Sleep(500) increase the fail rate? > I tried to remove it but it had no effect for me at all. No, I don't see an effect either. I've done some more experimenting and can get the problem to reproduce more consistently (like 95% of the time instead of 25%) by launching my shortcut twice (so I have two test runs going at the same time). Then both of the runs will usually show problems. Gé.

Jan. 30, 2009

Re: comctl32: Fix propsheet size calculation (resent)

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Alexandre Julliard wrote: >> Vitaliy <vitaliy(a)kievinfo.com> writes: >> >>> + /* Get non-client size */ >>> + if (!psInfo->isModeless) >>> + { >>> + RECT rc1; >>> + >>> + GetWindowRect(hwndDlg, &rc); >>> + GetClientRect(hwndDlg, &rc1); >>> + tabOffsetX = rc.right - rc.left - (rc1.right - rc.left); >>> + tabOffsetY = rc.bottom - rc.top - (rc1.bottom - rc.top); >> >> That doesn't make sense. What are you trying to compute here? >> > The size of non-client area - window borders and the title. Even after fixing the typos it doesn't really make sense, especially with names like tabOffsetX. You probably want AdjustWindowRect or something like that. -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2009

Re: comctl32: Fix propsheet size calculation (resent)

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy <vitaliy(a)kievinfo.com> writes: > >> + /* Get non-client size */ >> + if (!psInfo->isModeless) >> + { >> + RECT rc1; >> + >> + GetWindowRect(hwndDlg, &rc); >> + GetClientRect(hwndDlg, &rc1); >> + tabOffsetX = rc.right - rc.left - (rc1.right - rc.left); >> + tabOffsetY = rc.bottom - rc.top - (rc1.bottom - rc.top); > > That doesn't make sense. What are you trying to compute here? > The size of non-client area - window borders and the title. Vitaliy.

Jan. 30, 2009

Re: comctl32: Fix propsheet size calculation (resent)

by Alexandre Julliard

Vitaliy <vitaliy(a)kievinfo.com> writes: > + /* Get non-client size */ > + if (!psInfo->isModeless) > + { > + RECT rc1; > + > + GetWindowRect(hwndDlg, &rc); > + GetClientRect(hwndDlg, &rc1); > + tabOffsetX = rc.right - rc.left - (rc1.right - rc.left); > + tabOffsetY = rc.bottom - rc.top - (rc1.bottom - rc.top); That doesn't make sense. What are you trying to compute here? -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2009

Re: First complete test run passing on a Windows platform

by Florian Köberle

Hello Gé. >> I think the main problem is that the thread might run >> parallel with some other test code. >> >> That is why I would suggest to wait for the thread to finish >> at the end of the test. >> >> I made a patch and attached it to this email. I can't >> reproduce the failure on my system, so I can't test if the >> patch helps. It would be cool, if someone could test, if my >> patch fix the issue. >> > > I applied your patch and ran the test about a dozen times, two runs had > failures. So I'm afraid your patch is not enough. > > Gé. > How many cores do your processor have? I have a dual core which might make the difference. How exactly do you execute the tests? I executed "../../../tools/runtest -q menu" about 20 times without any failure. Did my patch reduce the number of failures? I am asking as I wonder, if I should send the patch anyway to wine-patches or not. Does removing the Sleep(500) increase the fail rate? I tried to remove it but it had no effect for me at all. Best regards, Florian Köberle

Jan. 30, 2009

RE: First complete test run passing on a Windows platform

by Ge van Geldorp

Hi Florian, > From: Florian Köberle [mailto:florian(a)fkoeberle.de] > I think the main problem is that the thread might run > parallel with some other test code. > > That is why I would suggest to wait for the thread to finish > at the end of the test. > > I made a patch and attached it to this email. I can't > reproduce the failure on my system, so I can't test if the > patch helps. It would be cool, if someone could test, if my > patch fix the issue. I applied your patch and ran the test about a dozen times, two runs had failures. So I'm afraid your patch is not enough. Gé.

Jan. 30, 2009

DIB Engine - Rebased on current tree (Takes 2) - Part 2 - winedib.drv initial implementation

by Massimo Del Fedele

Here part 2. Ciao Max

Jan. 30, 2009

DIB Engine - Rebased on current tree (Takes 2) - Part one - GDI32 patches

by Massimo Del Fedele

As there where some changes on GDI32 in latest commits, previous testing DIB Engine had to be modified too. I'm posting here (and in bug 421 page) the 2 needed patches, separated by GDI32 changes and winedib.drv folder. In order to keep patches smaller, I dropped the autogenerated 'configure', but leaving 'configure.ac'.... I guess this is the correct way, probably an autoconf is needed to regenerate the configure file. I was asked to separate the commits from Huw Davies, Jesse Allen and me, but as I changed most of the original author's code It'll be somehow difficult and, imho, will make few sense. It can be done, but that would mean to post a great number of patches with the final result quite different from the original one. I let of course the original copyright notices inside files; I'd like original author's opinion if for them is enough. Instructions on how to enable/disable the engine as the same as previous post, and are detailed in BUG 421 page. First part -- GDI32 patches Ciao Max

Jan. 30, 2009