- wine-devel - winehq.org

Re: Windows Imaging Component
by Kirill K. Smirnov 12 Aug '10

12 Aug '10

1 0

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.
by David Adam 12 Aug '10

12 Aug '10

Hello, some comments about this patch + if (hr != S_OK) return FALSE; + else return TRUE; could be simplified as return SUCCEEDED(hr); + trace("HRESULT when creating instance (%x)\n", hr); Since tests are assumed to pass, we dont care about debug informations. So, traces are useless in tests. [It is my opinion. Better developpers could give an opposite opinion] + todo_wine ok(*(ULONG *)pDirectMusicPort != 0, "IDirectMusicPort not set\n"); Why is this cast useful? A+ David 2010/8/9 Austin Lund <austin.lund(a)gmail.com> > > > > >

6 9

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)
by Vitaliy Margolen 12 Aug '10

12 Aug '10

On 08/11/2010 08:58 PM, Austin Lund wrote: > > > +static BOOL test_InitAudio(void) > +{ > + hr = IDirectMusicPerformance8_InitAudio(idmusicperformance,NULL,&pDirectSound,NULL,1,128,0x3f,NULL); > + if (hr != S_OK) return FALSE; > + else return TRUE; > +} Please put spaces after comas, as you do in the rest of the file. What are those magic numbers? Please use constants. If they are missing, add them to appropriate header file first. Same thing with return as in prior function.. > +static void test_PChannelInfo(void) Already covered in another thread. Vitaliy.

2 2

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance. (try 2)
by James McKenzie 12 Aug '10

12 Aug '10

Austin Lund wrote: Why the try2? It is always nice to put why you are doing this in the git commit notes. AJ is on vakay and will not be back until next week so there are NO reviews ongoing this week, except developer peer ones. James McKenzie

2 1

Re: [PATCH] qmgr/tests: Detect, when the service is disabled
by testbot＠testbot.winehq.org 11 Aug '10

11 Aug '10

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=4405 Your paranoid android. === W98SE (32 bit qmgr) === qmgr.c:46: Test failed: CoCreateInstance failed: 80040154

1 0

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

11 Aug '10

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 10 Aug '10

10 Aug '10

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 10 Aug '10

10 Aug '10

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 10 Aug '10

10 Aug '10

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 10 Aug '10

10 Aug '10

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 10 Aug '10

10 Aug '10

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 09 Aug '10

09 Aug '10

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 08 Aug '10

08 Aug '10

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 08 Aug '10

08 Aug '10

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 08 Aug '10

08 Aug '10

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 08 Aug '10

08 Aug '10

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 08 Aug '10

08 Aug '10

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 07 Aug '10

07 Aug '10

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 07 Aug '10

07 Aug '10

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 07 Aug '10

07 Aug '10

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 07 Aug '10

07 Aug '10

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 07 Aug '10

07 Aug '10

> 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 07 Aug '10

07 Aug '10

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 07 Aug '10

07 Aug '10

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ø 06 Aug '10

06 Aug '10

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 06 Aug '10

06 Aug '10

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 06 Aug '10

06 Aug '10

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 06 Aug '10

06 Aug '10

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 06 Aug '10

06 Aug '10

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 06 Aug '10

06 Aug '10

[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 05 Aug '10

05 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

> 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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

2 1

Re: d3dx9_36/tests: Added HLSL test suite. (try 3)
by Henri Verbeet 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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 04 Aug '10

04 Aug '10

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

Re: [PATCH 01/10] ddraw/tests: New CreateSurface for DDSCAPS_BACKBUFFER tests. (try 3)
by testbot＠testbot.winehq.org 04 Aug '10

04 Aug '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4245 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: regedit: Added Hebrew translation
by Alexandre Julliard 03 Aug '10

03 Aug '10

Yaron Shahrabani <sh.yaron(a)gmail.com> writes: > Hope everything is cool this time :) > +IDD_EXPORT_TEMPLATE DIALOG 50, 50, 278, 54 > +STYLE DS_3DLOOK | DS_CONTROL | WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS | > + WS_BORDER > +WS_EX_LAYOUTRTL > +FONT 8, "MS Shell Dlg" That's not valid syntax. Please try to compile at least the files you are changing, if you can't do a full build. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: [PATCH 2/4] include/shlobj.h: SHILCreateFromPath takes both CSTR and WSTR
by Alexandre Julliard 03 Aug '10

03 Aug '10

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

1 0

wiki slightly broken still?
by Dan Kegel 03 Aug '10

03 Aug '10

Creating new wiki pages seems broken today...

9 15

Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 3)
by Vitaliy Margolen 03 Aug '10

03 Aug '10

On 08/02/2010 05:48 PM, Jeff Cook wrote: > Moved check to conform with C90. > > + if (mastelem) { > + /* Master control */ ... > + } else { Please follow file's format. Vitaliy

1 0

Re: [PATCH 6/6] winealsa.drv: Open default device only once per card and don't discard non-defaults. (resend)
by Vitaliy Margolen 03 Aug '10

03 Aug '10

On 08/02/2010 05:50 PM, Jeff Cook wrote: > - > + You adding trailing spaces here. > + } else { > + default_used = 1; > } > Please follow files' format - curly braces go on separate line. Also you don't need braces for one line "else". Vitaliy.

1 0

Re: [PATCH 3/6] winealsa.drv: Always scan devices, even if a default device exists. (resend)
by Vitaliy Margolen 03 Aug '10

03 Aug '10

On 08/02/2010 05:49 PM, Jeff Cook wrote: > --- > dlls/winealsa.drv/waveinit.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) > > - int scan_devices = (fixedpcmdev == -1); > + /* we always want to scan_devices; otherwise, if a default is set and the > + appropriate registry keys are not set, only the default device will be seen > + by wine. This is undesirable, for instance, if you have separate cards for > + capture and playback, like a USB microphone for capture */ > + int scan_devices = 1; Please make it possible to force old behavior via registry. This was done for a reason - some devices were crashing during initialization, some were taking way too long to initialize. Vitaliy

1 0

Re: [5/5] wined3d: Fix NaN and Inf generation in msvc
by Henri Verbeet 03 Aug '10

03 Aug '10

On 31 July 2010 08:48, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This workaround isn't ideal, Yeah, I don't think this is much of an improvement.

4 4

Re: [PATCH 2/5] explorerframe/nstc: Create the treeview on initialization. (try 2)
by Alexandre Julliard 03 Aug '10

03 Aug '10

David Hedberg <david.hedberg(a)gmail.com> writes: > +static LRESULT resize_namespacetree(NSTC2Impl *This) > +{ > + RECT rc; > + TRACE("%p\n", This); > + > + GetClientRect(This->hwnd_main, &rc); > + SetWindowPos(This->hwnd_tv, HWND_TOP, rc.left, rc.top, > + rc.right, rc.bottom, SWP_SHOWWINDOW); Again, that's not the correct usage of SetWindowPos. You don't want to show or activate it. What you probably want is MoveWindow. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: GetVolumeInformationA: please test this on MS-Windows
by Andrew Eikum 03 Aug '10

03 Aug '10

On 07/29/2010 03:43 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Andrew, > >>Run on a Win98SE VM. The E drive is a CDROM drive. > Thank you very much for the result. I added the broken(GetLastError()) for Win9x > based on your data. > > Now is your chance to repeat the test with > https://testbot.winehq.org/JobDetails.pl?Key=4014 > (either as .patch file or the binary from testbot). > This is valuable because testbot skips most new tests, lacking another drive, > giving no proof that the fixed patch indeed works without errors on win9x. > If it fails, please report to wine-devel as I already submitted the new patch. Hi Jörg, No failures with the testbot executable. Run under the same Win98SE VM, again from the E: drive. Andrew

3 7

Re: [PATCH 04/10] ddraw/tests: New visual back buffer flipping tests. (try 2)
by testbot＠testbot.winehq.org 03 Aug '10

03 Aug '10

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=4179 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:3027: Test failed: got R FF G 00 B 00, expected R FF G FF B FF

2 1

Re: [PATCH 09/10] ddraw: Add checking of SURFACEDESC type into CreateSurface methods. (try 2)
by testbot＠testbot.winehq.org 03 Aug '10

03 Aug '10

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=4188 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 2)
by testbot＠testbot.winehq.org 03 Aug '10

03 Aug '10

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=4187 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:3027: Test failed: got R FF G 00 B 00, expected R FF G FF B FF === 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 2)
by testbot＠testbot.winehq.org 03 Aug '10

03 Aug '10

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=4186 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:3027: Test failed: got R FF G 00 B 00, expected R FF G FF B FF === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: [PATCH 2/5] ws2_32/tests: test ConnectEx
by Mike Kaplinskiy 03 Aug '10

03 Aug '10

On Mon, Aug 2, 2010 at 11:50 PM, Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> wrote: > --- > dlls/ws2_32/tests/sock.c | 227 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 227 insertions(+), 0 deletions(-) > Shoot, any chance you can just take #1 and take 2-5 from the first batch? That's an outdated not working version of the patches. Otherwise I'll resend tomorrow. Sorry, Mike.

1 0

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

03 Aug '10

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

1 0

Re: [PATCH 02/10] ddraw/tests: New attachment/flipping tests for back buffers. (try 2)
by testbot＠testbot.winehq.org 03 Aug '10

03 Aug '10

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

1 0

Re: [PATCH 01/10] ddraw/tests: New CreateSurface for DDSCAPS_BACKBUFFER tests. (try 2)
by testbot＠testbot.winehq.org 03 Aug '10

03 Aug '10

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

1 0

Re: shdocvw: Update French translation
by Frédéric Delanoy 03 Aug '10

03 Aug '10

Please discard; has been mangled by misconfigured git 2010/8/2 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > --- > dlls/shdocvw/Fr.rc | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/dlls/shdocvw/Fr.rc b/dlls/shdocvw/Fr.rc > index 94b4a7e..b7326bb 100644 > --- a/dlls/shdocvw/Fr.rc > +++ b/dlls/shdocvw/Fr.rc > @@ -55,6 +55,11 @@ IDR_BROWSE_MAIN_MENU MENU > MENUITEM SEPARATOR > MENUITEM "&Propriétés...", ID_BROWSE_PROPERTIES > } > + POPUP "&Favoris" > + { > + MENUITEM "&Ajouter aux favoris..." ID_BROWSE_ADDFAV > + MENUITEM SEPARATOR > + } > POPUP "&Aide" > { > MENUITEM "À &propos d'Internet Explorer...", ID_BROWSE_ABOUT > -- > 1.7.2 > >

1 0

Re: The WineAPI wiki.
by James Mckenzie 02 Aug '10

02 Aug '10

Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: >Sent: Aug 2, 2010 4:25 AM >To: wine-devel(a)winehq.org >Subject: Re: The WineAPI wiki. > >On 08/02/2010 07:00 AM, Dmitry Timoshkov wrote: >> Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: >> >>> I have started the WineAPI wiki at >>> >>> https://sourceforge.net/apps/mediawiki/wineapi/index.php?title=Main_Page >> >> You have chosen not very good name. There is no such a thing as Wine API, >> Wine implements Win32 API, and doesn't specify/add anything custom to it. >> The name "WineAPI" implies that Wine defines its own API which is not true, >> and is confusing. >> This should be named, the Windows32/Window64 API as implemented by Wine Documentation site. That is what it is. We have found shortcomings in the MSDN documentation (I'm dealing with this right now in one function call for Richedit.) This should be a collaborative site where Wine developers, Windows on Wine developers and others can place information on what Wine has implemented today, what needs to be implemented (with case code and discoveries) and what Wine cannot implement. >This has been discussed elsewhere on this mailing list. > Agreed. >There is a lot of information specific to Wine, particularly its >internal structure, that is not shared with Microsoft's product. >Further, there is a little confusing and incorrect information in the >Microsoft documentation. Bluntly, the Microsoft documentation is what >they want it to be. We need to document what it really is. > >We have tried to embed API documentation in the source code. That has >not worked as well as it could. Alexandre Julliard has said as much. I >think that having good documentation will help the project. Not having >good documentation can and does hurt Wine in my opinion. I also think >that trying to prevent the creation of that documentation might be >harmful. AJ has stated that documenting the Windows API and internal API calls should NOT be documented just in the source. It bloats the source code terribly and can make code unreadable. I agree that this Wiki should only be used to document the external interfaces to Wine as we implement Windows32/Windows64 API/ABI calls and what we have found in our testing that is different than MSDN. We should NOT duplicate MSDN where is is proper, but rather have a note that states MSDN and other sources have been found to be proper. As to the griping, we need to be public with our progress. This eliminates confusion and also gives new developers a place to start. James McKenzie

3 4

Latest version of ddraw/tests plus fixes
by Oldřich Jedlička 02 Aug '10

02 Aug '10

Hi Stefan, Roderick, I've sent my latest version of ddraw/tests plus some fixes right now (it takes some time to get to wine-patches ML), one of them fixes bug #9008. Unfortunately I don't have much spare time (and actually I didn't have it the whole time working on patches), my spare time is almost over now, so I would appreciate some last comments - what to remove (if there is something unacceptable), what to change. But I don't have more time to enhance the backbuffers+3D interaction investigations/tests, sorry. It would be great if you let the fix for bug #9008 go into the wine tree. Thanks! Regards, Oldřich.

1 0

Re: wordpad: Added Hebrew translation.
by Paul Vriens 02 Aug '10

02 Aug '10

Hi Yaron, On 08/01/2010 10:52 AM, Yaron Shahrabani wrote: > Alexander and Paul, please notice I added the EXSTYLE WS_EX_LAYOUTRTL > for the dialogs, hope that helps. > > Also found out that menus does not need any special RTL property, they > are self aligned according to the app. What do you mean by that? Running Wordpad in Hebrew still gives me LTR menu styles/justification. The global (per process) RTL settings still need to be implemented for our internal apps. > > Kind regards, > Yaron Shahrabani > > <Hebrew translator> > > > > 0002-wordpad-Added-Hebrew-translation.patch > > > From 8f5dfcb55656e7e4d7943d622234fb37753210f7 Mon Sep 17 00:00:00 2001 > From: Yaron Shahrabani<sh.yaron(a)gmail.com> > Date: Sun, 1 Aug 2010 11:48:23 +0300 > Subject: wordpad: Added Hebrew translation. > > --- > programs/wordpad/He.rc | 282 ++++++++++++++++++++++++++++++++++++++++++ > programs/wordpad/Makefile.in | 1 + > 2 files changed, 283 insertions(+), 0 deletions(-) > create mode 100644 programs/wordpad/He.rc > > diff --git a/programs/wordpad/He.rc b/programs/wordpad/He.rc > new file mode 100644 > index 0000000..091ec98 > --- /dev/null > +++ b/programs/wordpad/He.rc > @@ -0,0 +1,282 @@ > +/* > + * Copyright 2004 by Krzysztof Foltman > + * Hebrew Translation by Yaron Shahrabani<sh.yaron(a)gmail.com>, 2010 Minor, but why did you not use the same format (as we see in most files)? So something like: /* * Hebrew Translation of wordpad * * Copyright 2004 by Krzysztof Foltman * Copyright 2010 Yaron Shahrabani<sh.yaron(a)gmail.com> > +IDD_DATETIME DIALOG 30, 20, 130, 80 > +STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU > +EXSTYLE WS_EX_LAYOUTRTL Eventually we probably have to but I'm not sure what Alexandre thinks about introducing it (now). We probably also have to teach our tools (like the translation site) that detects translation differences/issues to cope with this. > +STRINGTABLE > +BEGIN > + STRING_ALIGN_LEFT, "שמאל" > + STRING_ALIGN_RIGHT, "ימין" > + STRING_ALIGN_CENTER, "מרכז" > +END This piece is already defined starting on line 226 and thus leads to: ../../../wine-git/programs/wordpad/He.rc:279:32: Error: Stringtable ID 1416 already in use -- Cheers, Paul.

3 4

Re: write: Added Hebrew translation
by Paul Vriens 02 Aug '10

02 Aug '10

On 08/02/2010 04:57 PM, Yaron Shahrabani wrote: > +++ b/programs/write/He.rc > @@ -0,0 +1,30 @@ > +/* > + * English language support Should be 'Hebrew' of course ;) -- Cheers, Paul.

2 1

Re: [PATCH 1/4] wined3d: separate driver info from GPU info
by Henri Verbeet 02 Aug '10

02 Aug '10

On 1 August 2010 05:37, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > struct driver_version_information > { > + WORD vendor; /* reported PCI card vendor ID */ ... > + enum wined3d_display_driver driver; > +}; That doesn't make all that much sense.

2 1

Re: winex11.drv: implement drag and drop from X to OLE (try 3)
by Alexandre Julliard 02 Aug '10

02 Aug '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -300,6 +499,66 @@ static void X11DRV_XDND_ResolveProperty(Display *display, Window xwin, Time tm, > wine_tsx11_unlock(); > } > > + /* We get the list of formats in descending order of preference, yet the linked > + * list is a stack so the order is inverted. Reverse the linked list here so > + * that we get the right order. > + */ > + current = XDNDData; You should first convert it to a standard Wine list, then you can use it in either order. > + /* For some strange reason, load-time linking SHELL32.DLL to WINEX11.DRV > + * causes wine to segfault on startup. So rather use run-time linking. > + */ > + shell32 = GetModuleHandleA("SHELL32.DLL"); > + if (shell32 == NULL) > + shell32 = LoadLibraryA("SHELL32.DLL"); A delayed import should work fine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11.drv: implement X session management (try 2)
by Alexandre Julliard 02 Aug '10

02 Aug '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > +static void SM_Init(void) > +{ > + CreateThread(NULL, 0, manage_session, NULL, 0, NULL); > +} > +#endif /* defined(SONAME_LIBSM) */ You don't want to create a new thread in every process for this. It will cause lots of trouble. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 07/10] explorerframe/nstc: Implement Initialize.
by Alexandre Julliard 02 Aug '10

