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

Re: [PATCH 3/5] wined3d: refactoring and add Mesa AMD/ATI driver support
by Henri Verbeet Feb. 26, 2010

Feb. 26, 2010

On 26 February 2010 06:39, Paul-Andre Panon <ppanon(a)shaw.ca> wrote: > + if (gl_vendor == GL_VENDOR_ATI) return TRUE; > + return FALSE; Just "return gl_vendor == GL_VENDOR_ATI;" should probably do. > - * varyings and we subtract one in dx9 shaders its not going to hurt us because the dx9 limit is > + * varyings and we subtract one in dx9 shaders it's not going to hurt us because the dx9 limit is This change is correct of course, but please put it in a separate patch.

1 0

Re: [PATCH 2/5] wined3d: refactoring and add Mesa AMD/ATI driver support
by Henri Verbeet Feb. 26, 2010

Feb. 26, 2010

On 26 February 2010 06:38, Paul-Andre Panon <ppanon(a)shaw.ca> wrote: > +enum wined3d_gl_vendor > +{ > + GL_VENDOR_WINE = 0x0000, > + GL_VENDOR_MESA = 0x0001, > + GL_VENDOR_APPLE = 0x0002, > + GL_VENDOR_ATI = 0x1002, > + GL_VENDOR_NVIDIA = 0x10de, > + GL_VENDOR_INTEL = 0x8086, > +}; These enum members shouldn't need specific values.

1 0

Re: [PATCH 3/3] gdiplus/test: Remove todos for tests that pass now [Try 4]
by Charles Davis Feb. 25, 2010

Feb. 25, 2010

Justin Chevrier wrote: > --- > dlls/gdiplus/tests/graphics.c | 22 +++++++++++----------- > 1 files changed, 11 insertions(+), 11 deletions(-) You're still not getting it! Remember, when each patch is applied, all the tests must pass. That's the rule. If the second patch is applied without this one, some tests will fail. Thus, you must merge patches 2 and 3. Chip

2 1

Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [Try 3]
by Vincent Povirk Feb. 25, 2010

Feb. 25, 2010

> + status = GdipGetNearestColor(graphics, &color); > + expect(Ok, status); I think you still need to mark this as todo_wine.

2 2

Fw: Re: Unable to Compile Wine on MacOSX
by James Mckenzie Feb. 25, 2010

Feb. 25, 2010

-----Forwarded Message----- >From: James Mckenzie <jjmckenzie51(a)earthlink.net> >Sent: Feb 25, 2010 6:52 AM >To: Charles Davis <cdavis(a)mymail.mines.edu> >Subject: Re: Unable to Compile Wine on MacOSX > >>James McKenzie wrote: >>> Interestingly enough, I have run into the 'Unable to compile' problem >>> building the latest git on MacOSX. Maybe there is corruption in my git >>> pull, but this started yesterday.... >>> >>> It appears that configure never fully finishes and config.status loops. >>I don't have that problem... And I've been experimenting with clang as >>my compiler! >> >>By the way, I never use git pull. I always do git fetch; git rebase >>origin, which is what you're supposed to do anyway if you have local >>patches in your tree. >> >That is what I have been doing. What I may need to do is run git clone and get a new copy. For some strange reason my git copy gets corrupted and I have to do a new 'pull'. > >>Another thing I do is run autoreconf, because I have local changes to >>configure.ac in my tree. That might have something to do with it. >> >Hmmm... > >>I have noticed a change in configure behavior, though. config.status >>creates the makefiles during make, not configure. I find that odd, but >>it still works, so I'm happy. >I'm thinking that both were running and that was causing problems as the first pass finished and then a second one started up. > >At least you confirmed this is 'normal'. > >James McKenzie Send to list as well. Can anyone confirm that this changed with either yesterday's or Monday's git? Thank you. James McKenzie

1 0

Preferred way of dll registration
by Paul Vriens Feb. 25, 2010

Feb. 25, 2010

Hi, We seem to have 2 different approaches for dll registration: 1) a regsvr.c file with all the necessary functions and registry information. 2) an inf file and some code to register/unregister the dll. The first one is the most common in our source but I can remember a comment from AJ about favoring the latter (or at least something like "maybe we should start using inf files for registration"). Thoughts? -- Cheers, Paul.

3 4

Re: shell32: implements shell link's GetCurFile (with tests, fixes bug #21297) [try5]
by Alexandre Julliard Feb. 25, 2010

Feb. 25, 2010

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > @@ -33,6 +33,30 @@ > > #include "shell32_test.h" > > +#define expect_eq_x(expected, actual) \ > + do { \ > + int value = (actual); \ > + ok((expected) == value, "Expected " #actual " to be 0x%x (" #expected ") is 0x%x\n", \ > + (expected), value); \ > + } while (0) > +#define expect_eq_p(expected, actual) \ > + do { \ > + void *value = (actual); \ > + ok((expected) == value, "Expected " #actual " to be %p (" #expected ") is %p\n", \ > + (expected), value); \ > + } while (0) > +#define expect_eq_ws(expected, actual) \ > + do { \ > + LPCWSTR value = (actual); \ > + ok(winetest_strcmpW((expected), value) == 0, "Expected " #actual " to be %s (" #expected ") is %s\n", \ > + wine_dbgstr_w(expected), wine_dbgstr_w(value)); \ > + } while (0) > +#define expect_true(actual) \ > + do { \ > + BOOL value = (actual); \ > + ok(value, "Expected " #actual " to be true, but it isn't\n"); \ > + } while (0) > + That's quite ugly. It doesn't save much code since it's basically a single ok() statement each time, and it makes it harder to fix a test when we find out that it can expect two different values, or that it needs a different printf format. Please avoid that sort of thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] cmd: Add test case for bug 18346: cmd "^" escape char
by Paul Vriens Feb. 25, 2010

Feb. 25, 2010

On 02/25/2010 08:35 AM, John Chow wrote: > This patch adds the test case for bug 18346: cmd does not support the > "^" escape character (http://bugs.winehq.org/show_bug.cgi?id=18346) > > The test fails on Wine but passes on WineTestBot. > > -John Chow > > You forgot the patch (and also in the second mail). -- Cheers, Paul.

1 0

Unable to Compile Wine on MacOSX
by James McKenzie Feb. 24, 2010

Feb. 24, 2010

Interestingly enough, I have run into the 'Unable to compile' problem building the latest git on MacOSX. Maybe there is corruption in my git pull, but this started yesterday.... It appears that configure never fully finishes and config.status loops. James McKenzie

2 1

Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [try 2]
by Vincent Povirk Feb. 24, 2010

Feb. 24, 2010

You should probably use a Bitmap object rather than the display for this, since the pixel format is important. That should make it possible to test other depths, even though they can't yet be implemented properly in Wine. Also, you should mark tests that fail in wine with todo_wine and remove the todo_wine in any subsequent patches that fix them. On Tue, Feb 23, 2010 at 8:56 PM, Justin Chevrier <jchevrier(a)gmail.com> wrote: > --- > dlls/gdiplus/tests/graphics.c | 45 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 45 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c > index 45bd9f7..97c520d 100644 > --- a/dlls/gdiplus/tests/graphics.c > +++ b/dlls/gdiplus/tests/graphics.c > @@ -21,6 +21,7 @@ > #include "windows.h" > #include "gdiplus.h" > #include "wingdi.h" > +#include "winuser.h" > #include "wine/test.h" > #include <math.h> > > @@ -2270,6 +2271,49 @@ static void test_GdipIsVisibleRect(void) > ReleaseDC(0, hdc); > } > > +static void test_GdipGetNearestColor(void) > +{ > + GpStatus status; > + GpGraphics *graphics = NULL; > + ARGB color = 0xdeadbeef; > + HDC hdc = GetDC(0); > + DEVMODEA dmA; > + BOOL ret; > + > + /* create a graphics object */ > + ok(hdc != NULL, "Expected HDC to be initialized\n"); > + > + status = GdipCreateFromHDC(hdc, &graphics); > + expect(Ok, status); > + ok(graphics != NULL, "Expected graphics to be initialized\n"); > + > + status = GdipGetNearestColor(graphics, NULL); > + expect(InvalidParameter, status); > + > + status = GdipGetNearestColor(NULL, &color); > + expect(InvalidParameter, status); > + > + ret = EnumDisplaySettingsA(NULL, ENUM_CURRENT_SETTINGS, &dmA); > + if (!ret) > + { > + skip("Could not determine color depth\n"); > + goto end; > + } > + > + if (dmA.dmBitsPerPel >= 24) > + { > + status = GdipGetNearestColor(graphics, &color); > + expect(Ok, status); > + ok(color == 0xdeadbeef, "expected 0xdeadbeef, got: 0x%08x\n", color); > + } > + else > + skip("Color depth less than 24bpp.\n"); > + > + end: > + GdipDeleteGraphics(graphics); > + ReleaseDC(0, hdc); > +} > + > START_TEST(graphics) > { > struct GdiplusStartupInput gdiplusStartupInput; > @@ -2296,6 +2340,7 @@ START_TEST(graphics) > test_GdipDrawLineI(); > test_GdipDrawLinesI(); > test_GdipDrawString(); > + test_GdipGetNearestColor(); > test_GdipGetVisibleClipBounds(); > test_GdipIsVisiblePoint(); > test_GdipIsVisibleRect(); > -- > 1.6.5.rc1 > > > >

2 4