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