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

Re: [5/5] libport: Add msvc isnan and isinf implementations

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -31,6 +31,14 @@ int isinf(double x) > return (!(finite(x) || isnand(x))); > } > > +#elif defined(HAVE_FLOAT_H) && defined(_MSC_VER) > +#include <float.h> You should use proper configure checks instead of _MSC_VER, like we do for other similar cases. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Marko Nikolic

Andrey Turkin wrote: > On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: >> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) >> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) >> falls well inside the number range expressible by a LONG. Logically >> there is no difference between >> formatsize <= sizeof(PCMWAVEFORMAT) >> and >> formatsize <= 16 >> One gives a bogus warning and the other doesn't. > > C99 std (para 6.5.3.4.4) states following about sizeof operator: > "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> > (and other headers)." > > sizeof result is a compile-time constant but, unlike numeric constants, > its type must always be size_t so gcc does the correct thing here. The same is with C89, paragraph 3.3.3.4 from standard: The value of the result is implementation-defined, and its type (an unsigned integral type) is size_t defined in the <stddef.h> header. So, the gcc is correct. In the example above, correct would be formatsize <= 16U which gives a warning, as expected. What remains is how to correctly remove warning. In this case (and there are many similar in the code), signed function parameter is comparing with values that are natively unsigned. Changing type of the parameter is not possible, the same if with sizeof operator. One possiblity is to add some temporary variable, but in my opinioin it will just unncesary bloat the code and is worse than casting return value of sizeof. Maybe better solution is to make signed_sizeof macro, which will always return signed values and use it instead of sizeof; I will check if there is possiblity for that.

Aug. 23, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by testbot＠testbot.winehq.org

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=4676 Your paranoid android. === WVISTAADM (32 bit gameexplorer) === gameexplorer.c:450: Test failed: cannot find expected registry value gameexplorer.c:468: Test failed: cannot find expected registry value

Aug. 23, 2010

Re: [2/6] wincodec.idl: invent an ICNS encoder CLSID

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * wincodec.idl: invent an ICNS encoder CLSID If it's invented it shouldn't be in a public header. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: comctl32: Remove unused last parameter from TOOLTIPS_EnumToolsT.

by Nikolay Sivov

On 8/23/2010 00:51, Gerald Pfeifer wrote: > --- > dlls/comctl32/tooltips.c | 6 ++---- > 1 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index 688d3b5..d17f067 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1177,8 +1177,7 @@ TOOLTIPS_DelToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > } > > static LRESULT > -TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti, > - BOOL isW) > +TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti) > { > TTTOOL_INFO *toolPtr; > > @@ -2176,8 +2175,7 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > uMsg == TTM_DELTOOLW); > case TTM_ENUMTOOLSA: > case TTM_ENUMTOOLSW: > - return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam, > - uMsg == TTM_ENUMTOOLSW); > + return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam); > case TTM_GETBUBBLESIZE: > return TOOLTIPS_GetBubbleSize (infoPtr, (LPTTTOOLINFOW)lParam); > This needs to be implemented properly instead of being removed. Significant part is here: --- /* ti->lpszText = toolPtr->lpszText; */ ti->lpszText = NULL; /* FIXME */ --- which needs some tests. It's really doubtful that text is not returned when A/W messages exist.

Aug. 23, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF.

by Henri Verbeet

On 20 August 2010 21:16, Misha Koshelev <misha680(a)gmail.com> wrote: > Thank you for your helpful feedback on my tests. > > This is based mostly on dlls/d3d9/vertexdeclaration.c with some > changes specific to D3DXDeclaratorFromFVF. > > Again, if there are any suggested changes please let me know. > As you already mentioned, this is pretty much another copy/paste implementation, including e.g. the useless macros and typedef.

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Andrey Turkin