02 Aug '10

David Hedberg <david.hedberg(a)gmail.com> writes: > + /* Native accepts a NULL prc, so should we. */ > + if(prc) > + SetWindowPos(This->hwnd_main, HWND_TOP, prc->left, prc->top, > + prc->right - prc->left, prc->bottom - prc->top, SWP_SHOWWINDOW); It would be better to create it directly with the correct rectangle. Also SWP_SHOWWINDOW is not useful since the window is created visible. And please don't add comments like "native does this", that should be true of pretty much anything we do. Native behavior should be documented by test cases anyway, not comments. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32: Partial implementation of IShellItem::BindToHandler.
by Nikolay Sivov 02 Aug '10

02 Aug '10

On 8/2/2010 02:36, David Hedberg wrote: > +static HRESULT ShellItem_get_shellfolder(ShellItem *This, IBindCtx *pbc, IShellFolder **ppsf) > +{ > + IShellFolder *desktop; > + HRESULT ret; > + > + ret = SHGetDesktopFolder(&desktop); > + if (SUCCEEDED(ret)) > + { > + if (_ILIsDesktop(This->pidl)) > + { > + *ppsf = desktop; > + IShellFolder_AddRef(*ppsf); > + } > + else > + { > + ret = IShellFolder_BindToObject(desktop, This->pidl, pbc,&IID_IShellFolder, (void**)ppsf); > + } > + > + IShellFolder_Release(desktop); > + } > + > + return ret; > +} > + > I don't think this explicit check for desktop folder is needed here, as I understand ::BindToObject() it should handle this case internally.

2 4

Re: [PATCH 1/5] include/mswsock: add WS_ prefix if necessary
by Alexandre Julliard 02 Aug '10

02 Aug '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > @@ -173,11 +174,28 @@ typedef BOOL (WINAPI * LPFN_TRANSMITFILE)(SOCKET, HANDLE, DWORD, DWORD, LPOVERLA > typedef BOOL (WINAPI * LPFN_TRANSMITPACKETS)(SOCKET, LPTRANSMIT_PACKETS_ELEMENT, DWORD, DWORD, LPOVERLAPPED, DWORD); > typedef INT (WINAPI * LPFN_WSARECVMSG)(SOCKET, LPWSAMSG, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > typedef INT (WINAPI * LPFN_WSASENDMSG)(SOCKET, LPWSAMSG, DWORD, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > +#else > +typedef BOOL (WINAPI * LPFN_ACCEPTEX)(SOCKET, SOCKET, PVOID, DWORD, DWORD, DWORD, LPDWORD, LPOVERLAPPED); > +typedef BOOL (WINAPI * LPFN_CONNECTEX)(SOCKET, const struct WS_sockaddr *, int, PVOID, DWORD, LPDWORD, LPOVERLAPPED); > +typedef BOOL (WINAPI * LPFN_DISCONNECTEX)(SOCKET, LPOVERLAPPED, DWORD, DWORD); > +typedef VOID (WINAPI * LPFN_GETACCEPTEXSOCKADDRS)(PVOID, DWORD, DWORD, DWORD, struct WS_sockaddr **, LPINT, struct WS_sockaddr **, LPINT); > +typedef BOOL (WINAPI * LPFN_TRANSMITFILE)(SOCKET, HANDLE, DWORD, DWORD, LPOVERLAPPED, LPTRANSMIT_FILE_BUFFERS, DWORD); > +typedef BOOL (WINAPI * LPFN_TRANSMITPACKETS)(SOCKET, LPTRANSMIT_PACKETS_ELEMENT, DWORD, DWORD, LPOVERLAPPED, DWORD); > +typedef INT (WINAPI * LPFN_WSARECVMSG)(SOCKET, LPWSAMSG, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > +typedef INT (WINAPI * LPFN_WSASENDMSG)(SOCKET, LPWSAMSG, DWORD, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > +#endif What you want is the WS() macro. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/5] shdocvw: Recurse into directories when adding Favorites
by Alexandre Julliard 02 Aug '10

