wine-devel September 2008

wine-devel@winehq.org

116 participants
274 discussions

Request for feedback: gdi32/tests antialiasing patch
by Glenn Wurster 17 Sep '08

17 Sep '08

Last Thursday I submitted a patch which was silently dropped. I'd be interested if someone could take a look at it and let me know what I'm missing plase. I've included the original patch e-mail for reference. The patch was tested on XP, 98, and Wine. I also ran it through valgrind and it passed patchwatcher without any errors. I've had the conformance test sitting around for a while and believe it's best put in the wine source tree (especially as a conformance test for the new DIB engine). It's a conformance test for a bug I fixed years ago in the Wine source tree: * http://www.winehq.org/pipermail/wine-cvs/2005-January/013584.html * http://www.winehq.org/pipermail/wine-cvs/2005-January/013623.html Thanks for any assistance anyone may be able to provide. Glenn. On Thu, Sep 11, 2008 at 02:59:46PM -0400, Glenn Wurster wrote: > > Changelog: > gdi32/tests: Add font antialiasing tests > > Add tests to ensure that antialiasing is not used even if requested > when we are operating in a palette drawing mode, and that antialiasing > is used when operating in a non-palette mode. > > Changes since attempt 1: > * Clear the bitmap before we write the text to it. > * Document in this e-mail tests performed. > > Tested on XP (sp2), 98, and Wine, also run through Valgrind (did this on > the initial patch as well but forgot to mention that in the e-mail). > > Glenn Wurster. > > --- > dlls/gdi32/tests/font.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 163 insertions(+), 0 deletions(-) > diff --git a/dlls/gdi32/tests/font.c b/dlls/gdi32/tests/font.c > index 7d2c036..088d4e6 100644 > --- a/dlls/gdi32/tests/font.c > +++ b/dlls/gdi32/tests/font.c > @@ -2430,6 +2430,168 @@ static void test_orientation(void) > DeleteDC(hdc); > } > > +static void clear_bmp(HDC hdc, int width, int height, COLORREF colour) > +{ > + HBRUSH hbrush, hbrush_old; > + HPEN hpen, hpen_old; > + > + hbrush = CreateSolidBrush(colour); > + ok(hbrush != NULL, "CreateSolidBrush failed.\n"); > + > + hpen = CreatePen(PS_SOLID, 0, colour); > + ok(hpen != NULL, "CreatePen failed.\n"); > + > + hpen_old = SelectObject( hdc, hpen ); > + hbrush_old = SelectObject( hdc, hbrush ); > + ok(hpen_old != NULL, "SelectObject failed.\n"); > + ok(hbrush_old != NULL, "SelectObject failed.\n"); > + > + ok(Rectangle(hdc, 0, 0, width, height), "Rectangle failed.\n"); > + > + SelectObject(hdc, hbrush_old); > + DeleteObject(hbrush); > + SelectObject(hdc, hpen_old); > + DeleteObject(hpen); > +} > + > +static COLORREF check_bmp_colors(HDC hdc, COLORREF * colours, int colorCnt, int width, int height) > +{ > + COLORREF pixel; > + int x, y, z; > + for(y = 0; y < height; y++) > + { > + for(x = 0; x < width; x++) > + { > + pixel = GetPixel(hdc, x, y); > + for(z = 0; z < colorCnt; z++) > + { > + if(pixel == colours[z]) > + break; > + } > + if(z >= colorCnt) > + { > + return pixel; > + } > + } > + } > + return 0; > +} > + > +static void test_antialias(void) > +{ > + PALETTEENTRY paletteEntries[3] = { > + { 0x00, 0x00, 0x00, PC_NOCOLLAPSE }, > + { 0xFF, 0xFF, 0xFF, PC_NOCOLLAPSE }, > + { 0x44, 0x44, 0x44, PC_NOCOLLAPSE } > + }; > + HDC hdc; > + HFONT hfont, old_hfont; > + HPALETTE hpal, old_hpal; > + LOGPALETTE * lpal; > + HBITMAP hbmp, old_hbmp; > + BITMAPINFO * bmi; > + COLORREF colours[3]; > + int cntr; > + COLORREF pixel; > + > + hdc = CreateCompatibleDC(0); > + > + /* Create an antialiased font. We don't really care what the specific font is */ > + hfont = CreateFont(32, 0, 0, 0, FW_REGULAR, FALSE, FALSE, FALSE, ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, ANTIALIASED_QUALITY, DEFAULT_PITCH | FF_DONTCARE, NULL); > + old_hfont = SelectObject(hdc, hfont); > + ok(old_hfont != NULL, "SelectObject failed.\n"); > + > + /* Set up a palette */ > + lpal = (LOGPALETTE *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(LOGPALETTE) + 3*sizeof(PALETTEENTRY)); > + lpal->palNumEntries = 3; > + lpal->palVersion = 0x0300; > + lpal->palPalEntry[0] = paletteEntries[0]; > + lpal->palPalEntry[1] = paletteEntries[1]; > + lpal->palPalEntry[2] = paletteEntries[2]; > + hpal = CreatePalette(lpal); > + HeapFree(GetProcessHeap(), 0, lpal); > + old_hpal = SelectPalette(hdc, hpal, FALSE); > + ok(old_hpal != NULL, "SelectPalette failed.\n"); > + > + /* Create an 8bit bitmap to draw into */ > + bmi = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFO) + 3 * sizeof(RGBQUAD)); > + bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + bmi->bmiHeader.biWidth = 20; > + bmi->bmiHeader.biHeight = -20; > + bmi->bmiHeader.biPlanes = 1; > + bmi->bmiHeader.biBitCount = 8; > + bmi->bmiHeader.biCompression = BI_RGB; > + bmi->bmiHeader.biClrUsed = 3; > + for(cntr = 0; cntr < 3; cntr++) > + { > + bmi->bmiColors[cntr].rgbRed = paletteEntries[cntr].peRed; > + bmi->bmiColors[cntr].rgbGreen = paletteEntries[cntr].peGreen; > + bmi->bmiColors[cntr].rgbBlue = paletteEntries[cntr].peBlue; > + bmi->bmiColors[cntr].rgbReserved = 0; > + colours[cntr] = RGB(paletteEntries[cntr].peRed, paletteEntries[cntr].peGreen, paletteEntries[cntr].peBlue); > + } > + > + hbmp = CreateDIBSection(hdc, bmi, DIB_RGB_COLORS, 0, 0, 0); > + ok(hbmp != NULL, "error=%d\n", GetLastError()); > + old_hbmp = SelectObject(hdc, hbmp); > + ok(old_hbmp != NULL, "error=%d\n", GetLastError()); > + > + HeapFree(GetProcessHeap(), 0, bmi); > + > + /* Set up the text colours */ > + SetTextColor(hdc, RGB(0xFF, 0xFF, 0xFF)); > + SetBkColor(hdc, RGB(0, 0, 0)); > + SetBkMode(hdc, OPAQUE); > + > + /* Draw an 'O' offset to see if antialiasing was > + * used. Antialiasing should be restricted to colours in the > + * palette (if it is done at all). */ > + clear_bmp(hdc, 20, 20, RGB(0, 0, 0)); > + ok(ExtTextOut(hdc, 0, -4, 0, NULL, "O", 1, NULL), "ExtTextOut failed.\n"); > + pixel = check_bmp_colors(hdc, colours, 3, 20, 20); > + ok(pixel == 0, "Found invalid pixel: %x.\n", pixel); > + > + /* Cleanup the palette stuff */ > + SelectPalette(hdc, old_hpal, FALSE); > + DeleteObject(hpal); > + SelectObject(hdc, old_hbmp); > + DeleteObject(hbmp); > + > + /* Create an RGB bitmap to draw into */ > + bmi = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFO)); > + bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + bmi->bmiHeader.biWidth = 20; > + bmi->bmiHeader.biHeight = -20; > + bmi->bmiHeader.biPlanes = 1; > + bmi->bmiHeader.biBitCount = 32; > + bmi->bmiHeader.biCompression = BI_RGB; > + bmi->bmiHeader.biClrUsed = 0; > + > + hbmp = CreateDIBSection(hdc, bmi, DIB_RGB_COLORS, 0, 0, 0); > + ok(hbmp != NULL, "error=%d\n", GetLastError()); > + old_hbmp = SelectObject(hdc, hbmp); > + ok(old_hbmp != NULL, "error=%d\n", GetLastError()); > + > + HeapFree(GetProcessHeap(), 0, bmi); > + > + /* Draw an 'O' offset to see if antialiasing was used. > + * Antialiasing should be used when we specify an antialiasing > + * font and use a RGB bitmap. */ > + clear_bmp(hdc, 20, 20, RGB(0, 0, 0)); > + ok(ExtTextOut(hdc, 0, -4, 0, NULL, "O", 1, NULL), "ExtTextOut failed.\n"); > + pixel = check_bmp_colors(hdc, colours, 2, 20, 20); > + ok(pixel != 0, "Antialiasing was not used.\n"); > + > + /* Free the bitmap */ > + SelectObject(hdc, old_hbmp); > + DeleteObject(hbmp); > + > + /* Free the rest of our memory */ > + SelectObject(hdc, old_hfont); > + DeleteObject(hfont); > + DeleteDC(hdc); > +} > + > START_TEST(font) > { > init(); > @@ -2449,6 +2611,7 @@ START_TEST(font) > test_GetFontUnicodeRanges(); > test_nonexistent_font(); > test_orientation(); > + test_antialias(); > > /* On Windows Arial has a lot of default charset aliases such as Arial Cyr, > * I'd like to avoid them in this test. >

1 0

Rejected patches needing review.
by Peter Dons Tychsen 17 Sep '08

17 Sep '08

Hello. I have a problem loading a specific proprietary driver. I traced the problem to two bugs in: - services - winedevice The two bugs caused the loading to fail. I created and tested two fixes to solve the problem, but both patches were silently rejected. Can some review them before i re-send them? I have looked them over several time, but i do not see a problem with them. The only "problem" is that there are no test cases for these programs, as there is no such place for such. Thanks, /pedro

4 5

Re: [PATCH] pass correct buffersize to LCMapStringW
by Dmitry Timoshkov 16 Sep '08

16 Sep '08

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > diff --git a/dlls/kernel32/tests/locale.c b/dlls/kernel32/tests/locale.c > index f792da2..a49953b 100644 > --- a/dlls/kernel32/tests/locale.c > +++ b/dlls/kernel32/tests/locale.c > @@ -1268,7 +1268,7 @@ static void test_LCMapStringW(void) > /* otherwise src == dst should fail */ > SetLastError(0xdeadbeef); > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | LCMAP_UPPERCASE, > - buf, 10, buf, sizeof(buf)); > + buf, 10, buf, sizeof(buf)/sizeof(WCHAR)); > ok(GetLastError() == ERROR_INVALID_FLAGS /* NT */ || > GetLastError() == ERROR_INVALID_PARAMETER /* Win9x */, > "unexpected error code %d\n", GetLastError()); > @@ -1276,40 +1276,40 @@ static void test_LCMapStringW(void) > > /* test whether '\0' is always appended */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - upper_case, -1, buf, sizeof(buf)); > + upper_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - upper_case, lstrlenW(upper_case), buf2, sizeof(buf2)); > + upper_case, lstrlenW(upper_case), buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORECASE */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORECASE, > - upper_case, -1, buf, sizeof(buf)); > + upper_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - lower_case, -1, buf2, sizeof(buf2)); > + lower_case, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORENONSPACE */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORENONSPACE, > - lower_case, -1, buf, sizeof(buf)); > + lower_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - lower_case, -1, buf2, sizeof(buf2)); > + lower_case, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORESYMBOLS */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORESYMBOLS, > - lower_case, -1, buf, sizeof(buf)); > + lower_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - symbols_stripped, -1, buf2, sizeof(buf2)); > + symbols_stripped, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); LCMAP_SORTKEY takes the target buffer size in bytes in both A and W versions. > @@ -1332,7 +1332,7 @@ static void test_LCMapStringW(void) > > /* test srclen = 0 */ > SetLastError(0xdeadbeef); > - ret = LCMapStringW(LOCALE_USER_DEFAULT, 0, upper_case, 0, buf, sizeof(buf)); > + ret = LCMapStringW(LOCALE_USER_DEFAULT, 0, upper_case, 0, buf, sizeof(buf)/sizeof(WCHAR)); > ok(!ret, "LCMapStringW should fail with srclen = 0\n"); > ok(GetLastError() == ERROR_INVALID_PARAMETER, > "unexpected error code %d\n", GetLastError()); The size of the target buffer doesn't matter at all in this case, since the API is supposed to fail due to source length being 0. -- Dmitry.

5 8

Wineconf - final reminder!
by Jeremy White 16 Sep '08

16 Sep '08

Folks, Just 11 days until Wineconf. Come celebrate Wine 1.0! http://wiki.winehq.org/WineConf2008 I'll start up a thread for RSVPs and such on the wineconf mailing list. Cheers, Jeremy

1 0

Re: winemenubuilder: eliminate wineshelllink (try 5)
by Alexandre Julliard 16 Sep '08

16 Sep '08

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > + do > + { > + line = HeapAlloc(GetProcessHeap(), 0, size); > + if (!line) > + return NULL; > + ret = fgets(line, size, file); > + if (ret != NULL) > + { > + if (strlen(line) < size - 1) > + return line; > + size *= 2; > + } > + HeapFree(GetProcessHeap(), 0, line); > + } while (ret != NULL); This won't do what you want. > + char *line; > + while ((line = next_line(originalMenu)) != NULL) > + { > + if (strstr(line, "<Filename>")) > + { > + if (strstr(line, name)) > + found = TRUE; > + fprintf(tempfile, "%s", line); > + } strstr is not appropriate for comparing file names. Also you are leaking memory here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: Implementing d3dx9_36.dll.D3DXCreateTexture
by Andrew Fenn 16 Sep '08

16 Sep '08

D3DXCheckTextureRequirements has already been implemented and a patch was submitted here: http://www.winehq.org/pipermail/wine-patches/2008-April/053547.html Please check it out. On Tue, Sep 16, 2008 at 2:20 PM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > For basic operation just forwarding to the d3d9 CreateTexture call should work fine but note the following: > "Internally, D3DXCreateTexture uses D3DXCheckTextureRequirements to adjust the calling parameters. Therefore, calls to D3DXCreateTexture will often succeed where calls to IDirect3DDevice9::CreateTexture would fail." > > As a start I wouldn't add that behavior but add a comment that the function isn't complete and what is missing. I would also print a FIXME about it but only show it once in total (so use a static variable). > > Roderick > >> Hi list, >> >> I'm trying to get a DirectX model viewer[1] to run. Using wine 1.1.4 it >> is possible to lauch because d3dx9_36.dll exists but a method >> (CreateTexture) of it is stubbed out. I started looking for details on >> this and came up with this MSDN link[2]. Looking at the code I found >> that this method is already implemented in the core d3d9 library in >> dlls/d3d9/texture.c. From what I understand a forward to this function >> should be enough to get this method to work since the parameters seem to >> match (except the last parameter in the core d3d9 (HANDLE* >> pSharedHandle) does not exist in the MSDN definition). >> >> Can someone please comment if my thoughts are right here? >> >> Thanks, >> Christoph >> >> [1] http://www.teamxtcgames.com/3d_object_viewer.htm >> [2] http://msdn.microsoft.com/en-us/library/bb172800(VS.85).aspx >> >> > > -- > GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! > http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691… > > >

1 0

Implementing d3dx9_36.dll.D3DXCreateTexture
by Christoph Brill 16 Sep '08

16 Sep '08

Hi list, I'm trying to get a DirectX model viewer[1] to run. Using wine 1.1.4 it is possible to lauch because d3dx9_36.dll exists but a method (CreateTexture) of it is stubbed out. I started looking for details on this and came up with this MSDN link[2]. Looking at the code I found that this method is already implemented in the core d3d9 library in dlls/d3d9/texture.c. From what I understand a forward to this function should be enough to get this method to work since the parameters seem to match (except the last parameter in the core d3d9 (HANDLE* pSharedHandle) does not exist in the MSDN definition). Can someone please comment if my thoughts are right here? Thanks, Christoph [1] http://www.teamxtcgames.com/3d_object_viewer.htm [2] http://msdn.microsoft.com/en-us/library/bb172800(VS.85).aspx

2 1

Interesting Chromium hacks...er..patches
by Jeremy White 15 Sep '08

15 Sep '08

We've had a lot of fun hacking on Chromium these past few weeks. We did have a few things that we rushed along to include in the CrossOver Chromium builds that haven't properly baked here on wine-devel. I thought I'd share them in case anyone else wants to match what we did. First of all, we were working against dev build 21 of Chromium, not Chrome. Note that newer builds of Chromium now work (thanks to a patch by Alexandre), but they're pretty unstable. We got our dev build from here: http://build.chromium.org/buildbot/archives/chromium.tgz We find we have to have both Times and Arial (or replacements in the registry) in order for it to run stably. We have 3 winhttp patches we used that we're going to clean up and get into WineHQ properly, but here they are in raw form: winhttp_reset_content_length.diff fixes a glitch in winhttp on redirects. winhttp_flags.diff fixes a fairly obvious mistake (and turns out to be the gating factor for gmail support) winhttp_cookies.diff is the beginning of a cookie manager; Hans is still working on this one. Also, we used the following ...er...patches: focus.diff (hack by Alexandre, makes single tabs work okay) gdi hack by Huw, makes the map hand on maps.google.com not a blob Cheers, Jeremy

1 0

General Questions
by Scott Lindeneau 15 Sep '08

15 Sep '08

I haven't had time to work on the AcceptEx patch since the last time I submitted it to wine-patches. I still cannot reproduce the bug's patchwatcher indicated but I had a few questions regarding the whole process. When I finally get the patches to pass the patchwatcher regression test, is there anyway for me to know what is going on with the patch. Is Juilliard looking at them? Are they rejected? How long does the patch review process take? Is it just Julliard doing them? In regards to the AcceptEx patch in particular: I know that there is extra attention paid to patches that modify the wineserver. Should I spend extra time writing a discussion as to the reasons why I felt the modifications needed to take place within the wineserver? With the AcceptEx patch I kind of just plowed ahead and did what I thought needed to be done to make the functions work. Should I spend more time discussing what I intend to do in the patches with someone else before submitting them? Is someone willing to do this peer review with me? (Note: I don't have a lot of time to program). And lastly: Am I doing anything wrong (in general. not simply in coding)? I don't know how these internet based, user based systems work. I've never tried working with one before. Is there anything else someone wants me to work on? ~Scott

2 1

re: Patchwatcher should ignore AppDB patches
by Dan Kegel 15 Sep '08

15 Sep '08

Right, it should ignore those patches. I'm going to add a configurable regular expression to the patch detector to let it do that. (That is, when I get a chance. I'm cranking on native Chrome these days.)

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
28
Older →

Jump to page:

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 September 2008