On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: > IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) > is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) > falls well inside the number range expressible by a LONG. Logically > there is no difference between > formatsize <= sizeof(PCMWAVEFORMAT) > and > formatsize <= 16 > One gives a bogus warning and the other doesn't. C99 std (para 6.5.3.4.4) states following about sizeof operator: "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> (and other headers)." sizeof result is a compile-time constant but, unlike numeric constants, its type must always be size_t so gcc does the correct thing here.

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Marko Nikolic wrote: > sizeof expresion always return unsigned type, so it is casted > when comparing with signed values. This is ugly. > --- > dlls/avifil32/wavfile.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/avifil32/wavfile.c b/dlls/avifil32/wavfile.c > index fd6d9ec..3fc934c 100644 > --- a/dlls/avifil32/wavfile.c > +++ b/dlls/avifil32/wavfile.c > @@ -803,7 +803,7 @@ static HRESULT WINAPI IAVIStream_fnSetFormat(IAVIStream *iface, LONG pos, > TRACE("(%p,%d,%p,%d)\n", iface, pos, format, formatsize); > > /* check parameters */ > - if (format == NULL || formatsize <= sizeof(PCMWAVEFORMAT)) > + if (format == NULL || formatsize <= (LONG)sizeof(PCMWAVEFORMAT)) IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) falls well inside the number range expressible by a LONG. Logically there is no difference between formatsize <= sizeof(PCMWAVEFORMAT) and formatsize <= 16 One gives a bogus warning and the other doesn't. bye michael

Aug. 23, 2010

Re: [5/5] gdiplus: Test flags of loaded images.

by Vincent Povirk

Yep, this patch should not be committed. So the flags for a loaded image on Windows 7 are always 13010. So while earlier versions of gdiplus could determine whether the DPI was set in an image header, win7's gdiplus cannot, and always claims that it is. I remember reading that gdiplus on win7 uses WIC for its image loading/saving, and I know that WIC cannot get this information. So it makes sense. It's also very convenient for me. On Sun, Aug 22, 2010 at 1:42 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > 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=4650 > > Your paranoid android. > > > === WVISTAADM (32 bit image) === > No test summary line found > > === W7PRO (32 bit image) === > image.c:103: Test failed: Expected 00012010, got 00013010 > image.c:103: Test failed: Expected 00013088, got 00013010 > > === W7PROX64 (32 bit image) === > image.c:103: Test failed: Expected 00012010, got 00013010 > image.c:103: Test failed: Expected 00013088, got 00013010 > > === W7PROX64 (64 bit image) === > image.c:103: Test failed: Expected 00012010, got 00013010 > image.c:103: Test failed: Expected 00013088, got 00013010 > > >

Aug. 22, 2010

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > This was just a try to fix bug 23866. > > call 32 bit function from 16 bit and back is still some "black magic" for me. > Therefore i searched the wine sources for a similar case. Most/all places to > convert HINSTANCE16 to HINSTANCE i found are dlls/user.exe16/window.c . Looks > like i picked a "wrong" code fragment from there. > > Should i send a new patch only using HINSTANCE_32(GetExePtr( hinst16 )) ? No, that's wrong too. If the 16-bit code really needs a valid instance you have to pass it unmodified, otherwise you may just as well pass 0. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2010

New winetricks 20100822: new verb lucida

by Dan Kegel

Another fortnight, 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 mdac26: can't download anymore, so make it a synonym for mdac27 firefox: fix install. (filenames can have spaces. Patch by depesz. Issue 153.) lucida: add new font verb lucida mingw: fix PATH Andrew Nguyen wsh57: Fix the wsh57 dependency check and remove calls to load_wsh56 helper. Dan Kegel: gecko: make it work even if WINE isn't set. (How did this get through?)

Aug. 22, 2010

Re: appwiz.cpl: Removed sign comparison warning

by Marko Nikolic

Nikolay Sivov wrote: > On 8/21/2010 12:18, Marko Nikolic wrote: >> Nikolay Sivov wrote: >> >>> On 8/20/2010 20:04, Marko Nikolic wrote: >>>> Changed variable type to match function return type. >>>> --- >>>> dlls/appwiz.cpl/appwiz.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c >>>> index ffd2b24..1b3370b 100644 >>>> --- a/dlls/appwiz.cpl/appwiz.c >>>> +++ b/dlls/appwiz.cpl/appwiz.c >>>> @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) >>>> { >>>> APPINFO *iter; >>>> LVITEMW lvItem; >>>> - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >>>> LVM_GETNEXTITEM, -1, >>>> + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >>>> LVM_GETNEXTITEM, -1, >>>> LVNI_FOCUSED | LVNI_SELECTED); >>>> BOOL enable_modify = FALSE; >>>> >>> There's no need for that, return value means integer item index. What >>> are you fixing with that? >> Hi Nikolay, >> >> The above change suppresses sign comparison warning in the line >> >> if (selitem != -1) ... >> >> and two more places below. selitem is declared as unsigned (DWORD), so >> comparing with -1 produces warning. Since SendDlgItemMessageW anyway >> return LRESULT which is signed integer, patch changes the variable type >> to match function result and removes sign warnings. > LRESULT is something that supposed to work anyway as I understand it, > for this case I think it's > better to cast function return value to INT and use INT as a local type. Hi Nikolay, I don't think that casting is a good practice, it could just hide warnings instead of fixing them (ok, sometimes is necesary). However, in this case LRESULT (Long result) is anyway an int, 32 or 64 bit, depending on the platform. As I can see it, using LRESULT or INT is the same. Or maybe I am missing something else... Marko

Aug. 22, 2010

Re: [5/5] gdiplus: Test flags of loaded images.

by testbot＠testbot.winehq.org

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=4650 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found === W7PRO (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (64 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010

Aug. 22, 2010

Re: [4/5] gdiplus: Set bitmap has alpha flag based on format.

by testbot＠testbot.winehq.org

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=4649 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found

Aug. 22, 2010

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys

by André Hentschel

Am 22.08.2010 12:48, schrieb Konrad Wartke: > Am 22.08.2010, 13:36 Uhr, schrieb André Hentschel <nerv(a)dawncrow.de>: > >>> +#ifdef __i386__ >>> + /* get VendorID from CPUID, eax = 0 */ >>> + unsigned int regs[3]; >> >> >> Hello Konrad, >> you are generating declerations after some code here. > > fixed and resend > > +#else > + static const WCHAR VenidIntelW[] = {'G','e','n','u','i','n','e','I','n','t','e','l',0}; Be more carefull, you still do it here. -- Best Regards, André Hentschel

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by wylda＠volny.cz

> > configure: libGLU development files not found, > > GLU won't be supported. GOUJON Alexandre: > It clearly appears that libGLU.so was present > during the "ok" configure > execution and not for the other. No, that's not true, because "ls -alF /usr/lib/libGLU*" showed that all files and even checksum are correct (before installation of libice and after installation of libice) Andrew Nguyen: > /usr/bin/ld: cannot find -lSM > Presumably libsm is unavailable, which causes the configure check > to fail. That's it :-D Installing libsm-dev solved the libGLU issue. Many thanks! Interesting, that ./configure does not say a word about missing libsm, like a "checking for -lSM... not found". So if another not related to wine installs libice-dev, then i can't play games under wine ;) Anyway why configure complains about mpg123 or libGLU like: configure: libGLU development files not found, GLU won't be supported. but does not complain at all about: libasound2-dev, libice-dev, libsm-dev?

Aug. 22, 2010

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys

by André Hentschel

> +#ifdef __i386__ > + /* get VendorID from CPUID, eax = 0 */ > + unsigned int regs[3]; Hello Konrad, you are generating declerations after some code here. -- Best Regards, André Hentschel

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by GOUJON Alexandre

On 08/22/2010 10:09 AM, wylda(a)volny.cz wrote: >>> So why configure says me "-lGLU... not found" >>> when file "/usr/lib/libGLU.so.1" is present alex(a)Evan:~/Desktop$ diff configure_output_ok_libice_dev_missing.txt configure_output_bad_libice_dev_present.txt 506c506 < checking for IceConnectionNumber in -lICE... no --- > checking for IceConnectionNumber in -lICE... yes 539c539 < checking for -lGLU... libGLU.so.1 --- > checking for -lGLU... not found 802a803 > configure: libGLU development files not found, GLU won't be supported. It clearly appears that libGLU.so was present during the "ok" configure execution and not for the other.

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by Andrew Nguyen

On Sun, Aug 22, 2010 at 3:09 AM, <wylda(a)volny.cz> wrote: > Thanks for hints, Austin. Unfortunately looking at it and comparing > GOOD vs BAD log did not move me any further. So if anyone would see > there a bug, please let me know. Logs attached. > > W. > >From the bad configure log: configure:8817: checking for -lGLU configure:8842: gcc -o conftest -g -O2 conftest.c -lGLU -lGL -lSM -lICE -lXext -lX11 -lm >&5 /usr/bin/ld: cannot find -lSM Presumably libsm is unavailable, which causes the configure check to fail.

Aug. 22, 2010

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys

by Konrad Wartke

Am 22.08.2010, 13:36 Uhr, schrieb André Hentschel <nerv(a)dawncrow.de>: >> +#ifdef __i386__ >> + /* get VendorID from CPUID, eax = 0 */ >> + unsigned int regs[3]; > > > Hello Konrad, > you are generating declerations after some code here. fixed and resend

Aug. 22, 2010

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)

by Stefan Leichter

Am Thursday 19 August 2010 11:58:23 schrieb Alexandre Julliard: > Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > > + HINSTANCE hinst32; > > + if (hinst16 == GetModuleHandle16("msvideo.dll")) > > + hinst32 = GetModuleHandleA("msvfw32.dll"); > > + else > > + hinst32 = HINSTANCE_32(GetExePtr( hinst16 )); > > This doesn't seem right. Why do you need this? This was just a try to fix bug 23866. call 32 bit function from 16 bit and back is still some "black magic" for me. Therefore i searched the wine sources for a similar case. Most/all places to convert HINSTANCE16 to HINSTANCE i found are dlls/user.exe16/window.c . Looks like i picked a "wrong" code fragment from there. Should i send a new patch only using HINSTANCE_32(GetExePtr( hinst16 )) ? -- Stefan Leichter

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by wylda＠volny.cz

> > > > So why configure says me "-lGLU... not found" > > when file "/usr/lib/libGLU.so.1" is present? > > You'll want to check config.log for a more verbose > error. > > -- > -Austin Thanks for hints, Austin. Unfortunately looking at it and comparing GOOD vs BAD log did not move me any further. So if anyone would see there a bug, please let me know. Logs attached. W.

Aug. 22, 2010

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file

by Anton Khirnov

On Sat, Aug 21, 2010 at 07:50:50PM -0700, James McKenzie wrote: > Looks like you did not test the build before running it against the > testbot (I've been guilty of this as well.) > actually i did test it and it worked for some reason, must be magic :) in any case, after rebasing it doesn't -- and the reason seems to be that the build system assumes that each .c file under tests/ actually contains a test. is there a way around that (besides the obvious-but-ugly empty test in the common file)? Anton Khirnov

Aug. 22, 2010

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file

by James McKenzie

(Marvin) wrote: > 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=4626 > > Your paranoid android. > > > === WINEBUILD (build) === > Make failed > > Looks like you did not test the build before running it against the testbot (I've been guilty of this as well.) Rebase your code against the most current git and then resubmit. James McKenzie

Aug. 21, 2010

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 5, resend)

by Oldřich Jedlička

Hi Stefan, On Thursday 19 August 2010 15:40:53 Stefan Dösinger wrote: > This test contains a C++ comment, please remove it. Otherwise it looks ok, > as does patch 1 I will start sending patches one-by-one and wait until it is applied - as you recommended. It will not contain the [PATCH x/y] prefix, so don't be confused :-) I will also remove the "try 5" and start from the beginning. I will start with this patch, description is unmodified, but the C++ comment is converted to C comment. Oldřich. > > Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > > --- > > dlls/ddraw/tests/visual.c | 123 > > +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 123 > > insertions(+), 0 deletions(-) > > > > diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > > index 290cb76..aecc2ab 100644 > > --- a/dlls/ddraw/tests/visual.c > > +++ b/dlls/ddraw/tests/visual.c > > @@ -2920,6 +2920,128 @@ static void depth_clamp_test(IDirect3DDevice7 > > *device) > > > > ok(SUCCEEDED(hr), "SetViewport failed, hr %#x.\n", hr); > > > > } > > > > +static void DX1_BackBufferFlipTest(void) > > +{ > > + HRESULT hr; > > + int ret; > > + IDirectDraw *DirectDraw1 = NULL; > > + IDirectDrawSurface *Primary = NULL; > > + IDirectDrawSurface *Backbuffer = NULL; > > + WNDCLASS wc = {0}; > > + DDSURFACEDESC ddsd; > > + DDBLTFX ddbltfx; > > + COLORREF color; > > + const DWORD white = 0xffffff; > > + const DWORD red = 0xff0000; > > + BOOL attached = FALSE; > > + > > + wc.lpfnWndProc = DefWindowProc; > > + wc.lpszClassName = "DX1_BackBufferFlipTest_wc"; > > + RegisterClass(&wc); > > + window = CreateWindow("DX1_BackBufferFlipTest_wc", > > "DX1_BackBufferFlipTest", + WS_MAXIMIZE | > > WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); + > > + hr = DirectDrawCreate( NULL, &DirectDraw1, NULL ); > > + ok(hr==DD_OK || hr==DDERR_NODIRECTDRAWSUPPORT, "DirectDrawCreate > > returned: %x\n", hr); + if(FAILED(hr)) goto out; > > + > > + hr = IDirectDraw_SetCooperativeLevel(DirectDraw1, window, > > DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN); + ok(hr==DD_OK, > > "SetCooperativeLevel returned: %x\n", hr); > > + if(FAILED(hr)) goto out; > > + > > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 32); > > + if(FAILED(hr)) { > > + /* 24 bit is fine too */ > > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 24); > > + } > > + ok(hr==DD_OK || hr == DDERR_UNSUPPORTED, "SetDisplayMode returned: > > %x\n", hr); + if (FAILED(hr)) { > > + goto out; > > + } > > + > > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > > + ddsd.dwSize = sizeof(DDSURFACEDESC); > > + ddsd.dwFlags = DDSD_CAPS; > > + ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; > > + > > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Primary, NULL); > > + ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > > + > > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > > + ddsd.dwSize = sizeof(DDSURFACEDESC); > > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > > DDSD_PIXELFORMAT; + ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER; > > + ddsd.dwWidth = 640; > > + ddsd.dwHeight = 480; > > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 32; > > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x00ff0000; > > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000ff00; > > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x000000ff; > > + > > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Backbuffer, > > NULL); + todo_wine ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: > > %08x\n", hr); + if(FAILED(hr)) goto out; > > + > > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > > + if (FAILED(hr)) goto out; > > + > > + attached = TRUE; > > + > > + memset(&ddbltfx, 0, sizeof(ddbltfx)); > > + ddbltfx.dwSize = sizeof(ddbltfx); > > + U5(ddbltfx).dwFillColor = red; > > + hr = IDirectDrawSurface_Blt(Backbuffer, NULL, NULL, NULL, > > DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); + ok(hr == DD_OK, > > "IDirectDrawSurface_Blt returned: %x\n", hr); + > > + U5(ddbltfx).dwFillColor = white; > > + hr = IDirectDrawSurface_Blt(Primary, NULL, NULL, NULL, > > DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); + ok(hr == DD_OK, > > "IDirectDrawSurface_Blt returned: %x\n", hr); + > > + // Check it out > > + color = getPixelColor_GDI(Primary, 5, 5); > > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && > > GetBValue(color) == 0xFF, + "got R %02X G %02X B %02X, > > expected R FF G FF B FF\n", + GetRValue(color), > > GetGValue(color), GetBValue(color)); + > > + color = getPixelColor_GDI(Backbuffer, 5, 5); > > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && > > GetBValue(color) == 0, + "got R %02X G %02X B %02X, expected > > R FF G 00 B 00\n", + GetRValue(color), GetGValue(color), > > GetBValue(color)); + > > + hr = IDirectDrawSurface_Flip(Primary, NULL, DDFLIP_WAIT); > > + todo_wine ok(hr == DD_OK, "IDirectDrawSurface_Flip returned > > 0x%08x\n", hr); + > > + if (hr == DD_OK) > > + { > > + color = getPixelColor_GDI(Primary, 5, 5); > > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && > > GetBValue(color) == 0, + "got R %02X G %02X B %02X, > > expected R FF G 00 B 00\n", + GetRValue(color), > > GetGValue(color), GetBValue(color)); + > > + color = getPixelColor_GDI(Backbuffer, 5, 5); > > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && > > GetBValue(color) == 0xFF) || + broken(GetRValue(color) == 0xFF > > && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver + > > "got R %02X G %02X B %02X, expected R FF G FF B FF\n", + > > GetRValue(color), GetGValue(color), GetBValue(color)); + > > } > > + > > + out: > > + > > + if (Backbuffer) > > + { > > + if (attached) > > + IDirectDrawSurface_DeleteAttachedSurface(Primary, 0, > > Backbuffer); + IDirectDrawSurface_Release(Backbuffer); > > + } > > + if (Primary) IDirectDrawSurface_Release(Primary); > > + if (DirectDraw1) IDirectDraw_Release(DirectDraw1); > > + if (window) DestroyWindow(window); > > +} > > + > > START_TEST(visual) > > { > > > > HRESULT hr; > > > > @@ -2983,6 +3105,7 @@ START_TEST(visual) > > > > D3D3_ViewportClearTest(); > > p8_primary_test(); > > > > + DX1_BackBufferFlipTest(); > > > > return ;

Aug. 21, 2010