02 Aug '10

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > @@ -109,10 +109,10 @@ static void add_fav_to_menu(HMENU menu, LPWSTR title, LPCWSTR url) > { > MENUITEMINFOW item; > /* Subtract the number of standard elements in the Favorites menu */ > - INT favcount = GetMenuItemCount(menu) - 2; > + static INT favcount; > LPWSTR urlbuf; The previous version was better, you don't want a static variable for this, you may want to do it multiple times, or the menu may get changed somewhere else. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mshtml: Send more informative messages to OleInPlaceFrame
by Jacek Caban 02 Aug '10

02 Aug '10

On 08/02/10 13:30, Alexander Nicolaysen Sørnes wrote: > These are displayed in Internet Explorer. > > > Alexander N. Sørnes > +LPCWSTR get_statustext(INT id, BOOL has_arg, LPCWSTR arg_in) WHy do you need has_arg argument? Isn't NULL arg_in enough to recognize no argument? +{ + static LPWSTR strings[NUM_STATUS_STRINGS]; + int index = id - IDS_STATUS_DONE; + DWORD maxlen = 255; + DWORD len = maxlen; + LPWSTR* p = &strings[index]; + + if(!*p) + { + if(has_arg) + len *= 3; + + *p = heap_alloc(len * sizeof(WCHAR)); + len = LoadStringW(hInst, id, *p, len); + len++; + + if(!has_arg) + *p = heap_realloc(*p, len * sizeof(WCHAR)); + } + + if(has_arg) + { + LPWSTR p2 = strings[index] + maxlen; + LPCWSTR arg = arg_in; + + if(!arg) + { + const WCHAR empty = 0; + arg = ∅ + ERR("Missing arg for message (id=%d) '%s'\n", id, debugstr_w(strings[index])); + } + snprintfW(p2, (maxlen * 2) - 1, strings[index], arg); + + return p2; + } + + return *p; +} This caching mechanism is broken and not thread safe. + LPCWSTR text = get_statustext(IDS_STATUS_DONE, FALSE, NULL); + IOleInPlaceFrame_SetStatusText(doc_obj->frame, text); The helper function should take care of calling SetStatusText. if(doc->frame) - IOleInPlaceFrame_SetStatusText(doc->frame, NULL /* FIXME */); + { + LPCWSTR text = get_statustext(IDS_STATUS_DOWNLOADINGFROM, TRUE, task->url); + CoTaskMemFree(task->url); + IOleInPlaceFrame_SetStatusText(doc->frame, text); + } You leak task->url here if doc->frame is NULL. Jacek

1 0

Re: [PATCH 4/4] jscript: Use generic property for Error.number.
by testbot＠testbot.winehq.org 02 Aug '10

02 Aug '10

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=4153 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: [PATCH 3/4] jscript: Fixed test crash on some win9x installations.
by testbot＠testbot.winehq.org 02 Aug '10

02 Aug '10

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=4152 Your paranoid android. === WNT4WSSP6 (32 bit jscript) === jscript.c:388: Test failed: CoCreateInstance failed: 80040154 jscript.c:468: Test failed: CoCreateInstance failed: 80040154

1 0

Re: [PATCH 2/4] jscript: Use generic properties for NaN and Infinity implementation.
by testbot＠testbot.winehq.org 02 Aug '10

02 Aug '10

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=4151 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: gdi32: Do not crash on an invalid pointer passed to AddFontMemResourceEx.
by testbot＠testbot.winehq.org 02 Aug '10

02 Aug '10

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=4149 Your paranoid android. === W98SE (32 bit font) === Failure running script in VM: Exceeded timeout limit of 315 sec === WNT4WSSP6 (32 bit font) === Timeout

1 0

Re: user32: Add a test for GetClassInfo, make it pass under Wine. Take 2.
by testbot＠testbot.winehq.org 01 Aug '10

01 Aug '10

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=4119 Your paranoid android. === WNT4WSSP6 (32 bit class) === class.c:939: Test failed: expected ERROR_NOACCESS, got -559038737

1 0

New winetricks 20100731: new verbs eadm eufonts gfw glut ie8 safari secur32 xlive
by Dan Kegel 01 Aug '10

01 Aug '10

Another month, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes: Austin English: New verbs eadm eufonts gfw (aka xlive) ie8 safari secur32 Turning off MouseWarpOverride should be 'disable' not 'disabled'. (Issue 138) flash, ogg: support silent installs Lots of updates and minor fixes Dan Kegel: New verb glut Mathieu Malaterre: update cmake to 2.8.2 (issue 136)

2 2

New wisotool 20100731: 44 new verbs (aa3, apb, ... masseffect2_demo, ... zen_of_sudoku_demo_steam)
by Dan Kegel 01 Aug '10

01 Aug '10

wisotool is a handy winetricks-like script for automatically installing games from .iso files copied from your own dvds (or, if the game is freely downloadable, it will download it). Just like winetricks, it is intended to make testing Wine easier, but might be useful for people who simply want to install games. Unlike winetricks, wisotool is quiet by default; it doesn't ask any questions (except it prompts for your password so it can mount the .iso file, and it prompts you to insert the disk if the .iso file is not found). Wisotool currently supports about 145 games and/or benchmarks (see below). Please consider contributing support for your favorite game, it's not (too) hard. Thanks to everyone who contributed changes for this release. Not all of these games currently work under wine. Workarounds for specific Wine bugs are applied if available. Wisotool is available at http://kegel.com/wine/wisotool You can read more about it at http://wiki.winehq.org/wisotool Please report bugs via http://code.google.com/p/winezeug/issues/ Changes since version 20100618: Austin English If iso isn't present, offer to make one for the user Generic Steam installer New verbs: aa3 (America's Army 3) apb (All Points Bulletin) arx_fatalis_demo_steam bookworm_adventures_deluxe_demo_steam daytona_usa_evolutions dc2ba (Dora's Carnival 2: Boardwalk Adventure) eets_demo_steam fallout3_goty (Fallout 3: Game of the Year edition) ffxivbench (Final Fantasy XIV benchmark) fifa10 fifa10_demo joint_task_force_demo_steam longest_journey_demo_steam lost_planet_dx10_demo_steam lost_planet_dx9_demo_steam metro2033 multiwinia_demo_steam napoleon_total_war_demo_steam painkiller_demo_steam sega_rally_2 singularity ssdd2 (SpongeBob SquarePants Diner Dash 2 Demo) starcraft2 total_war_and_empire_demo_steam twfc (Transformers: War for Cybertron) wowtrial (World of Warcraft trial) zen_of_sudoku_demo_steam Dan Kegel: Allow specifying a .verb file on commandline New verbs: algodoo_demo deadspace lotsn (Monkey Island: Launch of the Screaming Narwhal) masseffect2_demo secondlife_beta Eleazar Galano: New verbs: cnc3_demo (Command and Conquer 3 Demo) cnc4 fifaonline3_beta hphbp, hphbp_demo (Harry Potter Half Blood Prince) lhp (Lego Harry Potter) moh_beta (Medal of Honor) nfsshift nfsshift_demo oblivion sf4bench Jon Angelo: New verb hod3_jp_demo Thai Nguyen: New verb smbx

1 0

Re: [2/2] Try2: imagehlp: Implement ImageGetDigestStream
by Paul Vriens 31 Jul '10

31 Jul '10

Hi Andrey, On 07/18/2010 12:39 PM, Andrey Turkin wrote: > +static BOOL IMAGEHLP_ReportImportSection( IMAGE_SECTION_HEADER *hdr, > + DWORD num_sections, BYTE *map, DWORD fileSize, DWORD DigestLevel, > + DIGEST_FUNCTION DigestFunction, DIGEST_HANDLE DigestHandle ) > +{ > + BOOL ret = FALSE; > + DWORD offset, size, base; > + PBYTE import; import is defined here but not used any further down the line. > + > + /* Get import data */ > + offset = IMAGEHLP_GetSectionOffset( hdr, num_sections, ".idata",&size, > +&base ); > + if( !offset ) > + return FALSE; > + > + /* If CERT_PE_IMAGE_DIGEST_ALL_IMPORT_INFO is set, the entire > + * section is reported. Otherwise, the debug info section is > + * decoded and reported piecemeal. See tests. However, I haven't been > + * able to figure out how the native implementation decides which values > + * to report. Either it's buggy or my understanding is flawed. > + */ > + if( DigestLevel& CERT_PE_IMAGE_DIGEST_ALL_IMPORT_INFO ) > + ret = IMAGEHLP_ReportSectionFromOffset( offset, size, map, fileSize, > + DigestFunction, DigestHandle ); > + else > + { > + FIXME("not supported except for CERT_PE_IMAGE_DIGEST_ALL_IMPORT_INFO\n"); > + SetLastError(ERROR_INVALID_PARAMETER); > + ret = FALSE; > + } > + HeapFree( GetProcessHeap(), 0, import ); Only freed. Can 'import' be removed? Coverity complained. -- Cheers, Paul.

1 0

Re: d3dx9: D3DXCreateMeshFVF
by Misha Koshelev 31 Jul '10

31 Jul '10

> Instead of implementing D3DXCreateMeshFVF, wouldn't it be better to > implement D3DXCreateMesh and call the latter from D3DXCreateMeshFVF by > previously using D3DXDeclaratorFromFVF? > > D3DXCreateMeshFVF would be pretty straight then: > 1. get the const LPD3DVERTEXELEMENT9 *pDeclaration from the supplied FVF > 2. call D3DXCreateMesh > > BTW, D3DXGetFVFVertexSize could then also be forwarded to > D3DXGetDeclVertexSize and the code simplified. Thank you Thank you. Yes indeed this is the approach that has been recommended by Henri Verbeet as well. Specifically, after the D3DXCreateSphere patch (in some form) is applied to git: http://bugs2.winehq.org/attachment.cgi?id=29947 You can see two patches for tests here: http://bugs2.winehq.org/attachment.cgi?id=29948 http://bugs2.winehq.org/attachment.cgi?id=29949 The only caveat is that we must first implement D3DXFVFFromDeclarator at the very least, as the CreateIndexBuffer call must be (to my understanding) supplied an FVF. Thank you Misha

1 1

d3dx9: D3DXCreateMeshFVF
by Luis Buquets 31 Jul '10

31 Jul '10

Instead of implementing D3DXCreateMeshFVF, wouldn't it be better to implement D3DXCreateMesh and call the latter from D3DXCreateMeshFVF by previously using D3DXDeclaratorFromFVF? D3DXCreateMeshFVF would be pretty straight then: 1. get the const LPD3DVERTEXELEMENT9 *pDeclaration from the supplied FVF 2. call D3DXCreateMesh BTW, D3DXGetFVFVertexSize could then also be forwarded to D3DXGetDeclVertexSize and the code simplified.

1 0

Re: [PATCH] d3dx9_36/tests: Added HLSL test suite. (Try 2)
by testbot＠testbot.winehq.org 31 Jul '10

31 Jul '10

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=4080 Your paranoid android. === WXPPROSP3 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W2K3R2SESP2 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === WVISTAADM (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W2K8SE (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W7PRO (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W7PROX64 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a No test summary line found === W7PROX64 (64 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086a Timeout

2 1

Re: [website] Wine 1.3.0 freigegeben
by Frédéric Delanoy 30 Jul '10

30 Jul '10

2010/7/30 André Hentschel <nerv(a)dawncrow.de>: > --- > news/de/2010073001.xml | 17 +++++++++++++++++ > 1 files changed, 17 insertions(+), 0 deletions(-) > create mode 100644 news/de/2010073001.xml > > -- > > Best Regards, André Hentschel I know you're sending the German translation, but patches commit logs should stay in English IMHO. Imagine everyone sending a log message with their own mother tongue... what would you do in you received a patch with a commit log in, say, Korean... Regards, Frédéric

1 0

Re: [5/9] msi: Set/unset the SourceDir property at the right stage in the execution sequence.
by Paul Vriens 30 Jul '10

30 Jul '10

Hi Hans, On 07/23/2010 09:42 AM, Hans Leidekker wrote: > + /* full UI, no ResolveSource action */ > + r = MsiInstallProductA(msifile, NULL); > + ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %u\n", r); Right about here I get a popup, waiting for 'OK' to be pushed, on Win95/98/Me that says "Test 14 failed". That does explain some of the timeouts we see on test.winehq.org for those platforms as of this patch. -- Cheers, Paul.

1 0

Re: [PATCH 5/5] gameux/tests: Add test of IGameExplorer2 creating
by testbot＠testbot.winehq.org 30 Jul '10

30 Jul '10

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=4065 Your paranoid android. === W98SE (32 bit gameexplorer) === gameexplorer.c:43: Test failed: IGameExplorer creating failed (result false) === WNT4WSSP6 (32 bit gameexplorer) === gameexplorer.c:43: Test failed: IGameExplorer creating failed (result false) === W2KPROSP4 (32 bit gameexplorer) === gameexplorer.c:43: Test failed: IGameExplorer creating failed (result false) === WXPPROSP3 (32 bit gameexplorer) === gameexplorer.c:43: Test failed: IGameExplorer creating failed (result false) === W2K3R2SESP2 (32 bit gameexplorer) === gameexplorer.c:43: Test failed: IGameExplorer creating failed (result false) === W2K8SE (32 bit gameexplorer) === gameexplorer.c:43: Test failed: IGameExplorer creating failed (result false)

1 0

Re: [PATCH 1/5] gameux/tests: Add test of IGameExplorer creating
by testbot＠testbot.winehq.org 30 Jul '10

30 Jul '10

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=4063 Your paranoid android. === W98SE (32 bit gameexplorer) === gameexplorer.c:42: Test failed: IGameExplorer creating failed (result false) === WNT4WSSP6 (32 bit gameexplorer) === gameexplorer.c:42: Test failed: IGameExplorer creating failed (result false) === W2KPROSP4 (32 bit gameexplorer) === gameexplorer.c:42: Test failed: IGameExplorer creating failed (result false) === WXPPROSP3 (32 bit gameexplorer) === gameexplorer.c:42: Test failed: IGameExplorer creating failed (result false) === W2K3R2SESP2 (32 bit gameexplorer) === gameexplorer.c:42: Test failed: IGameExplorer creating failed (result false) === W2K8SE (32 bit gameexplorer) === gameexplorer.c:42: Test failed: IGameExplorer creating failed (result false)

1 0

Re: [PATCH 5/9] mciqtz32: Fix window visibility
by Alexandre Julliard 30 Jul '10

30 Jul '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -757,15 +757,12 @@ static DWORD MCIQTZ_mciWindow(UINT wDevID, DWORD dwFlags, LPMCI_DGV_WINDOW_PARMS > return 0; > > if (dwFlags & MCI_DGV_WINDOW_HWND && (IsWindow(lpParms->hWnd) || !lpParms->hWnd)) { > - LONG style = 0; > TRACE("Setting hWnd to %p\n", lpParms->hWnd); > IVideoWindow_put_Visible(wma->vidwin, OAFALSE); > - IVideoWindow_get_WindowStyle(wma->vidwin, &style); > - style &= ~WS_CHILD; > if (lpParms->hWnd) > - IVideoWindow_put_WindowStyle(wma->vidwin, style|WS_CHILD); > + IVideoWindow_put_WindowStyle(wma->vidwin, WS_CHILD); > else > - IVideoWindow_put_WindowStyle(wma->vidwin, style); > + IVideoWindow_put_WindowStyle(wma->vidwin, 0); This doesn't look right. Why do you want to clear all the style bits? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shdocvw: Add Italian translation
by Paul Vriens 30 Jul '10

30 Jul '10

Hi Luca, You need to add the UTF-8 pragma: Warning: string "&Proprietà..." seems to be UTF-8 but codepage 1252 is in use. -- Cheers, Paul.

1 0

Creation of the Wine API wiki on SourceForge
by Max TenEyck Woodbury 30 Jul '10

30 Jul '10

A wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php has been created for documenting the API interface of WINE (as opposed to Microsoft Windows). It is in the planning stage at this point. - Max

1 0

[PATCH 3/9] mciqtz32: Fix mciSeek
by Joerg-Cyril.Hoehle＠t-systems.com 30 Jul '10

30 Jul '10

Maarten, @@ -331,16 +331,14 @@ static DWORD MCIQTZ_mciSeek(UINT wDevID, DWORD dwFlags, LPMCI_SEEK_PARMS lpParms - MCIQTZ_mciStop(wDevID, MCI_WAIT, NULL); is there a reason why you remove that? The MCI devices (mciwave, sequencer, avivideo, quartz with .avi, quartz with midi, quartz with .wav) all stop playing when seeking. How do you handle that in mciqtz? Is it delegated to the individual renderers? I don't see where. IIRC, I believe once found one exception but I can't remember where that was (perhaps mcicda? mcicda is quite a different beast, as it continues playing even after the application closes the device and exits, unlike the other MCI devices). Regards, Jörg Höhle

1 0

Re: shlwapi/tests: Fix some test failures on RTL enabled boxes
by testbot＠testbot.winehq.org 30 Jul '10

30 Jul '10

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=4059 Your paranoid android. === W98SE (32 bit ordinal) === ordinal.c:616: Test failed: GetShellSecurityDescriptor should fail, got 0096F808 === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1783: Test failed: got 13 ordinal.c:1789: Test failed: got 25 ordinal.c:1804: Test failed: got 10 ordinal.c:1817: Test failed: got 13 ordinal.c:1825: Test failed: got 13 ordinal.c:1847: Test failed: got 25 ordinal.c:1855: Test failed: got 37, length 38 ordinal.c:1866: Test failed: got 40 ordinal.c:1877: Test failed: got 23 ordinal.c:1888: Test failed: got 26 === W7PROX64 (32 bit ordinal) === ordinal.c:1789: Test failed: got 24 ordinal.c:1839: Test failed: got 24 ordinal.c:1847: Test failed: got 24 ordinal.c:1855: Test failed: got 33, length 34 ordinal.c:1866: Test failed: got 36 === W7PROX64 (64 bit ordinal) === ordinal.c:1783: Test failed: got 10 ordinal.c:1804: Test failed: got 7 ordinal.c:1817: Test failed: got 10 ordinal.c:1825: Test failed: got 10 ordinal.c:1855: Test failed: got 33, length 34 ordinal.c:1866: Test failed: got 36 ordinal.c:1877: Test failed: got 20 ordinal.c:1888: Test failed: got 23

1 0

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 5)
by Alexandre Julliard 30 Jul '10

30 Jul '10

Misha Koshelev <misha680(a)gmail.com> writes: > + for (i = 0; i < number_of_vertices; i++) > + { > + ok(compare_vec3(vertices[i].position, mesh->vertices[i].position), "Test %s, vertex position %d, result (%g, %g, %g), expected (%g, %g, %g)\n", name, i, vertices[i].position.x, vertices[i].position.y, vertices[i].position.z, mesh->vertices[i].position.x, mesh->vertices[i].position.y, mesh->vertices[i].position.z); > + ok(compare_vec3(vertices[i].normal, mesh->vertices[i].normal), "Test %s, vertex normal %d, result (%g, %g, %g), expected (%g, %g, %g)\n", name, i, vertices[i].normal.x, vertices[i].normal.y, vertices[i].normal.z, mesh->vertices[i].normal.x, mesh->vertices[i].normal.y, mesh->vertices[i].normal.z); Please add some line breaks occasionally. 100 chars is a reasonable limit, a bit more is tolerated, but 300 is too much. > + /* free lookup tables */ > + free_sincos_table(&phi); > + free_sincos_table(&theta); > + > + /* success */ > + return TRUE; There's no need for that sort of comments, the purpose of that code is obvious. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/5] WineD3D: Get rid of some C99 code
by Henri Verbeet 30 Jul '10

30 Jul '10

Please use http://www.winehq.org/pipermail/wine-patches/2010-July/091554.html instead. Also, the module name is wined3d.

1 0

Re: explorer: implement X session management
by Dmitry Timoshkov 30 Jul '10

30 Jul '10

Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Changelog: > * explorer: implement X session management Explorer should not have X11 as a dependency. This should be implemented inside of winex11.drv. -- Dmitry.

4 3

Re: [2/4] tools: enable .lnk thumbnailing in Gnome
by Alexandre Julliard 30 Jul '10

30 Jul '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > diff --git a/tools/Makefile.in b/tools/Makefile.in > index a9ec324..a0c9c99 100644 > --- a/tools/Makefile.in > +++ b/tools/Makefile.in > @@ -75,6 +75,8 @@ install install-lib:: wine.inf $(INSTALLDIRS) > $(INSTALL_DATA) $(SRCDIR)/l_intl.nls $(DESTDIR)$(datadir)/wine/l_intl.nls > $(INSTALL_DATA) $(SRCDIR)/wine.desktop $(DESTDIR)$(datadir)/applications/wine.desktop > -$(UPDATE_DESKTOP_DATABASE) > + gconftool --set -t string /desktop/gnome/thumbnailers/application@x-ms-shortcut/command "wine winemenubuilder -t %i %o" || true > + gconftool --set -t bool /desktop/gnome/thumbnailers/application@x-ms-shortcut/enable "true" || true There needs to be a better way of doing this. Probably filing a bug with freedesktop.org is in order. -- Alexandre Julliard julliard(a)winehq.org

6 8

Re: [PATCH] d3dx9_36/tests: Added HLSL test suite.
by testbot＠testbot.winehq.org 30 Jul '10

30 Jul '10

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=4052 Your paranoid android. === WXPPROSP3 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086ahlsl.c:104: this is the last test seen before the exception No test summary line found === W2K3R2SESP2 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086ahlsl.c:104: this is the last test seen before the exception No test summary line found === WVISTAADM (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086ahlsl.c:104: this is the last test seen before the exception No test summary line found === W2K8SE (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086ahlsl.c:104: this is the last test seen before the exception No test summary line found === W7PRO (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086ahlsl.c:104: this is the last test seen before the exception No test summary line found === W7PROX64 (32 bit hlsl) === hlsl.c:104: Test failed: Could not create device, IDirect3D9_CreateDevice returned: 8876086ahlsl.c:104: this is the last test seen before the exception No test summary line found === W7PROX64 (64 bit hlsl) === Timeout

1 0

Re: [1/2] richedit: Return correct values when EM_SETTEXTMODE fails.
by testbot＠testbot.winehq.org 30 Jul '10

30 Jul '10

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=4043 Your paranoid android. === W7PRO (32 bit editor) === editor.c:4702: Test failed: test paste: strcmp = 1, text='testing paste editor.c:4720: Test failed: test paste: strcmp = 1 editor.c:4732: Test failed: test paste: strcmp = -1 editor.c:4762: Test failed: test paste: strcmp = -1, actual = 'Ts' editor.c:5977: Test failed: Cursor is at 0 instead of 4 editor.c:5983: Test failed: Cursor is at 0 instead of 9 editor.c:5989: Test failed: Cursor is at 0 instead of 4 editor.c:6003: Test failed: Cursor is at 8 instead of 9 editor.c:6011: Test failed: Cursor is at 11 instead of 9 editor.c:6022: Test failed: Cursor is at 0 instead of 8 editor.c:6047: Test failed: Cursor is at 0 instead of 8

1 0

Re: [PATCH 3/4] ddraw: Allow creating back buffer for pre-DirectX 7 interfaces. (try 3)
by Stefan Dösinger 29 Jul '10

29 Jul '10

Am 22.07.2010 um 21:13 schrieb Oldřich Jedlička: > DirectX 1 interface allowed creation of explicit back buffers, so move the > restrictive checks to DirectX 2+ implementations. It is still missing testing/handling of AddAttachedSurface

3 3

Re: [PATCH] d3dx9_36/tests: Added HLSL test suite.
by David Adam 29 Jul '10

29 Jul '10

On a real Vista windows box, tests fail at line 372: test failed: sin: Got 2: unexpected values line 385:test failed: cos: Got 2: unexpected values A+ David

1 0

Re: [PATCH 3/8] explorerframe/nstc: Add host window and create a treeview.
by David Hedberg 29 Jul '10

29 Jul '10

On Thu, Jul 29, 2010 at 9:19 PM, David Hedberg <david.hedberg(a)gmail.com> wrote: > --- > dlls/explorerframe/explorerframe_main.h | 3 + > dlls/explorerframe/nstc.c | 211 ++++++++++++++++++++++++++++++- > dlls/explorerframe/tests/nstc.c | 49 +++++++- > 3 files changed, 260 insertions(+), 3 deletions(-) > Sorry for the duplicate(s), gmail was (seemingly randomly) rejecting some of my mail.

1 0

Re: shell32: Initialize memory to zero in IShellItemArray constructor.
by Nikolay Sivov 29 Jul '10

29 Jul '10

On 7/29/2010 22:21, David Hedberg wrote: > This is needed as we might, if passed an invalid riid, > hit ::Release before we get to initialize array or item_count. > --- > dlls/shell32/shellitem.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/shell32/shellitem.c b/dlls/shell32/shellitem.c > index 5b01262..a7b2f29 100644 > --- a/dlls/shell32/shellitem.c > +++ b/dlls/shell32/shellitem.c > @@ -765,7 +765,7 @@ static HRESULT WINAPI IShellItemArray_Constructor(IUnknown *pUnkOuter, REFIID ri > if(pUnkOuter) > return CLASS_E_NOAGGREGATION; > > - This = HeapAlloc(GetProcessHeap(), 0, sizeof(IShellItemArrayImpl)); > + This = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IShellItemArrayImpl)); > if(!This) > return E_OUTOFMEMORY; > I don't see a reason for this. If you want to zero two remaining fields do it explicitly. Also this helper doesn't need WINAPI it seems.

2 1

Re: krnl386.exe: Fix last error check for DOS compatibility hack.
by Alexandre Julliard 29 Jul '10

29 Jul '10

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > @@ -1092,7 +1092,7 @@ static BOOL INT21_CreateFile( CONTEXT86 *context, > winMode, winAttributes, 0 ); > /* DOS allows to open files on a CDROM R/W */ > if( winHandle == INVALID_HANDLE_VALUE && > - GetLastError()== ERROR_WRITE_PROTECT) { > + GetLastError() == ERROR_ACCESS_DENIED) { You should keep the old error too. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] mmdevapi/tests: Prevent crash when GetMixFormat fails.
by Alexandre Julliard 29 Jul '10

29 Jul '10

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > @@ -190,25 +190,31 @@ static void test_audioclient(IAudioClient *ac) > hr = IAudioClient_GetMixFormat(ac, NULL); > ok(hr == E_POINTER, "GetMixFormat returns %08x\n", hr); > > + pwfx = (void *)0xdeadbeef; > hr = IAudioClient_GetMixFormat(ac, &pwfx); > ok(hr == S_OK, "Valid GetMixFormat returns %08x\n", hr); > > - trace("Tag: %04x\n", pwfx->wFormatTag); > - trace("bits: %u\n", pwfx->wBitsPerSample); > - trace("chan: %u\n", pwfx->nChannels); > - trace("rate: %u\n", pwfx->nSamplesPerSec); > - trace("align: %u\n", pwfx->nBlockAlign); > - trace("extra: %u\n", pwfx->cbSize); > - ok(pwfx->wFormatTag == WAVE_FORMAT_EXTENSIBLE, "wFormatTag is %x\n", pwfx->wFormatTag); > - if (pwfx->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > + trace("pwfx: %p\n", pwfx); > + if (pwfx == (void *)0xdeadbeef) pwfx = NULL; > + if (pwfx) That's ugly, you should check the function result, not a magic pointer value. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: msi: prevent cryptical errors
by Alexandre Julliard 29 Jul '10

29 Jul '10

André Hentschel <nerv(a)dawncrow.de> writes: > when accidently using the wrong path then > err:msi:MSI_OpenPackageW can't find L"asf.msi" > is more readable than > err:msi:copy_package_to_temp failed to copy package L"asf.msi" to L"C:\\users\\dawncrow\\Temp\\msi71e7.tmp" (2) Then you should fix that function to display a better error, instead of adding an extra check to every open. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: Add a test for GetClassInfo, make it pass under Wine.
by Paul Vriens 29 Jul '10

29 Jul '10

On 07/29/2010 08:55 AM, Dmitry Timoshkov wrote: > + SetLastError(0xdeadbeef); > + ret = GetClassInfoEx(0, "static", NULL); Why not the explicit A-function? I see there is already an existing call in the current tests, but still. > + ok(!ret, "GetClassInfoEx() should fail\n"); > + ok(GetLastError() == ERROR_NOACCESS, "expected ERROR_NOACCESS, got %d\n", GetLastError()); > + > + SetLastError(0xdeadbeef); > + ret = GetClassInfoExW(0, staticW, NULL); > + ok(!ret, "GetClassInfoExW() should fail\n"); > + ok(GetLastError() == ERROR_NOACCESS || > + GetLastError() == ERROR_CALL_NOT_IMPLEMENTED, /* win9x */ Wouldn't broken() be more appropriate? -- Cheers, Paul.

2 1

Re: user32: Add a test for GetClassInfo, make it pass under Wine.
by testbot＠testbot.winehq.org 29 Jul '10

29 Jul '10

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=4013 Your paranoid android. === W98SE (32 bit class) === class.c:932: Test failed: expected ERROR_NOACCESS, got -559038737 === WNT4WSSP6 (32 bit class) === class.c:932: Test failed: expected ERROR_NOACCESS, got -559038737 class.c:937: Test failed: expected ERROR_NOACCESS, got -559038737

1 0

Re: [2/3] shlwapi/ordinal: Partially implement SHGetShellKey
by testbot＠testbot.winehq.org 29 Jul '10

29 Jul '10

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=4012 Your paranoid android. === W98SE (32 bit ordinal) === ordinal.c:616: Test failed: GetShellSecurityDescriptor should fail, got 0096F808 === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1789: Test failed: got 27 ordinal.c:1839: Test failed: got 27 ordinal.c:1847: Test failed: got 27 ordinal.c:1855: Test failed: got 38, length 39 ordinal.c:1866: Test failed: got 41 === W7PROX64 (32 bit ordinal) === ordinal.c:1783: Test failed: got 9 ordinal.c:1789: Test failed: got 26 ordinal.c:1804: Test failed: got 6 ordinal.c:1817: Test failed: got 9 ordinal.c:1825: Test failed: got 9 ordinal.c:1839: Test failed: got 26 ordinal.c:1847: Test failed: got 26 ordinal.c:1877: Test failed: got 19 ordinal.c:1888: Test failed: got 22 === W7PROX64 (64 bit ordinal) === ordinal.c:1783: Test failed: got 9 ordinal.c:1789: Test failed: got 26 ordinal.c:1804: Test failed: got 6 ordinal.c:1817: Test failed: got 9 ordinal.c:1825: Test failed: got 9 ordinal.c:1839: Test failed: got 26 ordinal.c:1847: Test failed: got 26 ordinal.c:1877: Test failed: got 19 ordinal.c:1888: Test failed: got 22

1 0

Re: [1/3] shlwapi/tests: Fix some test failures on Win2000
by testbot＠testbot.winehq.org 29 Jul '10

29 Jul '10

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=4011 Your paranoid android. === W98SE (32 bit ordinal) === ordinal.c:614: Test failed: GetShellSecurityDescriptor should fail, got 0096F808 === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1787: Test failed: got 27 ordinal.c:1837: Test failed: got 27 ordinal.c:1845: Test failed: got 27 ordinal.c:1853: Test failed: got 38, length 39 ordinal.c:1864: Test failed: got 41 === W7PROX64 (32 bit ordinal) === ordinal.c:1781: Test failed: got 9 ordinal.c:1787: Test failed: got 26 ordinal.c:1802: Test failed: got 6 ordinal.c:1815: Test failed: got 9 ordinal.c:1823: Test failed: got 9 ordinal.c:1837: Test failed: got 26 ordinal.c:1845: Test failed: got 26 ordinal.c:1875: Test failed: got 19 ordinal.c:1886: Test failed: got 22 === W7PROX64 (64 bit ordinal) === ordinal.c:1781: Test failed: got 9 ordinal.c:1787: Test failed: got 26 ordinal.c:1802: Test failed: got 6 ordinal.c:1815: Test failed: got 9 ordinal.c:1823: Test failed: got 9 ordinal.c:1837: Test failed: got 26 ordinal.c:1845: Test failed: got 26 ordinal.c:1875: Test failed: got 19 ordinal.c:1886: Test failed: got 22

1 0

Re: [PATCH] mmdevapi/tests: Prevent crash when GetMixFormat fails.
by Octavian Voicu 29 Jul '10

29 Jul '10

On Thu, Jul 29, 2010 at 3:57 AM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > Test results from test.winehq.org show that GetMixFormat consistently > fails on some configurations (usually for both capture and render, > sometimes only for capture). I also found out why GetMixFormat fails on my system (Kubuntu 10.04). OpenAL returns Pulse Audio as the default device, but pulseaudio daemon is not running (I removed the pulseaudio package from my system). MMDevEnum marks the pulseaudio device as the default one (for both render and capture), but alcOpenDevice / alcCaptureOpenDevice fail so the device is marked with state DEVICE_STATE_NOTPRESENT and openal_setformat is never called (which is the function responsible for writing the DeviceFormat registry key, used by GetMixFormat). A proper fix for the failed GetMixFormat test would be to fall back MMDevice_def_play / MMDevice_def_rec to the 2nd, 3rd, etc device from the default device list, and eventually to the first good device that is found (if all devices from the default device list fail). Is this OK? Octavian

1 0

siggraph / opengl BOF tonight
by Dan Kegel 29 Jul '10

29 Jul '10

Siggraph happens to be a stone's throw from my house this year, and one of the presenters was my frosh roommate :-), so I'm heading over to the opengl BOF to listen in. ( http://www.khronos.org/news/events/detail/siggraph-la-2010/#topengl_bof ) Email me or google chat me if you want me to try to find out anything...

1 1

Re: [6/6] urlmon/tests: Added some more test URIs (resend)
by testbot＠testbot.winehq.org 29 Jul '10

29 Jul '10

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=4009 Your paranoid android. === WXPPROSP3 (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === WVISTAADM (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === W2K8SE (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2400: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2856: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2].

2 1

Re: shdocvw: Add French translation
by Paul Vriens 28 Jul '10

28 Jul '10

On 07/27/2010 10:28 AM, Frédéric Delanoy wrote: > We now have an error on the translation site as you've merged 'New' and 'Window'. I know you brought this up on wine-devel but until agreed upon we should stick to the English one IMHO. -- Cheers, Paul.

3 3

Re: imm32: Set size of OSVERSIONINFOA before calling GetVersionExA
by Andrew Nguyen 28 Jul '10

28 Jul '10

On Wed, Jul 28, 2010 at 12:46 PM, Matt 'Murph' Finnicum <mattfinn(a)gmail.com> wrote: > This was causing console spam when I played Starcraft 2 (since > dwPlatformId was used uninitialized and thus was invalid). > > > > Hi Matt, Your patch causes declarations and code in the ImmGetVirtualKey function to be mixed, something that's only permitted in C99. Most likely you'll want to either initialize the size field in the OSVERSIONINFOA struct declaration or move the statement to an appropriate place after the declarations. Andrew

1 0

Re: [PATCH 1/4] ddraw: Use a less offensive handle table implementation for materials.
by Alexandre Julliard 28 Jul '10

28 Jul '10

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > IDirect3DDeviceImpl_CreateHandle() is particular is just awful. > --- > dlls/ddraw/ddraw_private.h | 30 ++++++++++++- > dlls/ddraw/device.c | 63 ++++++++++++------------- > dlls/ddraw/direct3d.c | 10 ++++ > dlls/ddraw/executebuffer.c | 26 ++++------ > dlls/ddraw/main.c | 109 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/material.c | 13 ++--- > dlls/ddraw/viewport.c | 34 ++++++-------- > 7 files changed, 211 insertions(+), 74 deletions(-) Not sure it's really less offensive: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok visual.c:1770: Tests skipped: device has no P8 texture support, skipping test visual.c:1952: Test failed: IDirect3DMaterial_GetHandle failed: 80070057 visual.c:1989: Test failed: Got color 00000000, expected 00ff0000 visual.c:1997: Test failed: Got color 00000000, expected 000000ff wine: Unhandled page fault on write access to 0x00000083 at address 0x686daffd (thread 0024), starting debugger... Unhandled exception: page fault on write access to 0x00000083 in 32-bit code (0x686daffd). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:686daffd ESP:0032fa60 EBP:0032fae8 EFLAGS:00010206( R- -- I - -P- ) EAX:00000059 EBX:6870b914 ECX:00149058 EDX:0000001b ESI:000004b0 EDI:00000097 Stack dump: 0x0032fa60: 00000000 6870c5e8 686fbe22 686f95a0 0x0032fa70: 00000097 0000001b 00020808 00000000 0x0032fa80: 00000000 3f800000 00000000 00149058 0x0032fa90: 0000001b 686f954c 6870c70c 686f95a0 0x0032faa0: 686f95d0 6870c5e8 686fbe22 00000000 0x0032fab0: 001329e8 00000000 00000000 00000000 Backtrace: =>0 0x686daffd IDirect3DDeviceImpl_7_Release+0x25d(iface=0x149058) [/home/julliard/wine/wine/dlls/ddraw/device.c:422] in ddraw (0x0032fb28) 1 0x686cfd60 Thunk_IDirect3DDeviceImpl_1_Release+0x5f(iface=0x149064) [/home/julliard/wine/wine/dlls/ddraw/device.c:474] in ddraw (0x0032fd38) 2 0x686a29fd func_visual+0x155c() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:1099] in ddraw_test (0x0032fd88) 3 0x686a2dee run_test+0x15d(name=<is not available>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:556] in ddraw_test (0x0032fe48) 4 0x686a2fe7 main+0x156(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:624] in ddraw_test (0x0032fe90) 5 0x686a3b6c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test (0x0032fea8) 6 0x7b85521c call_process_entry+0xb() in kernel32 (0x0032fee8) 7 0x7b85766b start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:996] in kernel32 (0x0032fef8) 8 0x7bc72370 call_thread_func+0xb() in ntdll (0x0032ffc8) 9 0x7bc72540 call_thread_entry_point+0x6f(entry=0x7b857610, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0032ffe8) 10 0x7bc4d8ca start_process+0x29(kernel_start=0x7b857610) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x00000000) 0x686daffd IDirect3DDeviceImpl_7_Release+0x25d [/home/julliard/wine/wine/dlls/ddraw/device.c:422] in ddraw: movl $0x0,0x68(%edx) 422 m->Handle = 0; -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] comdlg32/tests: Use GetOpenFileNameA instead of GetOpenFileNameW
by testbot＠testbot.winehq.org 28 Jul '10

28 Jul '10

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=3990 Your paranoid android. === W7PROX64 (32 bit filedlg) === No test summary line found

1 0

Re: [3/5] urlmon: Implemented canonicalization for ports in URIs
by Alexandre Julliard 28 Jul '10

28 Jul '10

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > --- > dlls/urlmon/uri.c | 88 > +++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 86 insertions(+), 2 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so uri.c && touch uri.ok uri.c:2788: Test failed: Error: Expected a length of 0 but got -2 on uri_tests[13].str_props[6]. make: *** [uri.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 5/11] quartz: Add MediaSeekingPassThru to video renderer
by Alexandre Julliard 28 Jul '10

28 Jul '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > From 42723d1e254d1fa5b6a64a56d895e05c035780bc Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > Date: Sat, 22 May 2010 15:58:15 +0200 > Subject: [PATCH 13/32] quartz: Add MediaSeekingPassThru to video renderer It doesn't work here: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so filtergraph.c && touch filtergraph.ok filtergraph.c:276: Test failed: SetPositions failed: 80040209 filtergraph.c:278: Test failed: SetPositions failed: 80040209 make: *** [filtergraph.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32/treeview: Fix a crash in TVS_SINGELEXPAND helper (Coverity)
by testbot＠testbot.winehq.org 28 Jul '10

28 Jul '10

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=3980 Your paranoid android. === WNT4WSSP6 (32 bit treeview) === treeview.c:896: Test failed: got wrong state 60

1 0

Re: [1/2] d3dx9_36: Handle parent_data parameter of D3DXInclude.Open() function.
by Henri Verbeet 28 Jul '10

28 Jul '10

On 27 July 2010 23:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > + if(parent_include == NULL) > + ERR("Parent include file missing\n"); If that's an internal error, shouldn't the call fail? Similar for the wpp_open_mem() changes.

1 0

Re: [2/2] d3dx9: Implement D3DXAssembleShaderFromFile.
by Henri Verbeet 28 Jul '10

28 Jul '10

On 27 July 2010 23:32, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > + if(parent_data != NULL) > + parent_name = *((char **)parent_data - 1); That casts away const. The ID3DXInclude interface itself looks somewhat broken to me, but I don't think you need to modify the parent name here. Please use "const char *" and "const void *" or "LPCSTR" and "LPCVOID".

1 0

Re: ddraw: Added a todo_wine test for SetCooperativeLevel
by Stefan Dösinger 28 Jul '10

28 Jul '10

Am 28.07.2010 um 00:39 schrieb Johan Gill: > > <new_ddraw_test.txt> The test seems OK to me. Not sure why patchbot is complaining, but it is running in virtual machines, so I guess we can blame its ddraw setup.

1 0

Re: ddraw: Added a todo_wine test for SetCooperativeLevel
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3977 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: ddraw: Ensure fullscreen size of fullscreen windows
by Stefan Dösinger 27 Jul '10

27 Jul '10

Am 27.07.2010 um 00:19 schrieb Johan Gill: > This patch fixes the long-standing regression bug 17215. > > Enjoy, and provide feedback if you don't ;) > <17215.txt> Usually wined3d does the window setup. I recommend to take a look at WineD3D's AcquireFocusWindow and SetDisplayMode The problem is somewhat more complicated though - there's swapchain_setup_fullscreen_window and swapchain_restore_fullscreen_window, but wined3ddevice::Setdisplaymode doesn't call the swapchain(because there may not be one if ddraw hasn't created the primary surface yet).

2 2

The Bugzilla Project is interested in hearing about your feedback
by Frédéric Buclin 27 Jul '10

27 Jul '10

Hello dear Bugzilla maintainers and administrators, I am Frédéric "LpSolit" Buclin, the QA lead and one of the two assistant project leads for the Bugzilla project. You are receiving this email because you have already been contacted by Max Kanat-Alexander (mkanat) some time ago when he did a survey about Bugzilla, or because you have been CC'ed to two notable security bugs in 2009, from where I took your email addresses. A few days ago, core Bugzilla developers were talking about relaxing a security policy, and we couldn't come to an agreement because some of us disagree to relax this policy, while some others are fine with this change. We realized that the lack of agreement was because we didn't have enough data from real Bugzilla installations, and that having feedback from maintainers and administrators of large and popular Bugzilla installations was important in this process. Now you probably see why you are getting this email, aren't you? :) The proposed idea is to create a new mailing-list, containing mostly maintainers and administrators of main and popular Bugzilla installations, to discuss security policy changes and major UI changes. This mailing-list should be low-traffic (I don't expect more than 2-4 threads per year). To be clear, we are not going to talk about technical aspects of Bugzilla; important back-end changes being already discussed in developers(a)bugzilla.org. Also, we are not going to talk about minor UI changes, those changes being discussed with the UI lead. The goal of this mailing-list is only to get feedback from you, to know how a security policy change or a major UI change would affect your installation and your users, based on your work flow and based on your own management. So this is a good opportunity to let us know how you would be affected by such or such change. So in order to create the mailing-list, I need to know who would be willing to be in this list and give us their feedback. There will be a way to unsubscribe, in case you are no longer interested to participate. Your feedback is important to us! Please let me know if you are interested or not (with a short reminder about which Bugzilla installation you maintain, to make sure I'm up-to-date), so that we can add you to this new mailing-list. The first topic will be about the security policy change I talked earlier. Best regards, Frédéric Buclin

1 0

Re: [PATCH 02/11] d3d10: Implement D3D10CreateBlob().
by Henri Verbeet 27 Jul '10

27 Jul '10

2010/7/26 Rico Schüller <kgbricola(a)web.de>: > + IUnknown_Release((IUnknown *)object); Since you'll probably resend this anyway based on Matteo's comment, I think just HeapFree() should do just as well. Also, I don't have a recent enough DX SDK to check at the moment, but if d3dcommon.h is generated by IDL, it will mostly likely have proper COM macros for ID3D10Blob as well.

2 1

Re: [2/2] shlwapi/ordinal: Partially implement SHGetShellKey
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3965 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:609: Test failed: GetShellSecurityDescriptor should fail ordinal.c:1964: Test failed: got 0x00393939, expected 0x00000080. Key {2AD91900-A873-11cf-9A80-00AA00C16E65} ordinal.c:1964: Test failed: got 0x00393939, expected 0x00000121. Key {DB8DC413-C0AA-11D0-9545-080009B1C2F3} === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1782: Test failed: got 26 ordinal.c:1832: Test failed: got 26 ordinal.c:1840: Test failed: got 26 ordinal.c:1848: Test failed: got 37, length 38 ordinal.c:1859: Test failed: got 40 === W7PROX64 (64 bit ordinal) === ordinal.c:1776: Test failed: got 10 ordinal.c:1797: Test failed: got 7 ordinal.c:1810: Test failed: got 10 ordinal.c:1818: Test failed: got 10 ordinal.c:1848: Test failed: got 33, length 34 ordinal.c:1859: Test failed: got 36 ordinal.c:1870: Test failed: got 20 ordinal.c:1881: Test failed: got 23

1 0

Re: [1/2] shlwapi/tests: Skip on invalid security descriptor to avoid exception
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3964 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:607: Test failed: GetShellSecurityDescriptor should fail ordinal.c:1962: Test failed: got 0x00393939, expected 0x00000080. Key {2AD91900-A873-11cf-9A80-00AA00C16E65} ordinal.c:1962: Test failed: got 0x00393939, expected 0x00000121. Key {DB8DC413-C0AA-11D0-9545-080009B1C2F3} === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1780: Test failed: got 26 ordinal.c:1830: Test failed: got 26 ordinal.c:1838: Test failed: got 26 ordinal.c:1846: Test failed: got 37, length 38 ordinal.c:1857: Test failed: got 40 === W7PROX64 (64 bit ordinal) === ordinal.c:1774: Test failed: got 10 ordinal.c:1795: Test failed: got 7 ordinal.c:1808: Test failed: got 10 ordinal.c:1816: Test failed: got 10 ordinal.c:1846: Test failed: got 33, length 34 ordinal.c:1857: Test failed: got 36 ordinal.c:1868: Test failed: got 20 ordinal.c:1879: Test failed: got 23

1 0

Re: [PATCH 01/11] d3d10: Add the ID3D10Blob interface.
by Matteo Bruni 27 Jul '10

27 Jul '10

Hello Rico, from d3d10misc.h of latest DirectX SDK: // ID3D10Blob has been made version-neutral and moved to d3dcommon.h. d3dcommon.h seems to be an idl-generated header. From what I can see up to now, only your first patch is "wrong", the rest just needs to be fixed to include d3dcommon.h where needed. Now, I wrote an ID3D10Blob implementation too, it's almost exactly the same as yours (or, to be fair, both are mostly a copy, paste and replace of D3DXBuffer), but I defined the ID3D10Blob interface as latest SDK while you implemented some more things. My plan at this point is: I'll send in a bit a patch adding d3dcommon.idl with the relevant definitions, then you can rebase and adjust your patches on top of it. Does it sound good? Matteo.

2 5

GetVolumeInformationA: please test this on MS-Windows
by Joerg-Cyril.Hoehle＠t-systems.com 27 Jul '10

27 Jul '10

Hi, Wine's testbot job #3910 at http://testbot.winehq.org/JobDetails.pl?Key=3910 contains one binary downloadable via http://testbot.winehq.org/GetFile.pl?JobKey=3910&StepKey=1 that I'd like people to test esp. on Win9X machines (virtual or real). Please invoke it as wintest.exe volume # or X:\path\to\wintest.exe volume Please start it from *another* drive than C: (where your Windows directory is located) or it will skip the important test: volume.c:406: Tests skipped: Please re-run from another device than C: That's why testbot is not good enough here: its machines only have a single drive, C: Normal output on Win9X will be: volume.c:326: Test failed: info: GetVolumeInformationA did fail, current=C:\winetest, last error 161 volume.c:342: Test failed: GetVolumeInformationA did not fail, last error 161 volume.c:422: Test failed: GetVolumeInformationA failed, root=\\?\C:\, last error=53 volume.c:428: Test failed: GetVolumeInformationA failed, root=\\.\C:\, last error=53 volume.c:434: Test failed: GetVolumeInformationA failed, root=C:\WINDOWS\, last error=161 volume.c:440: Test failed: GetVolumeInformationA failed, root=C:\WINDOWS, last error=161 Normal output on more recent OS: volume.c:326: Test failed: info: GetVolumeInformationA did fail, current=C:\winetest, last error 123 [other skipped tests not mentioned] The test in line 326 always fails in order to show what happens on the current directory. Try it out by starting from different directories. See bugs #23355 and #20887 about GetVolumeInformationA. Thank you very much, Jörg Höhle

3 2

Ukrainian translation of Wine at 100%
by Paul Vriens 27 Jul '10

27 Jul '10

Hi, And Ukrainian is also at a 100% !!! Thanks go to Igor for his efforts in getting us this far. -- Cheers, Paul.

1 0

Re: [2/6] richedit: EN_UPDATE notification is sent on WM_PAINT.
by James Mckenzie 27 Jul '10

27 Jul '10

Dylan: Just a question, I don't see 1/6 in this sequence. Was it submitted earlier? James -----Original Message----- >From: Dylan Smith <dylan.ah.smith(a)gmail.com> >Sent: Jul 26, 2010 5:26 AM >To: wine-patches <wine-patches(a)winehq.org> >Subject: [2/6] richedit: EN_UPDATE notification is sent on WM_PAINT. >

2 2

Re: jscript: Added support for Function.arguments property.
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3956 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

3 2

Re: [3/4] shdocvw: Add and use AdviseSinkInerface for IE
by Jacek Caban 27 Jul '10

27 Jul '10

On 7/27/10 1:25 PM, Alexander Nicolaysen Sørnes wrote: > This will be used to change the address bar URL when navigating to new pages + *ppvoid = NULL; + if(IsEqualGUID(&IID_IAdviseSink, riid)) You also need to handle IUnknown. + { + *ppvoid = iface; + AdviseSink_AddRef(iface); Direct call to interface function is not really nice. +typedef struct _AdviseSink { + const IAdviseSinkVtbl *lpAdviseSinkVtbl; + LONG ref; + DocHost* doc_host; +} AdviseSink; Is there any reason to make it a separated struct? Also, you don't need it for URL change notification. We already have better way of doing that in shdocvw. See IPropertyNotifySink related code. Jacek

1 0

Re: [2/2] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx
by Henri Verbeet 27 Jul '10

27 Jul '10

On 26 July 2010 23:05, Owen Rudge <owen(a)owenrudge.net> wrote: > + if ((filter & 0xFFFF) > D3DX_FILTER_BOX && filter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if ((mipfilter & 0xFFFF) > D3DX_FILTER_BOX && mipfilter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if (!filter || !mipfilter) > + return D3DERR_INVALIDCALL; I think those should be handled implicitly by D3DXLoadSurfaceFromFileInMemory() / D3DXFilterTexture(). Provided you check the return values anyway. > + if (filter == D3DX_DEFAULT) > + filter = D3DX_FILTER_TRIANGLE | D3DX_FILTER_DITHER; > + > + if (mipfilter == D3DX_DEFAULT) > + mipfilter = D3DX_FILTER_BOX; Same. > + if (width == 0 || width == D3DX_DEFAULT_NONPOW2) > + width = imginfo.Width; Probably depends on the device supporting NPOT textures again. > + if ((pool != D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC)) Dynamic textures are a device capability.

1 0

Re: [1/2] d3dx9: Implement missing D3DXCreateTextureFromFile functions
by Henri Verbeet 27 Jul '10

27 Jul '10

On 26 July 2010 23:05, Owen Rudge <owen(a)owenrudge.net> wrote: > +HRESULT WINAPI D3DXCreateTextureFromFileInMemory(LPDIRECT3DDEVICE9 device, > + LPCVOID srcdata, > + UINT srcdatasize, > + LPDIRECT3DTEXTURE9 *texture) Please don't use those, just write "IDirect3DTexture9 **", "const void *", etc. Also, srcdatasize is unsigned. > + TRACE("(void): relay\n"); That's doesn't really match the function arguments.

1 0

Re: mshtml: Improve status messages sent to IOleInPlaceFrame
by Jacek Caban 27 Jul '10

27 Jul '10

Hi Alexander, On 7/26/10 11:36 AM, Alexander Nicolaysen Sørnes wrote: > In preparation for adding a status bar to Wine's IE - static const WCHAR wszDone[] = {'D','o','n','e',0}; + static WCHAR wszDone[40] = { 0 }; + + if(!wszDone[0]) + LoadStringW(hInst, IDS_DONE, wszDone, sizeof(wszDone)/sizeof(wszDone[0])); IOleInPlaceFrame_SetStatusText(doc_obj->frame, wszDone); SetStatusText call really deserves a helper function that would take care of loading the string resources instead of duplicating the code. @@ -44,6 +45,7 @@ typedef struct { task_t header; HTMLDocumentObj *doc; BOOL set_download; + BSTR url; } download_proc_task_t; You don't need this, URL is stored in HTMLWindow object at this point. Jacek

2 1

Re: [2/2] ntdll: Fix the status code for ProcessDebugObjectHandle class in NtQueryInformationProcess when the debugger is ab
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3961 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: dmusic: use a previously unused variable (try 3)
by Octavian Voicu 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 9:36 AM, Austin English <austinenglish(a)gmail.com> wrote: > Try 3: Use tabs, not spaces. > Try 2: return hr, free memory There's still a memory leak in this function if IDirectMusicPortImpl_QueryInterface fails. Would be nice to fix that also :) Octavian

1 0

[website] Update French translation of 'About Wine' page
by Frédéric Delanoy 27 Jul '10

27 Jul '10

1 0

Re: programs/winetest: bump file size limit to 1.75 MB (1/2)
by Michael Stefaniuc 27 Jul '10

27 Jul '10

Hello Austin, Austin English wrote: > There were no test results on winehq today. Seems everyone's exceeding > 1.5. Guess some new tests today have a lot of output... wouldn't it make more sense to have a global variable 'max_filesize' instead of duplicating the magic constants all over the place? > diff --git a/programs/winetest/send.c b/programs/winetest/send.c > index 11c9f33..9fc4b81 100644 > --- a/programs/winetest/send.c > +++ b/programs/winetest/send.c > @@ -155,11 +155,11 @@ send_file_direct (const char *name) > goto abort1; > } > filesize = GetFileSize( file, NULL ); > - if (filesize > 1.5*1024*1024) { > + if (filesize > 1.75*1024*1024) { > report (R_WARNING, > - "File too big (%.1f MB > 1.5 MB); submitting partial report.", > + "File too big (%.1f MB > 1.75 MB); submitting partial report.", > filesize/1024.0/1024); > - filesize = (DWORD) 1.5*1024*1024; > + filesize = (DWORD) 1.75*1024*1024; > } > > report (R_STATUS, "Sending header"); > @@ -298,11 +298,11 @@ send_file_wininet (const char *name) > } > > filesize = GetFileSize( file, NULL ); > - if (filesize > 1.5*1024*1024) { > + if (filesize > 1.75*1024*1024) { > report (R_WARNING, > - "File too big (%.1f MB > 1.5 MB); submitting partial report.", > + "File too big (%.1f MB > 1.75 MB); submitting partial report.", > filesize/1024.0/1024); > - filesize = 1.5*1024*1024; > + filesize = 1.75*1024*1024; > } > > report (R_STATUS, "Opening HTTP connection to " SERVER_NAME); bye michael

1 0

Re: programs/winetest: bump file size limit to 1.75 MB (1/2)
by Paul Vriens 27 Jul '10

27 Jul '10

On 07/27/2010 03:48 AM, Austin English wrote: > There were no test results on winehq today. Seems everyone's exceeding > 1.5. Guess some new tests today have a lot of output... > I do see output for July 26th or am I missing something? We could use a volunteer to implement compression for the winetest reports. -- Cheers, Paul.

3 2

Re: kernel32: add a test for CreateFileA() (try 3)
by Andrew Nguyen 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 12:53 AM, Austin English <austinenglish(a)gmail.com> wrote: > Addressing Nikolay and Dmitry's comments. > > Passed wtb: > https://testbot.winehq.org/JobDetails.pl?Key=3947 > > -- > -Austin > > > You forgot to attach the patch.

1 0

Re: dmusic: remove unused variable (try 2)
by Andrew Nguyen 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 12:59 AM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > > The source file seems to use tabs for indentation, so your patch should do the same.

1 0

Re: ws2_32, WS2_send: Avoid error if total bytes sent is 0
by Mike Kaplinskiy 27 Jul '10

27 Jul '10

On Mon, Jul 26, 2010 at 3:05 PM, Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> wrote: > This fixes bug #19397 > > > > I don't think that's the right place for the fix. You should probably put it in WS2_sendto. Also could you add some tests to verify that this is the behavior for all protocols, not just IrDA? Mike.

1 0

Re: ntdll: Use IsEqualGUID instead of memcmp to compare GUIDs.
by Octavian Voicu 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 2:00 AM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > - ok(memcmp(&guid, &IID_Endianess, sizeof(guid)) == 0, "Endianess broken\n"); > + ok(!IsEqualGUID(&guid, &IID_Endianess), "Endianess broken\n"); memcmp returns 0 when there is a match, so you should probably use IsEqualGUID without the negation. Octavian

1 0

Re: ntdll: Use IsEqualGUID instead of memcmp to compare GUIDs.
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3928 Your paranoid android. === W2KPROSP4 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === WXPPROSP3 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W2K3R2SESP2 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === WVISTAADM (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W2K8SE (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W7PRO (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W7PROX64 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W7PROX64 (64 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken

1 0

d3dx9: D3DXCreateMeshFVF and ID3DXMesh... let the criticism begin
by Misha Koshelev 27 Jul '10

27 Jul '10

Dear All: I have worked hard today with Henri on my D3DXCreateSphere patch and appreciate all his help (and all of your help and patience with me and my inability to use email programs and IRC programs ;) ). I am now moving on to implementing D3DXCreateMeshFVF and ID3DXMesh so that we can actually get D3DXCreateSphere, Box, and Cylinder going (and teapot... or a stub). I attached my current versions. I expect a lot of comments/changes: * patch 1 - same patch as I submitted with Henri's blessing. Hopefully this will go in tomorrow. This is just for reference. * patch 2 - add stub for D3DXCreateMeshFVF and basic test. I'm assuming this should go in too if I sent it by itself tomorrow. * patch 3 - enumeration. Also fairly simple. * patch 4 - complete D3DXCreateMeshFVF test. Any criticisms? At the very least, I would like to send patches 2-4 tomorrow, provided patch 1 goes in (I'm assuming so per the Henri blessing part ... fingers crossed) * patch 5 - this is clearly not complete and I hope to get some good feedback on this patch. I've already gotten some feedback from Tony Wasserka (thank you). Specifically, I expect per his comment I must reimplement using declarators http://bugs.winehq.org/show_bug.cgi?id=22918#c39 This means that I must first get a patch committed that implements D3DXDeclaratorFromFVF which is currently a stub in git. Additionally, I realize Tony has, in his private repo, some more work on ID3DXMesh that is somewhat more complete I believe than mine: http://repo.or.cz/w/wine/d3dx9TW.git/blob/Merge:/dlls/d3dx9_36/basemesh.c I have not yet given this detailed scrutiny as, for me, it is easier to start with my own code, and then work from there, potentially integrating Tony's code (thank you) based on your feedback about what is necessary, etc. However, I have currently limited my code to the features that are necessary for ID3DXMesh for D3DXCreateSphere, Cylinder, and Box, as the aim was to fix this bug: http://bugs.winehq.org/show_bug.cgi?id=22918 In any case, I appreciate your attention to these patches and good feedback. I am specifically quite interested in feedback to patches 2-4, as I'd like to (ideally) submit versions of these that go through tomorrow. However, as the bulk of my work tomorrow (and probably for quite a bit afterwards) I expect on patch 5, I'd appreciate, it possible a list of things that are necessary to get such a patch committed. (Please correct me if I am wrong about having to implement D3DXDeclaratorFromFVF.) I chose to put this hard stuff first. Then, quite honestly, I believe adding tests for D3DXCreateBox and Cylinder, as well as the actual implementations, should be fairly simple compared to this part. In any case, I eagerly (anxiously) await constructive criticism/feedback/suggestions. Thank you Misha

1 1

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 5)
by Misha Koshelev 27 Jul '10

27 Jul '10

Ok I am very very sorry email is clearly not my forte. Linking same file in test and main dll: I am not aware of a precedent for this but if there is one of course I would be glad to be shown otherwise. Second comment: please pardon if I am misunderstanding but how is what you suggest not simply moving the lookup table calculation from the helper function which we will also use for, at the very least, the cylinder test, inside the actual compute_sphere function itself? Thank you Misha On Jul 26, 2010 8:40 PM, "Octavian Voicu" <octavian.voicu(a)gmail.com> wrote: On Tue, Jul 27, 2010 at 4:15 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > Why do you ask? > > Ar... That's why I was asking, as I suppose you can't use functions from the test in the implementation, nor have internal functions used in the tests. Only way I see it is to have something like mesh_utils.[ch] which is linked with both the dll and the test, but I'm not sure if that's acceptable. Maybe someone else can answer that. A little observation is that you don't really need to precompute both tables, just the one for phi (if you compute sin and cos of current theta outside the inner loop). Octavian

2 2

Re: [5/5] urlmon/tests: Added some more test URIs
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3926 Your paranoid android. === W98SE (32 bit uri) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit uri) === Timeout === WXPPROSP3 (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2387: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2840: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === WVISTAADM (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2387: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2840: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === W2K8SE (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2387: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2840: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2].

1 0

Re: [4/5] urlmon: Implemented IUri_GetPort
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3925 Your paranoid android. === W98SE (32 bit uri) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit uri) === Timeout

1 0

Re: [2/5] urlmon/tests: Restructured invalid URI tests plus added more test data
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3924 Your paranoid android. === W98SE (32 bit uri) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit uri) === Timeout

1 0

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 5)
by Misha Koshelev 27 Jul '10

27 Jul '10

> On Tue, Jul 27, 2010 at 1:30 AM, Misha Koshelev <misha680 at gmail.com> wrote: > > I have spent quite a bit of time with Henri on IRC re this patch (thank you so much) and it now has his blessing. > > > > Hopefully everyone else's as well :) > > Looks nice, but I have a question. > > When you're going to actually implement D3DXCreateSphere (probably > applies to subsequent mesh functions too), aren't you going to need > big chunks of this code, like the compute_sphere and *_sincos_table > functions? > > Or are you going to use a different approach to compute the meshes in > the actual implementation? > > Octavian > Yes it is going to be fairly similar. A few exceptions: * No mesh structure per se (vertex and index buffer inline in the actual function) * Definitely the sincos_table parts You can see (a rather dated at this point) version here: http://github.com/misha680/wine/blob/master/dlls/d3dx9_36/mesh.c Why do you ask? Are you aware of a good way to share code between tests and the actual function? Thank you Misha p.s. I'm not really aware of another (better) approach to compute.

2 2

Re: ddraw: Ensure fullscreen size of fullscreen windows
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3921 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 5)
by Octavian Voicu 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 1:30 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > I have spent quite a bit of time with Henri on IRC re this patch (thank you so much) and it now has his blessing. > > Hopefully everyone else's as well :) Looks nice, but I have a question. When you're going to actually implement D3DXCreateSphere (probably applies to subsequent mesh functions too), aren't you going to need big chunks of this code, like the compute_sphere and *_sincos_table functions? Or are you going to use a different approach to compute the meshes in the actual implementation? Octavian

1 0

Re: [PATCH 07/11] d3d10: Implement D3D10GetInputAndOutputSignatureBlob().
by Henri Verbeet 26 Jul '10

26 Jul '10

2010/7/26 Rico Schüller <kgbricola(a)web.de>: > + /* 32 (DXBC header) + 2 * (1 * 4 (chunk index) + 2 * 4 (chunk header)) + data_size (chunk data) */ I'm probably missing something here, but: - I think that should be "2 * 4 (chunk index) + 2 * 4 (chunk header)" -> 48? - Aligning chunks on 16 byte / 128 bits offsets makes sense, but then you also need to actually write the chunks at those locations, and take it into account in the size calculation.

1 0

Re: [PATCH 05/11] d3d10: Implement D3D10GetInputSignatureBlob().
by Henri Verbeet 26 Jul '10

26 Jul '10

2010/7/26 Rico Schüller <kgbricola(a)web.de>: > +static HRESULT shader_singnature_handler(const char *data, DWORD data_size, DWORD tag, void *ctx) That's not how you write "signature". > + IUnknown_Release((IUnknown *)object); Is that cast needed?

1 0

Re: [PATCH] libs/wpp: Fixed bug in preventing add_text_to_macro from handling macros over 1 kb large
by Austin English 26 Jul '10

26 Jul '10

On Mon, Jul 26, 2010 at 12:38 PM, Travis Athougies <iammisc(a)gmail.com> wrote: > Resending patch with proper line wrapping You forgot the patch :-). -- -Austin

1 0

Re: Patch #63746 revisited: Add const qualifer after version check
by Octavian Voicu 26 Jul '10

26 Jul '10

On Mon, Jul 26, 2010 at 2:13 PM, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > +#else > +const SSL_METHOD *method; Also, you accidentally removed the "static" keyword instead of removing the "const" keyword for the #else branch (in both files). Octavian

1 0

Re: Patch #63746 revisited: Add const qualifer after version check
by Octavian Voicu 26 Jul '10

26 Jul '10

On Mon, Jul 26, 2010 at 2:13 PM, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > -static SSL_METHOD *meth; > +#if defined(OPENSSL_VERSION_NUMBER) && (OPENSSL_VERSION_NUMBER> 0x1000000) > +static const SSL_METHOD *meth; > +#else > +const SSL_METHOD *method; There's a typo here, last line should declare meth not method. Octavian

1 0

Re: [PATCH] const variables are not compile-time constants
by Octavian Voicu 26 Jul '10

26 Jul '10

On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa <tdb(a)tdb.fi> wrote: > - static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /* flags that can be set by user */ > + static const DWORD user_flags = DCX_PARENTCLIP | DCX_CLIPSIBLINGS | DCX_CLIPCHILDREN | DCX_WINDOW > + | DCX_NORESETATTRS; /* flags that can be set by user */ This should be committed first thing tomorrow imho (in order to minimize the number of potential compile errors in case of a bisect). Octavian

4 4

Re: [PATCH 2/7] msvcp90/tests: Added allocator<char> tests (try3)
by Alexandre Julliard 26 Jul '10

26 Jul '10

Piotr Caban <piotr(a)codeweavers.com> writes: > try3: Don't skip all tests on 64bit You should be able to run all tests on 64-bit, which would also have the advantage of making sure the function prototypes are correct (since the call macros on i386 prevent checking). -- Alexandre Julliard julliard(a)winehq.org

1 0

How to handle Wrapper(?) Dlls
by Uwe Bonnes 26 Jul '10

26 Jul '10

Hello, there are several hardware related libraries, like libusb and libftd2xx which exist on Windows and at least linux. I tried already to add libftd2xx, but with silent reject. What is the preferred way to handle it? I feel including in wine is favorable, as this gives a good user impression, as some hardware device connected to the machine with the windows software installed has good chances to work out of the box. Another possibility, but much less favourable i.m.h.o. would be to build an add-on dll, distributed at either some place at winehq or else. This however requires user intervention and some way to let the user know about the translation dll. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 3

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 4)
by Henri Verbeet 26 Jul '10

26 Jul '10

On 26 July 2010 01:20, Misha Koshelev <misha680(a)gmail.com> wrote: > I kept some macros in, although I know you guys don't like that too much. > > Like sphere_vertex. I think it makes the code clearer. compare_vertex and compare_face are probably ok, but there's no reason sphere_vertex can't be an inline function. Note that macros are much trickier to get right than inline functions. E.g. unless you carefully control where a macro is used you usually need to at least wrap it inside "do {} while (0)", add braces around arguments, and make sure arguments are only used once to avoid unintended side-effects. >+ HeapFree(GetProcessHeap(), 0, (LPVOID)mesh->vertices); >+ mesh->vertices = (struct vertex *)HeapAlloc(GetProcessHeap(), 0, number_of_vertices * sizeof(struct vertex)); Are you used to programming in C++ by any chance? Assignments to/from void don't require an explicit cast in C. Also, you can use "sizeof(*mesh->vertices)" to ensure the type in the HeapAlloc() matches what you assign it to. > +struct mesh *new_mesh(DWORD number_of_vertices, DWORD number_of_faces) This should be static. > + struct mesh* mesh = NULL; This is redundant, you assign to mesh a few lines further down. I know this is mostly a style preference, but *please* just write "struct mesh *mesh". I guess the idea behind that convention is that you're declaring "mesh" as a "pointer to struct mesh", but declarations simply don't work that way in C. I suppose that's a flaw in the language, but either way it'll break down when you want to do something like "const char* p, q". In the long term you're probably better of properly learning C declaration syntax anyway. > + /* validate parameters */ > + assert(number_of_vertices); > + assert(number_of_faces); You don't need these. There are cases where assert() is appropriate, but that's rarely in the tests, and I don't think any of the ones in this patch qualify. > + /* new mesh */ > + mesh = (struct mesh *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct mesh)); > + if (!mesh) > + { > + return NULL; > + } You don't have to allocate "mesh" on the heap, you can just use a stack variable and pass a pointer to that. > + if (*sine) > + { > + HeapFree(GetProcessHeap(), 0, (LPVOID)*sine); > + *sine = NULL; > + } Checking for NULL before HeapFree() is redundant. > +static BOOL compute_circle_table(FLOAT **sine, FLOAT **cosine, FLOAT angle_start, FLOAT angle_step, int n) I think a "struct sincos_table" would be nicer. In the rest of the code you'd then have have e.g. "theta[stack].sin" instead of "sin_theta[stack]", but I think that's ok. You'd also avoid passing "FLOAT **sine" and "FLOAT **cosine" to free_circle_table(). Please just use "float" instead of "FLOAT". > + if (!compute_circle_table(&sin_theta, &cos_theta, theta_start, theta_step, stacks)) > + { > + free_circle_table(&sin_theta, &cos_theta); That's redundant again, compute_circle_table() already cleans those up itself on failure.

1 0

Re: [PATCH 2/3] d3dx9: Return D3DERR_INVALIDCALL in D3DXLoadSurfaceFromMemory if pDestRect is invalid
by Henri Verbeet 26 Jul '10

26 Jul '10

2010/7/25 <tony.wasserka(a)freenet.de>: > + if(pDestRect->left > pDestRect->right || pDestRect->top > pDestRect->bottom) return D3DERR_INVALIDCALL; > + if(pDestRect->left > surfdesc.Width || pDestRect->right > surfdesc.Width) return D3DERR_INVALIDCALL; If left <= right <= Width, left can never be > Width.

1 0

Re: [PATCH 1/3] d3dx9: Move pixel sampling and recombination in copy_simple_data to separate helper functions
by Henri Verbeet 26 Jul '10

26 Jul '10

On 25 July 2010 19:15, <tony.wasserka(a)freenet.de> wrote: > +typedef struct > { > + CONST PixelFormatDesc *srcformat; > + CONST PixelFormatDesc *destformat; > DWORD srcshift[4], destshift[4]; > DWORD srcmask[4], destmask[4]; > BOOL process_channel[4]; > - DWORD channels[4]; > - DWORD channelmask = 0; > + DWORD channelmask; > +} ARGB_CONVERSION_INFO; Please don't do that.

1 0

d3dx9: general direction/goal - speed, code "prettiness", etc?
by Misha Koshelev 26 Jul '10

26 Jul '10

Dear All: Given my recent work on this bug: http://bugs.winehq.org/show_bug.cgi?id=22918 and on D3DXCreateSphere, with the latest iteration being: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html I have been giving quite a bit of thought to d3dx9 and to mesh creation functions in particular. I have realized there is no "perfect" sphere creation function. Rather, there are functions that may be optimized for different purposes. Thus, I thought I'd pose the question - as to d3dx9, is our goal: a) speed b) code "prettiness" c) something else? I am tempted to think it is (a), but wanted to double check. For example, I have taken a look, per Henri's suggestion (wrt teapot), at freeglut 2.6.0 sources. For your reference: > freeglut is released under the X-Consortium license. Per http://www.winehq.org/pipermail/wine-devel/2010-July/085266.html, I believe it is okay to look at this code. In fact, the license looks strikingly like the one in: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/gdi32/region.c#l26 with X Consortium changed to Pawel W. Olstza (?) In any case, I have taken the liberty of copying and pasting glutSolidSphere to the top of the attached file. As you can see, it is implemented in terms of triangle fans and quad strips. (You will notice, btw, the use of lookup tables - fghCircleTable - for cos and sin, which reinforces my belief that speed is our top interest in terms of a graphics library). Now you will note, my current D3DXCreateSphere patch: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html creates unique vertices and indices (creating indices on a per-vertex basis per Henri's suggestion). I admit, this may not "look" as pretty as having triangle fans and quad strips. In fact, of course on possibility is to: a) create helper functions that make triangle fans and quad strips - because we are dealing with (unique) vertex buffers and index buffers for our (triangular) faces, we will need additional floating point comparison calls in each function to make sure that our vertices are unique b) use code a la freeglut to generate our vertex and index buffers Now this code might be a little "prettier" to look at, but I see some serious problems with this approach and would appreciate your comments/feedback. Here are some issues: i) KISS (keep it simple .. umm .. silly) - although not a computer scientist by formal training, I know well enough that in any system, the more complex the system, the more opportunities for random behavior. In other words, bugs. Clearly, this is why we have conformance tests. But it seems like it would be overkill to have conformance tests for helper functions, especially helper functions used in a test. ii) Most importantly - this would add at least three floating point comparisons per vertex that we add. This may not seem like a lot - until you start thinking of a sphere with, say, 1000 vertices (not too much for a spherical-looking sphere), and, say, for a game that generates 100 spheres. This means 100 x 1000 x 3 = 30000 extra floating point comparisons (which would involve a subtraction and comparison because we would be comparing to a predefined epsilon - not to mention the eternal question - which epsilon do we use?) Now this link is quite old: http://www.phoronix.com/scan.php?page=article&item=wine_feb08_tests&num=1 but surely Wine is constantly being benchmarked as far as graphics performance, since I believe one of the big uses of Wine currently is for games. Thus, it is reasonable that we do not want to take such a performance hit. In any case, this is my thought as to why http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html is a good implementation for a sphere, rather than doing something more high level. And, in general, why we probably want to keep doing the vertex buffer/index buffer approach, and forgo an approach where we: (a) create non-unique vertices uses nice geometrical structures on the fly (triangle fans, quad strips) (b) generate vertex and index buffers from these on the fly. However, as always, feedback appreciated. Thank you and have a nice Saturday! Misha

2 4

Re: [3/3] msi/tests: Skip tests if UAC is enabled and the process is not running elevated.
by testbot＠testbot.winehq.org 26 Jul '10

26 Jul '10

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=3902 Your paranoid android. === W7PROX64 (32 bit install) === install.c:3741: Test failed: Expected imaname, got ðõ install.c:3752: Test failed: Expected 314, got 12 install.c:3758: Test failed: Expected OrderTestValue, got ðõ === W7PROX64 (64 bit install) === install.c:10045: Test failed: key not removed install.c:10055: Test failed: key not removed install.c:10066: Test failed: key not removed install.c:10357: Test failed: key not created === W7PROX64 (32 bit package) === package.c:8371: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8382: Test failed: Expected "C:\winetest\", got "" package.c:8393: Test failed: Expected "C:\winetest\", got "" package.c:8443: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8454: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8463: Test failed: Expected "C:\", got "" package.c:8469: Test failed: Expected "C:\winetest\", got "" package.c:8490: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8499: Test failed: Expected "C:\winetest\FileName1", got "" === W7PROX64 (64 bit package) === package.c:8371: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8382: Test failed: Expected "C:\winetest\", got "" package.c:8393: Test failed: Expected "C:\winetest\", got "" package.c:8443: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8454: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8463: Test failed: Expected "C:\", got "" package.c:8469: Test failed: Expected "C:\winetest\", got "" package.c:8490: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8499: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 3/5] shell32: Initial implementation of IShellItemArray with SHCreateShellItemArray.
by Alexandre Julliard 26 Jul '10

26 Jul '10

David Hedberg <david.hedberg(a)gmail.com> writes: > --- > dlls/shell32/Makefile.in | 1 + > dlls/shell32/shell32.spec | 1 + > dlls/shell32/shellitemarray.c | 270 ++++++++++++++++++++++++++++++++++++++++ > dlls/shell32/tests/shlfolder.c | 132 +++++++++++++++++++ > include/shobjidl.idl | 1 + > 5 files changed, 405 insertions(+), 0 deletions(-) > create mode 100644 dlls/shell32/shellitemarray.c > > diff --git a/dlls/shell32/Makefile.in b/dlls/shell32/Makefile.in > index 3099de2..3db4bdb 100644 > --- a/dlls/shell32/Makefile.in > +++ b/dlls/shell32/Makefile.in > @@ -31,6 +31,7 @@ C_SRCS = \ > regsvr.c \ > shell32_main.c \ > shellitem.c \ > + shellitemarray.c \ > shelllink.c \ > shellole.c \ > shellord.c \ This could go into shellitem.c, no need for a separate file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/7] msvcp90/tests: Added allocator<char> tests (try2)
by Alexandre Julliard 26 Jul '10

26 Jul '10

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -22,6 +22,13 @@ > #include <winbase.h> > #include "wine/test.h" > > +#ifndef __i386__ > +/* Skip these tests for non x86 platforms */ > +START_TEST(misc) > +{ > +} > +#else There's no reason not to run the tests on 64-bit, as long as the functions exist there, they should be tested too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/4] propsys/tests: Add tests for PSStringFromPropertyKey.
by testbot＠testbot.winehq.org 26 Jul '10

26 Jul '10

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=3892 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

Re: [4/4] propsys/tests: Add tests for PSPropertyKeyFromString.
by testbot＠testbot.winehq.org 26 Jul '10

26 Jul '10

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=3893 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: propsys: add stub for PSPropertyKeyFromString
by Andrew Nguyen 26 Jul '10

26 Jul '10

On Sun, Jul 25, 2010 at 2:09 PM, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > fixes http://bugs.winehq.org/show_bug.cgi?id=23528 > I don't mean to step on this patch, but I've sent a fuller implementation of PSPropertyKeyFromString which, if accepted, should take precedence over this stub.

1 0

Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
by Nikolay Sivov 25 Jul '10

25 Jul '10

On 7/24/2010 18:51, Max TenEyck Woodbury wrote: > --- > dlls/ntdll/file.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 0a6ee55..86c200f 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2148,6 +2148,11 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE handle, PIO_STATUS_BLOCK io, > io->u.Status = STATUS_INVALID_PARAMETER_3; > break; > > + /* Invalid requests - do not need 'fixing'. */ > + case FileAllInformation: > + io->u.Status = STATUS_NOT_IMPLEMENTED; > + break; > + > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; Add a test please, and a comment won't be needed with a test too.

4 5

Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
by James McKenzie 25 Jul '10

25 Jul '10

Max TenEyck Woodbury wrote: > --- > dlls/ntdll/file.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 0a6ee55..86c200f 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2148,6 +2148,11 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE handle, PIO_STATUS_BLOCK io, > io->u.Status = STATUS_INVALID_PARAMETER_3; > break; > > + /* Invalid requests - do not need 'fixing'. */ > + case FileAllInformation: > + io->u.Status = STATUS_NOT_IMPLEMENTED; > + break; > + > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; > Max: I think you missed what Nicolay and Dmitry are trying to tell you. We are trying to implement, bug for bug, the functionality of what Windows does. Does Windows return "STATUS_NOT_IMPLEMENTED" when this call is made? If not, your fix is WRONG. Silencing a 'fixme' is NOT a fix and this will be REJECTED. If this is correct and is what Windows does, then state so. Otherwise, withdraw the patch and fix it the right way. James McKenzie

4 6

Re: [PATCH 2/2] dlls/ntdll/file.c: Return a different status code.
by Ricardo Filipe 25 Jul '10

25 Jul '10

2010/7/25 Max TenEyck Woodbury <max(a)mtew.isa-geek.net>: > --- > dlls/ntdll/file.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 86c200f..c32baa0 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2150,7 +2150,7 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE handle, PIO_STATUS_BLOCK io, > > /* Invalid requests - do not need 'fixing'. */ > case FileAllInformation: > - io->u.Status = STATUS_NOT_IMPLEMENTED; > + io->u.Status = STATUS_INVALID_INFO_CLASS; > break; > > default: > -- > 1.7.1.1 > > > > your first patch has not been accepted yet. you should just make a try 2 of the first patch with the correct return code instead of a new patch correcting the first.

1 0

Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
by James McKenzie 25 Jul '10

25 Jul '10

Max TenEyck Woodbury wrote: > On 07/25/2010 01:55 PM, James McKenzie wrote: >> Andrew Eikum wrote: >>> On 07/25/2010 12:04 PM, Max TenEyck Woodbury wrote: >>>> On 07/25/2010 09:45 AM, James McKenzie wrote: >>>>> I think you missed what Nicolay and Dmitry are trying to tell you. >>>>> We are trying to implement, bug for bug, the functionality of what >>>>> Windows does. Does Windows return "STATUS_NOT_IMPLEMENTED" when this >>>>> call is made? If not, your fix is WRONG. Silencing a 'fixme' is NOT a >>>>> fix and this will be REJECTED. >>>>> If this is correct and is what Windows does, then state so. >>>>> Otherwise, >>>>> withdraw the patch and fix it the right way. >>>>> >>>>> James McKenzie >>>>> >>>> Frankly, I do not know what Microsoft does, but the test would fail on >>>> their implementation if they did something else, so I think it is safe >>>> to assume the test is implemented properly. Given that, the fixme is >>>> wrong. >> You had very well much know what Microsoft does and care very much about >> what they do. The goal of this project, as it has been since the mid >> 1990s is to fully emulate, bug and all, the Microsoft Windows32 and >> Windows64 (since 64 bit versions of Windows arrived) APIs. Thus we have >> test cases that demonstrate what the actions are of the API/ABI. That is >> what I've been working on with several richedit functions that I need to >> have for programs that I personally use. I'm 'eating my own dog food' to >> speak. >> > Since I do not have (and should never have if I work on Wine) access to > Microsoft's code, I can not know what they actually do. Upon the insistance of AJ and others, I will no longer be working on or for the Wine project. Your code does have an error, it was just recently pointed out that the return value was incorrect. Thank you for sufficiently flogging me with the whip I was attempting to flog you with. James McKenzie

1 0

Re: [PATCH] libs/wpp: Fixed bug in preventing add_text_to_macro from handling macros over 1 kb large
by André Hentschel 25 Jul '10

25 Jul '10

Hi, Your Patch got wrapped. Try change some settings in you Mailclient please and resubmit. Thx -- Best Regards, André Hentschel

1 0

Re: Any more infos about the build failure for my (small) patch
by James Mckenzie 25 Jul '10

25 Jul '10

Octavian Voicu wrote: >On Fri, Jul 23, 2010 at 12:32 PM, Uwe Bonnes ><bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >> Paul> SSL_CTX *SSL_CTX_new(SSL_METHOD *meth); 61557 88 -rw-r--r-- 1 root >> Paul> root 87238 Jun 2 11:11 ./usr/include/openssl/ssl.h >> >> Ah, Readhat defining in it's own way. >> What about debian? >> >> Isn't the OpenSSL documentation way th way it should be? > >Ubuntu also has /usr/include/openssl/ssl.h. >Linux manpages show the same thing: http://linux.die.net/man/3/ssl_ctx_new > >Maybe this should go in autoconf? > Have to check the effect on other UNIX variations, including MacOSX before doing this. Looks like a good idea, however. James McKenzie

3 4

Sorry for all the repeat emails :(
by Misha Koshelev 24 Jul '10

24 Jul '10

They did not seem to go through this morning. My apologies for the (apparently unnecessary) resends. Misha

1 0

Re: [2/2] shell32/tests: CommandLineToArgvW("") shouldn't truncate returned exe path. (resend)
by testbot＠testbot.winehq.org 24 Jul '10

24 Jul '10

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=3816 Your paranoid android. === WVISTAADM (32 bit shlexec) === shlexec.c:192: Test failed: WaitForSingleObject(hProcess) returned 258 === W7PROX64 (64 bit shlexec) === shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtBAC3.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtBAC3.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtBAC3.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtBAC3.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtBAC3.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtBAC3.tmp\test file.sde", null, null) failed: rc=29 err=2

1 0

Re: [PATCH 2/7] msvcp90/tests: Added allocator<char> tests
by testbot＠testbot.winehq.org 24 Jul '10

24 Jul '10

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=3813 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

RFC: winex11.drv: drag from X, drop to OLE (try 3)
by Damjan Jovanovic 24 Jul '10

24 Jul '10

Hi This is my third attempt at a patch for dragging from X and dropping to Wine, with the more advanced OLE drag and drop. This attempt doesn't add a public API to OLE and instead uses the cross-process drag and drop framework implemented by commit 6d1ef3a6a64f0fabf05ce1bba5f0ec4373684786. The previous attempt was http://www.winehq.org/pipermail/wine-patches/2007-August/042910.html. I am not expecting this to get accepted yet, just posting to wine-devel to get some feedback on the overall design. Thank you Damjan Jovanovic

1 0

Re: [1/5] gameux: Add initial implementation of gameux.dll
by Henri Verbeet 24 Jul '10

24 Jul '10

2010/7/18 Mariusz Pluciński <vshader(a)gmail.com>: > +static HINSTANCE hInstance; This is unused. You're mixing tabs and spaces, and have a couple of trailing spaces. Also: > + * DllRegisterServer (OLEAUT32.@)

5 4

RFC: draft HLSL test suite
by Travis Athougies 23 Jul '10

23 Jul '10

Henri, Thanks for the quick reply. So I got rid of the maze of structures and instead called the helper functions directly for each test. The tests are now much easier to understand. Is there anything else that should be incorporated into these tests? Any other ideas or suggestions? Travis Athougies On Thu, Jul 22, 2010 at 3:16 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 21 July 2010 23:46, Travis Athougies <iammisc(a)gmail.com> wrote: >> an HLSL test suite might be a good place to start, so here's a draft >> of a test framework and a few tests that use it. It's not complete, I >> know (for one, I need to write tests for vertex shaders), but before I >> go any farther, I'd like to know get peoples' opinion on the design. >> Is this the way a wine HLSL test suite should look? Is there something >> else I should incorporate into these tests? I'm absolutely open to >> suggestions. > Leaving the (fairly significant) specific issues with the > implementation aside, the basic idea will work, but it seems to me > you're making it more complicated than it needs to be. This really > doesn't need to be much more complex than the tests in > dlls/d3d9/tests/visual.c, though a bit more generic would be nice. > >> http://wiki.winehq.org/HLSLTestSuite > That page is pretty awful. > -- Travis Athougies -- Travis Athougies

1 0

Re: [1/5] shdocvw: Add menu bar to Internet Explorer (try2)
by Frédéric Delanoy 23 Jul '10

23 Jul '10

2010/7/21 Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com>: > This series adds a menu bar and Open URL dialog box to Wine's IE. > > try2: > - Fix errors pointed out by Jacek > - Don't use ExecWB() until we can be sure it uses CGID_MSHTML > Alexander N. Sørnes You should merge the "New" and "Window" in a single menu entry (New window) A submenu with only one entry is not useful IMHO. It increases for no reason the # of clicks/key typed. Besides, it can make translation a bit more difficult (in some languages, the adjective is written differently according to the "gender" of the noun) Frédéric

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel