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

Wine users with a CD-ROM drive, please test
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 11, 2010

Aug. 11, 2010

Hi, No more MCIERR_HARDWARE in David's latest test result, hurray! The difference with prior tests is that I temporarily eliminated 3 commands a) resume c b) set c video audio all off c) set c door closed notify We are not done yet. Users who saw that error please feed the following scripts into the mcishell to see which of those 3 commands causes the failure. The mcishell is attached to bug #20232 at http://bugs.winehq.org/show_bug.cgi?id=20232#c10 http://bugs.winehq.org/attachment.cgi?id=24529 wintest.exe mcishell mci.c:1363: Type your commands to the MCI, end with Ctrl-Z The 5 test failures in David's report are unrelated to MCIERR_HARDWARE. >mcicda.c:540: Test failed: status mode after play is playing Weird. I'd have expected Play to terminate within Sleep(3900ms) time. >mcicda.c:297: Test failed: status position initially 00:02:33 I'll take care of that another day. For now I'll just remember that there are disks that don't start at position 00:02:00. Please copy&paste these lines as one piece into a cmd shell so that there's as little delay as possible between commands. # a) resume open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify resume c status c mode seek c to start notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Don't forget after each one close c # b) set video audio open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c video audio all off status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c # c) set door closed open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c door closed notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Thank you for testing, Jörg Höhle

1 0

Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.
by misha680 Aug. 10, 2010

Aug. 10, 2010

Dear All: I have become more busy with schoolwork than I had imagined. However, I would still like, if possible, to finish work on http://bugs.winehq.org/show_bug.cgi?id=22918 It has been suggested that I send patches to the wine-devel list first for feedback. This way, I hope to be able to get developer expertise in these areas, and to be able to understand exactly what is necessary for a given patch. I have, per this comment from Henri: http://bugs.winehq.org/show_bug.cgi?id=22918#c51 written a draft patch for FVF <-> declaration conversion tests. It can be found at the Nabble link below. I will appreciate comments as to what is necessary for this patch (or a similar one) to get accepted. http://wine.1045685.n5.nabble.com/file/n2471306/0001-d3dx9-Add-tests-for-FV… 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt I realize there are already three tests for conversion in one direction. I have decided at the moment to leave those as is and focus on getting necessary feedback for getting an appropriate patch accepted. If you have any guidance with regards to this, much appreciated. Thank you Misha p.s. I have uploaded some shell scripts that I use for Wine development here: http://groups.google.com/group/misha680-wine/files I don't know how useful they will be to anyone else, but if anything, it provides an nice backup for my computer. -- View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… Sent from the Wine - Devel mailing list archive at Nabble.com.

2 2

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)
by Stefan Dösinger Aug. 10, 2010

Aug. 10, 2010

Diff -u doesn't find any difference between try 4 and try 5, and probably older tries. If you're resending them because the older ones weren't applied, that's futile - Alexandre is on vacation. Also it is generally a bad idea to keep resending a unchanged patch. If you think the patch has been lost(e.g. Alexandre is waiting for my review and I am not at home, etc) it is better to ask on Wine-devel what is up with the patches. Am Sonntag 08 August 2010, 07:09:24 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/dsurface.c | 138 > +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 138 > insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index 76bfc7e..8cdcd92 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -25,6 +25,7 @@ > > #include <assert.h> > #include "wine/test.h" > +#include "wine/exception.h" > #include "ddraw.h" > #include "d3d.h" > #include "unknwn.h" > @@ -3569,6 +3570,142 @@ static void BackBufferAttachmentFlipTest(void) > DestroyWindow(window); > } > > +static void CreateSurfaceBadCapsSizeTest(void) > +{ > + DDSURFACEDESC ddsd_ok; > + DDSURFACEDESC ddsd_bad1; > + DDSURFACEDESC ddsd_bad2; > + DDSURFACEDESC ddsd_bad3; > + DDSURFACEDESC ddsd_bad4; > + DDSURFACEDESC2 ddsd2_ok; > + DDSURFACEDESC2 ddsd2_bad1; > + DDSURFACEDESC2 ddsd2_bad2; > + DDSURFACEDESC2 ddsd2_bad3; > + DDSURFACEDESC2 ddsd2_bad4; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + > + const DWORD caps = DDSCAPS_OFFSCREENPLAIN; > + > + memset(&ddsd_ok, 0, sizeof(ddsd_ok)); > + ddsd_ok.dwSize = sizeof(ddsd_ok); > + ddsd_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd_ok.dwWidth = 64; > + ddsd_ok.dwHeight = 64; > + ddsd_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd_bad1, &ddsd_ok, sizeof(ddsd_bad1)); > + ddsd_bad1.dwSize--; > + memcpy(&ddsd_bad2, &ddsd_ok, sizeof(ddsd_bad2)); > + ddsd_bad2.dwSize++; > + memcpy(&ddsd_bad3, &ddsd_ok, sizeof(ddsd_bad3)); > + ddsd_bad3.dwSize = 0; > + memcpy(&ddsd_bad4, &ddsd_ok, sizeof(ddsd_bad4)); > + ddsd_bad4.dwSize = sizeof(DDSURFACEDESC2); > + > + memset(&ddsd2_ok, 0, sizeof(ddsd2_ok)); > + ddsd2_ok.dwSize = sizeof(ddsd2_ok); > + ddsd2_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2_ok.dwWidth = 64; > + ddsd2_ok.dwHeight = 64; > + ddsd2_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd2_bad1, &ddsd2_ok, sizeof(ddsd2_bad1)); > + ddsd2_bad1.dwSize--; > + memcpy(&ddsd2_bad2, &ddsd2_ok, sizeof(ddsd2_bad2)); > + ddsd2_bad2.dwSize++; > + memcpy(&ddsd2_bad3, &ddsd2_ok, sizeof(ddsd2_bad3)); > + ddsd2_bad3.dwSize = 0; > + memcpy(&ddsd2_bad4, &ddsd2_ok, sizeof(ddsd2_bad4)); > + ddsd2_bad4.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return > 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw2, (void **) > &dd2); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw2_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw4, (void **) > &dd4); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_ok, &surf4, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw4_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface4_Release(surf4); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad1, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad2, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad3, &surf4, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad4, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) > &dd7); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_ok, &surf7, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw7_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface7_Release(surf7); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad1, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad2, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad3, &surf7, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad4, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(dsurface) > { > HRESULT ret; > @@ -3624,5 +3761,6 @@ START_TEST(dsurface) > GetDCFormatTest(); > BackBufferCreateSurfaceTest(); > BackBufferAttachmentFlipTest(); > + CreateSurfaceBadCapsSizeTest(); > ReleaseDirectDraw(); > }

2 2

X Presentation and Synchronization - will it help Wine performance
by Groeschel, Volker Aug. 10, 2010

Aug. 10, 2010

Hi, I wonder if Wine will profit from the new X Presentation and Synchronization feature NVIDIA is working on: http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… According to the Phoronix article the feature is planed for X.Org Server 1.10: http://www.phoronix.com/scan.php?page=news_item&px=ODM3Ng e.g. when I start several instances of my game with Wine on my computer (AMD X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks down dramatically. As of three instances the third windows freezes or gets near 0 FPS while the same computer with Win XP can run up to eight instances. Many thanks for your good work which helps me to get rid of Windows in my home office ☺

3 2

New and subtle ddraw:dsurface test failure
by wylda＠volny.cz Aug. 10, 2010

Aug. 10, 2010

Hi, i just noticed some new and subtle failure in ddraw:dsurface tests. I don't know how closely you watch and study tests results, so i thought it might be a good idea bring it the the light. Sorry if not ;-) Compared WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last Friday). Interestingly does not happen on Intel and nVidia 64bit. So the only affected is nVidia 32bit. (For my education) Generally, when the test fails in Windows world, it means that the test is wrongly written or not supported under the tested Windows version? (not blaming anyone, just asking how things work;) And the last question is about MSI failures and timeouts which some boxes suffers... In my case the "powerful" succeeds and the "weak" timeouts here (and not just mine). Shouldn't be the timeout prolonged? Regards, W. PS: I probably missed "gratulation time" for v1.2, so at least i wish all the goodness to 1.3.xx line! And hope i find another free time for buzilla soon.

5 6

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)
by Michael Stefaniuc Aug. 10, 2010

Aug. 10, 2010

Hello Austin, Austin Lund wrote: > > ------------------------------------------------------------------------ > From 07bc18edc35c68c8e0da58a70ccd5c8f03584a1a Mon Sep 17 00:00:00 2001 > From: Austin Lund <austin.lund(a)gmail.com> > Date: Tue, 10 Aug 2010 13:03:14 +1000 > Subject: [PATCH] winex11.drv: Fix uninitialised values. (valgrind) > > --- > dlls/winex11.drv/bitmap.c | 2 +- > dlls/winex11.drv/dib.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c > index 4683fd9..af6c00b 100644 > --- a/dlls/winex11.drv/bitmap.c > +++ b/dlls/winex11.drv/bitmap.c > @@ -351,7 +351,7 @@ LONG CDECL X11DRV_SetBitmapBits( HBITMAP hbitmap, const void *bits, LONG count ) > wine_tsx11_lock(); > image = XCreateImage( gdi_display, visual, physBitmap->pixmap_depth, ZPixmap, 0, NULL, > bitmap.bmWidth, height, 32, 0 ); > - if (!(image->data = HeapAlloc( GetProcessHeap(), 0, image->bytes_per_line * height ))) > + if (!(image->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, image->bytes_per_line * height ))) > { > WARN("No memory to create image data.\n"); > XDestroyImage( image ); > diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c > index 11157f1..eda064e 100644 > --- a/dlls/winex11.drv/dib.c > +++ b/dlls/winex11.drv/dib.c > @@ -3535,7 +3535,7 @@ static int X11DRV_DIB_SetImageBits( const X11DRV_DIB_IMAGEBITS_DESCR *descr ) > else { > bmpImage = XCreateImage( gdi_display, visual, descr->depth, ZPixmap, 0, NULL, > descr->infoWidth, lines, 32, 0 ); > - bmpImage->data = HeapAlloc( GetProcessHeap(), 0, lines * bmpImage->bytes_per_line ); > + bmpImage->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, lines * bmpImage->bytes_per_line ); > if(bmpImage->data == NULL) { > ERR("Out of memory!\n"); > XDestroyImage( bmpImage ); > both functions are heavily used and you don't want to waste time HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind complains as e.g. in X11DRV_SetBitmapBits() only the default switch case won't initialize the memory at all. bye michael

2 2

Re: [PATCH] quartz: implement AsyncReader_FindPin
by David Adam Aug. 9, 2010

Aug. 9, 2010

Hi, what about if ppPin is NULL? I think that this patch needs test cases to prove that it is correct? David 2010/8/6 Anton Khirnov <wyskas(a)gmail.com> > --- > dlls/quartz/filesource.c | 32 ++++++++++++++++++++++++++++++-- > 1 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/dlls/quartz/filesource.c b/dlls/quartz/filesource.c > index 110415d..00a91c8 100644 > --- a/dlls/quartz/filesource.c > +++ b/dlls/quartz/filesource.c > @@ -548,9 +548,37 @@ static HRESULT WINAPI AsyncReader_EnumPins(IBaseFilter > * iface, IEnumPins **ppEn > > static HRESULT WINAPI AsyncReader_FindPin(IBaseFilter * iface, LPCWSTR Id, > IPin **ppPin) > { > - FIXME("(%s, %p)\n", debugstr_w(Id), ppPin); > + IEnumPins *enumpins; > + HRESULT hr; > > - return E_NOTIMPL; > + hr = AsyncReader_EnumPins(iface, &enumpins); > + if (FAILED(hr)) > + return S_FALSE; > + > + while (hr == S_OK) { > + IPin *pin; > + LPWSTR pinname; > + > + hr = IEnumPins_Next(enumpins, 1, &pin, NULL); > + if (FAILED(hr)) > + break; > + > + hr = IPin_QueryId(pin, &pinname); > + if (SUCCEEDED(hr)) { > + if (!strcmpW(pinname, Id)) { > + *ppPin = pin; > + IPin_AddRef(*ppPin); > + CoTaskMemFree(pinname); > + break; > + } > + CoTaskMemFree(pinname); > + } > + } > + > + IEnumPins_Release(enumpins); > + if (SUCCEEDED(hr)) > + return S_OK; > + return S_FALSE; > } > > static HRESULT WINAPI AsyncReader_QueryFilterInfo(IBaseFilter * iface, > FILTER_INFO *pInfo) > -- > 1.7.1 > > > >

2 1

'winetricks python' and user-submitted small testcases
by Dan Kegel Aug. 8, 2010

Aug. 8, 2010

Waaaay back in 2002, the wine project experimented with writing win32 conformance tests in Perl. Nobody liked it; it was dropped in favor of conformance tests in C, and there was much rejoicing. Today I noticed http://bugs.winehq.org/show_bug.cgi?id=23940 which has a simple win32 test case written in Python. Surprisingly, with 'winetricks python', the test case ran and demonstrated the problem (though since the python script expected you to start another app first, and edit the python to have the other app's window title, it wasn't an unattended test). That particular bug isn't anything special, but I was happy to see that a user who preferred Python was able to successfully send a minimal test case for a win32 problem written in his favorite language, and have someone else successfully run it.

1 0

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5)
by testbot＠testbot.winehq.org Aug. 8, 2010

Aug. 8, 2010

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=4356 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1742: Test failed: Got color 000a246a, expected 00000000 visual.c:1748: Test failed: Got color 006b8bbd, expected 00ff0000 or near visual.c:1751: Test failed: Got color 00ffffff, expected 00000000 visual.c:1757: Test failed: Got color 00ffffff, expected 00800000 or near === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: gdi32: use usp10 to optionally generate glyphs for bidi strings
by Dmitry Timoshkov Aug. 8, 2010

Aug. 8, 2010

Aric Stewart <aric(a)codeweavers.com> wrote: > allows us to be able to make use of the mirroring code and eventually > the shaping code when it is in place. This should be done the other way around. gdi32 should not depend on a high level dll (that creates circular dependencies), gdi32 in Windows doesn't use usp10 either. -- Dmitry.

4 5

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)
by testbot＠testbot.winehq.org Aug. 8, 2010

Aug. 8, 2010

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=4352 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

1 0

Should we expect Liberation fonts to be installed?
by Scott Ritchie Aug. 8, 2010

Aug. 8, 2010

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

2 3

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 4)
by testbot＠testbot.winehq.org Aug. 7, 2010

Aug. 7, 2010

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=4348 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091 === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 4)
by testbot＠testbot.winehq.org Aug. 7, 2010

Aug. 7, 2010

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=4345 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057 visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091

1 0

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 4)
by testbot＠testbot.winehq.org Aug. 7, 2010

Aug. 7, 2010

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=4344 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: user32: Don't crash for unknown button styles
by Nikolay Sivov Aug. 7, 2010

Aug. 7, 2010

On 8/6/2010 22:22, André Hentschel wrote: > got that case with an MFC application which had a 3state radiobutton with buttonstyle 15(decimal) > with this fix everything is fine as the painting of the button is handled elsewhere, without that fix it crashes as it reads bad data behind the array. > > --- > dlls/user32/button.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/user32/button.c b/dlls/user32/button.c > index 54d54dc..4f629f0 100644 > --- a/dlls/user32/button.c > +++ b/dlls/user32/button.c > @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG window_style ) > /* paint a button of any type */ > static inline void paint_button( HWND hwnd, LONG style, UINT action ) > { > - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) > + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& IsWindowVisible(hwnd)) > { > HDC hdc = GetDC( hwnd ); > btnPaintFunc[style]( hwnd, hdc, action ); This needs a test to see what happens visually for style 0xf, maybe we need just to duplicate an entry in paint function table; also while you're at it: static inline UINT get_button_type( LONG window_style ) { return (window_style & 0x0f); } here BS_TYPEMASK should be used instead of 0xf.

2 4

Re: Configuring with -Werror
by André Hentschel Aug. 7, 2010

Aug. 7, 2010

> Configuring with -Werror used to work a while back for me; now that > -Wno-unused-result has been fixed I gave it another try and got this: > > configure: libxrandr 32-bit development files not found, XRandr won't > be supported. > configure: WARNING: Old Mesa headers detected. Consider upgrading your > Mesa libraries. > OpenGL and Direct3D won't be supported. > configure: WARNING: No sound system was found. Windows applications > will be silent. > > After a quick investigation, turns out many configure checks produce > warnings; patch below hacks around it, but I've never dealt with > configure before and apparently fixes need to go in configure.ac -- > anyone wants to give it a proper shot? Sorry for the noise on wine-patches, this should have been gone here... Patch looks ok, but that should only be changed in configure.ac... And the chance to get that in is not very high because AJ not always suppports different compilerflags. -- Best Regards, André Hentschel

1 0

Wine 1.3 packaged for Ubuntu, must be installed explicitly
by Scott Ritchie Aug. 7, 2010

Aug. 7, 2010

I have added a new series of Wine 1.3 packages to the Wine PPA: https://launchpad.net/~ubuntu-wine/+archive/ppa These are for 10.04 (Lucid) only and must be explicitly installed: sudo apt-get install wine1.3 Users who simply install the wine or wine1.2 packages (as in, all existing users) will instead get the stable Wine 1.2 release, which is still packaged there. Thanks, Scott Ritchie

1 0

Configuring with -Werror
by Jerome Leclanche Aug. 7, 2010

Aug. 7, 2010

Configuring with -Werror used to work a while back for me; now that -Wno-unused-result has been fixed I gave it another try and got this: configure: libxrandr 32-bit development files not found, XRandr won't be supported. configure: WARNING: Old Mesa headers detected. Consider upgrading your Mesa libraries. OpenGL and Direct3D won't be supported. configure: WARNING: No sound system was found. Windows applications will be silent. After a quick investigation, turns out many configure checks produce warnings; patch below hacks around it, but I've never dealt with configure before and apparently fixes need to go in configure.ac -- anyone wants to give it a proper shot? Jerome L. diff --git a/configure b/configure index 05a9317..ae29fe4 100755 --- a/configure ++ J. Leclanche / Adys+ b/configure @@ -8430,7 +8430,7 @@ int main () { static typeof(XRRSetScreenConfigAndRate) * func; - ; + if(func); return 0; } _ACEOF @@ -8685,7 +8685,7 @@ int main () { GLenum test = GL_UNSIGNED_SHORT_5_6_5; - ; + if(test); return 0; } _ACEOF @@ -10517,8 +10517,8 @@ if test "x$ac_cv_lib_asound_snd_pcm_hw_params_get_access" = x""yes; then : int main () { -int ret = snd_pcm_hw_params_get_access(NULL, NULL) - ; +int ret = snd_pcm_hw_params_get_access(NULL, NULL); + if(ret); return 0; } _ACEOF

1 0

Re: Wine users with a CD-ROM drive, please test
by Erik Inge Bolsø Aug. 6, 2010

Aug. 6, 2010

No failures on my winxp laptop. No mixed cd handy, so only audio cd tested. mcicda.c:270: CD length 73:35:54 mcicda.c:325: track #1 length 35694ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:25s:41frames mcicda.c:418: last track position: 69m:12s:13frames mcicda: 102 tests executed (0 marked as todo, 0 failures), 1 skipped. -- -erik http://useofwords.blogspot.com/

1 1

Re: [PATCH 1/6] d3dx9_36/tests: Added HLSL test suite.
by Henri Verbeet Aug. 6, 2010

Aug. 6, 2010

On 5 August 2010 00:05, Travis Athougies <iammisc(a)gmail.com> wrote: > +#define CINTERFACE Why do you need this? > +#include <d3d9.h> d3d9.h should be implied by d3dx9.h > +#include <assert.h> > +#include <stdio.h> I don't think you need these either. > +struct vertex > +{ > + float x, y, z; > + float tx, ty; > +}; > + > +const struct vertex quad_vertices[4] = { > + {-1, -1, 0, 0, 1}, > + {-1, 1, 0, 0, 0}, > + {1, -1, 0, 1, 1}, > + {1, 1, 0, 1, 0} > +}; Those aren't floating point values. Also, please use consistent formatting. > +const struct vertex quad_vertices[4] = { ... > +static IDirect3DVertexBuffer9 *quad_geometry; > +static IDirect3DVertexShader9 *vshader_passthru; > +static IDirect3DVertexDeclaration9 *vdeclaration; > +static IDirect3DDevice9 *device; Why is all of that global? > + hres = IDirect3D9_CreateDevice(d3d9_ptr, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, D3DCREATE_HARDWARE_VERTEXPROCESSING, &present_parameters, &device_ptr); Please break long lines. I realize this particular one is probably somehow my fault because I added it back in 2005 with c26ad82e75e408c302c21228ef08c1af0482326c, and everyone has been (blindly) copying it since, but there are other examples like setup_device() as well. Use 120 as maximum line length, 100 to be safe. > + hres = IDirect3DVertexBuffer9_Lock(quad_geometry, 0, sizeof(quad_vertices), (void**)&temp_geometry_vertices, 0); You don't need that cast. > + hres = D3DXCompileShader(vshader_passthru_hlsl, strlen(vshader_passthru_hlsl), > + NULL, NULL, "vshader", "vs_1_1", 0, > + &compiled, &errors, 0); > + if(FAILED(hres)) > + { > + vshader_passthru = NULL; That doesn't make sense, vshader_passthru is already NULL at that point. > + hr = D3DXCompileShader(shader, strlen(shader), > + NULL, NULL, "test", profile, > + 0, &compiled, &errors, constants); > + ok (hr == D3D_OK, "Pixel shader %s compilation failed: %s\n", shader, (char*) (errors?ID3DXBuffer_GetBufferPointer(errors):"")); This casts away const. > diff --git a/include/d3dx9shader.h b/include/d3dx9shader.h > index c8380bc..c54d27c 100644 > --- a/include/d3dx9shader.h > +++ b/include/d3dx9shader.h > @@ -296,6 +296,17 @@ HRESULT WINAPI D3DXAssembleShader(LPCSTR data, > LPD3DXBUFFER* shader, > LPD3DXBUFFER* error_messages); > > +HRESULT WINAPI D3DXCompileShader(LPCSTR src_data, > + UINT data_len, > + const D3DXMACRO* defines, > + LPD3DXINCLUDE include, > + LPCSTR function_name, > + LPCSTR profile, > + DWORD flags, > + LPD3DXBUFFER* shader, > + LPD3DXBUFFER* error_messages, > + LPD3DXCONSTANTTABLE* constant_table); > + This should be in a separate patch. The patch has some more issues, they shouldn't be hard to spot.

1 0

Re: [PATCH 2/5] gameux: Add stub of IGameStatisticsMgr implementation (try 2)
by Nikolay Sivov Aug. 6, 2010

Aug. 6, 2010

On 8/3/2010 13:58, Mariusz Pluciński wrote: > --- > dlls/gameux/Makefile.in | 1 + > dlls/gameux/factory.c | 5 ++ > dlls/gameux/gamestatistics.c | 153 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/gameux/gameux_private.h | 1 + > dlls/gameux/regsvr.c | 9 +++ > 5 files changed, 169 insertions(+), 0 deletions(-) > create mode 100644 dlls/gameux/gamestatistics.c > + TRACE("(%p, %s, 0x%x, %p, %p)\n", iface, debugstr_w(GDFBinaryPath), openType, pOpenResult, ppiStats); > + FIXME("stub\n"); > + return E_NOTIMPL; No need for duplicated traces, add one FIXME with full parameter output in it.

3 3

The WineAPI wiki.
by Max TenEyck Woodbury Aug. 6, 2010

Aug. 6, 2010

I have started the WineAPI wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php?title=Main_Page Some issues have come up that may need to be discussed here. In particular, there is going to be an 'Overview' section for many articles and I think the information to fill it in should come from the wine source tree. Specifically, I'd like to create 'Overview.wiki' files to contain this information. - Max

3 12

Wine users with a CD-ROM drive, please test
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 6, 2010

Aug. 6, 2010

Hi, this is my second call for participation, as only Jeff Zaroyko responded to the first one. I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). Wine's testbot job #4330 at https://testbot.winehq.org/JobDetails.pl?Key=4330 contains both a patch and binary of what I'd initially want to test about mcida.dll, solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. Please download the executable or compile the patch and execute it in MS-Windows: mcicda_test.exe mcicda mcicda.c:270: CD length 69:23:66 mcicda.c:325: track #1 length 989547ms mcicda.c:375: track #1 length: 16m:29s:41frames mcicda.c:410: last track length: 03m:28s:19frames mcicda.c:418: last track position: 65m:57s:47frames mcicda: 112 tests executed (0 marked as todo, 0 failures), 0 skipped. BTW, I wrote patches to make all these tests succeed in Wine. Before submission, I'd appreciate some more test data. Thank you for your participation, Jörg Höhle

3 3

Re: wiki slightly broken still?
by David Gerard Aug. 6, 2010

Aug. 6, 2010

[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.

2 1

[PATCH 5/6] d3dx9_36/tests: Added trigonometric functions test to HLSL test suite
by Joris Huizer Aug. 5, 2010

Aug. 5, 2010

Hello Travis Athougies, In this patch, you have this code: + void *ret = NULL; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); + for(i = 0;i < 32;i++) { //... + memcpy((void*) (((DWORD) ret) + (4 * i)), lr.pBits, 4); //... + } I'm not sure, but I think this will cause 64-bit issues (truncating to a 32-bit value?) Even if it doesn't, it seems simpler (more readable) to use a char pointer instead of a void pointer, like + char *ret; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); //... + memcpy(ret + (4 * i), lr.pBits, 4); HTH, regards, Joris

2 1

GDB debugging on ARM
by André Hentschel Aug. 4, 2010

Aug. 4, 2010

Hi, what is the best/easiest/fastest way to hack Wine so it does not start winedbg and i can debug it with gdb? my problem is that my WineARM works so far that it tries to run winedbg and uses its own handlers. but i want that not to happen of course it crashes somewhere and then tries to start winedbg... but winedbg is not really implemented yet on arm and its not yet time for it. i just want to debug on assembler level with gdb... "winedbg --gdb" is also not what i want. So my understanding is that Wine somewhere register its exception handlers, but i cant find that code to disable it. Anyone? -- Best Regards, André Hentschel

2 1

Re: [PATCH 07/10] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 3)
by Stefan Dösinger Aug. 4, 2010

Aug. 4, 2010

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)

2 1

Vacation
by Alexandre Julliard Aug. 4, 2010

Aug. 4, 2010

Folks, I'll be on vacation until the end of next week, so there won't be any commits for a while. That shouldn't prevent anybody from making progress, as we have seen during the recent code freeze ;-) The next release will be on Friday 20th. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)
by Alexandre Julliard Aug. 4, 2010

Aug. 4, 2010

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

4 3

Re: shdocvw: Add the Polish translation
by Jacek Caban Aug. 4, 2010

Aug. 4, 2010

On 8/4/10 5:45 PM, Łukasz Wojniłowicz wrote: > From: Lukasz Wojnilowicz<Wojnilowicz(a)localhost.localdomain> > > --- > dlls/shdocvw/Makefile.in | 1 + > dlls/shdocvw/Pl.rc | 57 ++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 58 insertions(+), 0 deletions(-) > create mode 100644 dlls/shdocvw/Pl.rc > > diff --git a/dlls/shdocvw/Makefile.in b/dlls/shdocvw/Makefile.in > index 9e2d8e1..f43e02e 100644 > --- a/dlls/shdocvw/Makefile.in > +++ b/dlls/shdocvw/Makefile.in > @@ -35,6 +35,7 @@ RC_SRCS = \ > Ko.rc \ > Lt.rc \ > Nl.rc \ > + Pl.rc \ > Ro.rc \ > Sv.rc \ > Uk.rc \ > diff --git a/dlls/shdocvw/Pl.rc b/dlls/shdocvw/Pl.rc > new file mode 100644 > index 0000000..1dd735b > --- /dev/null > +++ b/dlls/shdocvw/Pl.rc > @@ -0,0 +1,57 @@ > +/* > + * Copyright 2010 �ukasz Wojni�owicz > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "resource.h" > + > +LANGUAGE LANG_POLISH, SUBLANG_DEFAULT > + > +IDD_BROWSE_OPEN DIALOG 10, 10, 200, 70 > +STYLE DS_MODALFRAME | WS_CAPTION > +CAPTION "Otw�rz URL" > +FONT 8, "MS Shell Dlg" > +{ > + LTEXT "Podaj adres URL, kt�ry chcesz otworzy� w Internet Explorer",-1,25, 5, 150,15 It should be "(...) Internet Explorerze". > + LTEXT "Otw�rz:", -1, 2, 32, 20, 15 > + EDITTEXT IDC_BROWSE_OPEN_URL, 25, 30, 160, 13 > + DEFPUSHBUTTON "&OK", IDOK, 25, 50, 50, 15 > + PUSHBUTTON "&Anuluj", IDCANCEL, 85, 50, 50, 15 > +} > + > +IDR_BROWSE_MAIN_MENU MENU > +{ > + POPUP "&Plik" > + { > + POPUP "&Nowe" > + { > + MENUITEM "&Okno" ID_BROWSE_NEW_WINDOW > + } > + MENUITEM "&Otw�rz...", ID_BROWSE_OPEN > + MENUITEM "&Zapisz", ID_BROWSE_SAVE > + MENUITEM "Zapisz&jako...", ID_BROWSE_SAVE_AS > + MENUITEM SEPARATOR > + MENUITEM "Wydrukuj&format...", ID_BROWSE_PRINT_FORMAT It should be "Format wydruku". > + MENUITEM "&Drukuj...", ID_BROWSE_PRINT > + MENUITEM "Wydrukuj&podgl�d...", ID_BROWSE_PRINT_PREVIEW It should be "Podglad wydruku". Please be more careful about translations. ID_BROWSE_PRINT_FORMAT and ID_BROWSE_PRINT_PREVIEW are fairly obvious mistakes. Jacek

1 0

Re: shdocvw: Add the Polish translation
by Paul Vriens Aug. 4, 2010

Aug. 4, 2010

Hi Łukasz, On 08/04/2010 05:45 PM, Łukasz Wojniłowicz wrote: > +CAPTION "Otw�rz URL" This file needs the UTF-8 pragma. -- Cheers, Paul.

1 0

RE: WineTestBot and D3D
by Greg Geldorp Aug. 4, 2010

Aug. 4, 2010

> From: Stefan Doesinger > > Greg's testbot looks pretty useful by now, but for me it has one major > problem: It cannot run D3D tests because it is stuck in a virtual machine. > > I understand that the core of Winetestbot will stay in VMs, but is there a > way we can extend it with extra machines? I have a few spare boxes with > different GPUs here that could be used to run the tests. What I need is > basically: > > *) Some magic patchwatcher software I can install on these boxes > *) A Server this software talks to to get patch jobs and report the results > back. > *) Depending on the load, configure my machines to run d3d-related tests only > and leave others to the VMs. > > Now I guess it is important that if one of those extra test boxes dies(e.g. I > turn off my computers when I am away for a while) that this doesn't break the > testbot as a whole because it is waiting for test results. For starters I think > security is not that much of an issue, as long as I can firewall the machine > (via my router) and prevent it from connecting to anything but the testbot > master. > > Does the Testbot infrastructure allow this? Currently, no, it doesn't. But it certainly seems something that can be added. I'll investigate a bit what it will take. Ge.

1 0

Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx
by Alexandre Julliard Aug. 4, 2010

Aug. 4, 2010

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -37,8 +37,12 @@ > #include "winternl.h" > #include "wine/debug.h" > #include "wine/exception.h" > +#include "wine/unicode.h" > #include "ntdll_misc.h" > > +#include "winsock2.h" You don't want to include winsock2.h here. -- Alexandre Julliard julliard(a)winehq.org

1 0

WineTestBot and D3D
by Stefan Dösinger Aug. 4, 2010

Aug. 4, 2010

Hi, Greg's testbot looks pretty useful by now, but for me it has one major problem: It cannot run D3D tests because it is stuck in a virtual machine. I understand that the core of Winetestbot will stay in VMs, but is there a way we can extend it with extra machines? I have a few spare boxes with different GPUs here that could be used to run the tests. What I need is basically: *) Some magic patchwatcher software I can install on these boxes *) A Server this software talks to to get patch jobs and report the results back. *) Depending on the load, configure my machines to run d3d-related tests only and leave others to the VMs. Now I guess it is important that if one of those extra test boxes dies(e.g. I turn off my computers when I am away for a while) that this doesn't break the testbot as a whole because it is waiting for test results. For starters I think security is not that much of an issue, as long as I can firewall the machine(via my router) and prevent it from connecting to anything but the testbot master. Does the Testbot infrastructure allow this? Cheers, Stefan

1 0

Re: [PATCH 2/2 (resend)] shell32: Also compare UNIX realpaths in SHChangeNotify
by Alexandre Julliard Aug. 4, 2010

Aug. 4, 2010

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

2 3

Re: [PATCH 3/4] jscript: Fixed Error.toString implementation for non-Error this.
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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=4288 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

1 0

Re: user32: Protect from setting as a window owner one of window's succesors.
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

3 2

Re: [PATCH] kernel32/tests: Try harder to crash in the debugger test.
by Octavian Voicu Aug. 4, 2010

Aug. 4, 2010

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

1 0

shdocvw: Update Italian translation
by Luca Bennati Aug. 4, 2010

Aug. 4, 2010

2 1

Re: d3dx9_36/tests: Added HLSL test suite. (try 3)
by Henri Verbeet Aug. 4, 2010

Aug. 4, 2010

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.

1 0

Re: [PATCH 04/10] ddraw/tests: New visual back buffer flipping tests. (try 3)
by Stefan Dösinger Aug. 4, 2010

Aug. 4, 2010

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.

1 0

Re: [PATCH 09/10] ddraw: Add checking of SURFACEDESC type into CreateSurface methods. (try 3)
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

1 0

Re: [PATCH 08/10] ddraw: Allow attaching backbuffers and primaries. (try 3)
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

1 0

Re: [PATCH 07/10] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 3)
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

1 0

Re: tools/winebuild: add missing separators
by Andrew Nguyen Aug. 4, 2010

Aug. 4, 2010

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'

1 0

Re: [PATCH 04/10] ddraw/tests: New visual back buffer flipping tests. (try 3)
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

1 0

Re: [PATCH 03/10] ddraw/tests: Add test for NULL/bad size of surface caps in CreateSurface. (try 3)
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

1 0

Re: [PATCH] kernel32/tests: Try harder to crash in the debugger test.
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

1 0

Re: [PATCH 02/10] ddraw/tests: New attachment/flipping tests for back buffers. (try 3)
by testbot＠testbot.winehq.org Aug. 4, 2010

Aug. 4, 2010

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

1 0