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

To error out or to skip tests?
by Joerg-Cyril.Hoehle＠t-systems.com Nov. 9, 2009

Nov. 9, 2009

Hi, I apologize for the numerous occurrances of red color on test.winehq due to my new winmm MCI tests. That was not expected. However, turning something green is not a goal in itself. For some time now I wanted to query wine-devel about this topic, independently of my patches, so here it goes. An analysis reveals that my tests implement a detector of vmware (virtualbox etc.) default installs, i.e. MS-Windows systems that have not been configured with sound. No real user's machines would be like that (except for a w95 box I tried with a broken soundcard). The revealing line is > Tests skipped: Please install audio driver. Tests will fail (18 errors) This goes hand in hand with "5 tests, 0 errors, 1 skip" in winmm:wave. Exactly those systems skipping the wave tests produce 18-19 MCI errors. Failure to flag an error in such cases has known drawbacks: - For several month, Austin did not notice that his BSD boxes had lost sound. wave.ok simply reports "5 tests ok, 1 skipped" in joyfull green, whereas it executed many tests half a year ago. - All those vmware boxes configured without sound and thus skipping all but 5 wave.ok tests have for monthes *not* provided valuable feedback to Wine. So they were actually *not* executing tests, when they could have. It's only when Paul tested one of my tests that he realized that sound was not configured on one of his vmware boxes, promptly configured the sound device, and the tests passed. The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! They all have no sound configured. Mostly useless. Therefore, I believe it's sometimes better to flag an error than to calmly skip something. Last year already, submitting the ICCVID patches, I was thinking: "iccvid.dll may not part of every installation, but we want feedback so we should compare behaviour with MS-Windows systems equipped with that library and ask people to install it if not present". Likewise, Wine should compare with systems similarly equipped: d3d8, d3d9, dplay, dmusic etc. Perhaps an easy change on test.winehq would be to augment the blue color indicator of skipped tests to the full rectangle surface instead of the current green? Of course, I'll change my tests to flag a single error on systems without sound. -- Or no error at all, if that's wine-devel consensus. What do you think? Jörg Höhle. There's only few real MCI test errors I saw on test.winehq: the system "fg_winxp-ie8" that yields 1 error instead of 18: mci.c:391: Test failed: not enough time elapsed 80ms -- a flakey test. And on the ME systems: mci.c:603: Test failed: mci re-auto-open status mode returned error: 275 mci.c:612: Test failed: mci auto-open pause returned error: 275 Luckily, there are a few machines that pass all tests.

4 3

Another article that makes me want Wine to run in a sandbox
by Dan Kegel Nov. 8, 2009

Nov. 8, 2009

http://www.linuxinsider.com/rsstory/68566.html The article is about users who are willing to follow bogus instructions to solve a problem (or install something). It makes me want the average desktop to be really, really locked down... and for user-installed apps to run in a sandbox so they can't break the rest of the system. I am looking forward to hear what the discussion at http://sandboxing.org comes up with.

5 8

The user32/win test crashes X on Intel cards
by Francois Gouget Nov. 8, 2009

Nov. 8, 2009

I hit this issue while trying to run winetest for WineConf. I looked into it and the crash is caused by this line in dlls/user32/tests/win.c: SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); More precisely it's the setting of the window width and height to 32768 x 40000 that causes the crash. Looking at the .xsession-errors file I see the window manager reporting the following X server error: Anomalie dans le gestionnaire de fenêtres : Unexpected X error: BadAlloc (insufficient resources for operation) serial 11940 error_code 11 request_code 53 minor_code 0) Is it possible that this is just an out of memory issue caused by the huge window size? According to my tests 32000x32000 (a tad < 3GB) works but 32767x32767 (a tad >3GB) cause the crash. Here's my configuration: * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 * VideoRAM: 256MB (according to /var/log/Xorg.0.log) * xserver-xorg-video-intel 2:2.9.0-1 Latest from Debian Testing. Debian Unstable does not seem to have a more recent driver. Marcus got the same issue and he had an Intel card too and we were the only two with this issue. So apparently this is Intel-specific. Does any one have an Intel card where this does not happen? What's your driver version? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 2

Re: d3d9: quiet a few very noisy fixme's
by Austin English Nov. 8, 2009

Nov. 8, 2009

On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > These are spawned at huge rate in World in Conflict demo > (http://bugs.winehq.org/show_bug.cgi?id=11114) It'd be quicker/cleaner to just change them to warn's instead, IMHO. -- -Austin

2 1

Re: [PATCH] rpcrt4: compare networkoptions correctly (Coverity) (adjusted)
by Rob Shearman Nov. 8, 2009

Nov. 8, 2009

2009/11/8 Marcus Meissner <meissner(a)suse.de>: > @@ -84,6 +84,17 @@ static RPC_STATUS RpcAssoc_Alloc(LPCSTR Protseq, LPCSTR NetworkAddr, > return RPC_S_OK; > } > > +static BOOL compare_networkoptions(LPCWSTR opts1, LPCWSTR opts2) > +{ > + if ((opts1 == NULL) && (opts2 == NULL)) > + return TRUE; > + if ((opts1 == NULL) && (opts2 != NULL)) > + return FALSE; > + if ((opts1 != NULL) && (opts2 == NULL)) > + return FALSE; > + return !strcmpW(opts1, opts2); > +} > + > RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > LPCSTR Endpoint, LPCWSTR NetworkOptions, > RpcAssoc **assoc_out) > @@ -97,8 +108,8 @@ RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > if (!strcmp(Protseq, assoc->Protseq) && > !strcmp(NetworkAddr, assoc->NetworkAddr) && > !strcmp(Endpoint, assoc->Endpoint) && > - ((!assoc->NetworkOptions && !NetworkOptions) || !strcmpW(NetworkOptions, assoc->NetworkOptions))) > - { > + compare_networkoptions(NetworkOptions, assoc->NetworkOptions) > + ) { Looks good functionally, but please don't change the style. > assoc->refs++; > *assoc_out = assoc; > LeaveCriticalSection(&assoc_list_cs); Thanks, -- Rob Shearman

1 0

Re: winex11.drv: Implement FIXME in AlphaBlend
by Roderick Colenbrander Nov. 7, 2009

Nov. 7, 2009

Hi Peter, I didn't see this patch before because I was away at that time. The SourceConstantAlpha part looks correct to me. It might make sense to calculate blendfn.SourceConstantAlpha / 255 before the loop, so that it isn't recalculated each time. The other half of your patch is a separate change and it would require a separate patch. The part looks suspicious though. I don't understand why you need special locking there. Roderick On Mon, Oct 26, 2009 at 4:39 PM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > > > commit df78de34a06e32be9f37a3b34fe68e5b088a8578 > Author: Peter Urbanec <winehq.org(a)urbanec.net> > Date: Mon Oct 26 21:29:00 2009 +1100 > > Implement source alpha plus SourceConstantAlpha combined transparency. > Add DIB locking to prevent node icon rendering errors in Fusion composition flow views. > > diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c > index 90503bf..26dc262 100644 > --- a/dlls/winex11.drv/xrender.c > +++ b/dlls/winex11.drv/xrender.c > @@ -1956,9 +1956,6 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > return FALSE; > } > > - if ((blendfn.AlphaFormat & AC_SRC_ALPHA) && blendfn.SourceConstantAlpha != 0xff) > - FIXME("Ignoring SourceConstantAlpha %d for AC_SRC_ALPHA\n", blendfn.SourceConstantAlpha); > - > if(dib.dsBm.bmBitsPixel != 32) { > FIXME("not a 32 bpp dibsection\n"); > return FALSE; > @@ -1979,11 +1976,35 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > > if (blendfn.AlphaFormat & AC_SRC_ALPHA) > { > - for(; y >= y2; y--) > + if (blendfn.SourceConstantAlpha == 0xff) > { > - memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > + for(; y >= y2; y--) > + { > + memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > widthSrc * 4); > - dstbits += (top_down ? -1 : 1) * widthSrc; > + dstbits += (top_down ? -1 : 1) * widthSrc; > + } > + } > + else > + { > + /* Source alpha plus SourceConstantAlpha */ > + for(; y >= y2; y--) > + { > + int x; > + DWORD *srcbits = (DWORD *)((char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes) + xSrc; > + for (x = 0; x < widthSrc; x++) > + { > + DWORD argb = *srcbits++; > + BYTE *s = (BYTE *) &argb; > + s[0] = (s[0] * blendfn.SourceConstantAlpha) / 255; > + s[1] = (s[1] * blendfn.SourceConstantAlpha) / 255; > + s[2] = (s[2] * blendfn.SourceConstantAlpha) / 255; > + s[3] = (s[3] * blendfn.SourceConstantAlpha) / 255; > + *dstbits++ = argb; > + } > + if (top_down) /* we traversed the row forward so we should go back by two rows */ > + dstbits -= 2 * widthSrc; > + } > } > } > else > @@ -2006,6 +2027,7 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > > } > > + X11DRV_LockDIBSection( devDst, DIB_Status_GdiMod ); > dst_pict = get_xrender_picture(devDst); > > wine_tsx11_lock(); > @@ -2017,6 +2039,8 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > if(!src_format) > { > WARN("Unable to find a picture format supporting alpha, make sure X is running at 24-bit\n"); > + wine_tsx11_unlock(); > + X11DRV_UnlockDIBSection( devDst, TRUE ); > return FALSE; > } > > @@ -2055,6 +2079,7 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > XDestroyImage(image); > > wine_tsx11_unlock(); > + X11DRV_UnlockDIBSection( devDst, TRUE ); > HeapFree(GetProcessHeap(), 0, data); > return TRUE; > } > > > >

2 1

Re: (retry) msctf/tests: handle an occassional unexpected SetFocus from wine
by Nicolas Le Cam Nov. 7, 2009

Nov. 7, 2009

2009/11/7 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/msctf/tests/inputprocessor.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > Here are the results for 100 consecutive runs : $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 77 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 18 inputprocessor: 231 tests executed (0 marked as todo, 3 failures), 0 skipped. 3 inputprocessor: 234 tests executed (0 marked as todo, 4 failures), 0 skipped. 1 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. 1 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. I also did try to sleep between tests in case it could help but it doesn't seem so : $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; sleep 1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 78 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 17 inputprocessor: 231 tests executed (0 marked as todo, 3 failures), 0 skipped. 3 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. 2 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. For info, here is a run without your patch. $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; sleep 1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 64 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 18 inputprocessor: 236 tests executed (0 marked as todo, 4 failures), 0 skipped. 12 inputprocessor: 237 tests executed (0 marked as todo, 7 failures), 0 skipped. 3 inputprocessor: 234 tests executed (0 marked as todo, 4 failures), 0 skipped. 2 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. 1 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. If you need me to do more tests, just ask, I'm willing to go green ;) -- Nicolas Le Cam

1 0

Re: [PATCH] rpcrt4: Fixed incorrect NULL check condition (Coverity)
by Rob Shearman Nov. 7, 2009

Nov. 7, 2009

2009/10/17 Marcus Meissner <marcus(a)jet.franken.de>: > Hi, > > Coverity spotted that this could lead to NULL dereference, > and yes, the && should be ||. This is not what was intended. The code inside the if block shouldn't execute if assoc->NetworkOptions is NULL and NetworkOptions isn't and vice-versa. The comparison should probably be split into a separate function. > @@ -97,7 +97,7 @@ RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > if (!strcmp(Protseq, assoc->Protseq) && > !strcmp(NetworkAddr, assoc->NetworkAddr) && > !strcmp(Endpoint, assoc->Endpoint) && > - ((!assoc->NetworkOptions && !NetworkOptions) || !strcmpW(NetworkOptions, assoc->NetworkOptions))) > + (!assoc->NetworkOptions || !NetworkOptions || !strcmpW(NetworkOptions, assoc->NetworkOptions))) Thanks, -- Rob Shearman

1 0

libsmbclient and wine?
by Dan Kegel Nov. 7, 2009

Nov. 7, 2009

Hi folks, it's often been said that wine can't use libsmbclient because of license problems. I'd like to look at that assumption a bit. - What would wine like to use libsmbclient for, if it could? - Would it suffice to just link it in to wineserver, or would it need to be invoked directly by all sorts of dlls? - Would we just use the system's libsmbclient (I hope so) rather than trying to import its source? Also, fwiw, I think the Samba guys are willing to multiplex their listening daemon so Wine could handle incoming named pipe requests if we want to. Thanks, Dan

3 2

Re: msctf/tests: handle an occassional unexpected SetFocus from wine
by Aric Stewart Nov. 7, 2009

Nov. 7, 2009

Please disregard this. I was testing the wrong version on my winvista machine and this causes a failure. revised version coming. -aric Aric Stewart wrote: > --- > dlls/msctf/tests/inputprocessor.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > ------------------------------------------------------------------------ > >

1 0