November 2009 - Wine-Devel - list.winehq.org

Re: New version of my test for bug 4543

by Charles Davis

Paul Vriens wrote: > On 11/19/2009 11:17 PM, Charles Davis wrote: >> Hi, >> >> This is a new version of my test for bug 4543. This time, I followed >> Dmitry's suggestion of using the existing functions for comparing the >> contents of EMFs. I can't build tests for Windows both due to bug 20763 >> and due to the fact that I don't have any Windows boxes, so once again I >> need people to run this test on Windows to make sure it's an accurate >> representation of Windows' behavior. The test currently succeeds on Wine. >> >> Thanks in advance. >> >> Chip >> >> >> >> > I'll give it a try on some of my (VMware) boxes tomorrow. > Thanks. I almost forgot: some of the test is if(0)'d out because it crashes on Wine (right now). So, you may wish to un-if(0) the crashing test when you run on Windows. I'm particularly interested in the EMF that the test produces on Windows (it should dump it to the console if you run with WINETEST_DEBUG=1), so that would be really helpful. Chip

Nov. 19, 2009

Re: New version of my test for bug 4543

by Charles Davis

Ricardo Filipe wrote: > 2009/11/19 Charles Davis <cdavis(a)mymail.mines.edu>: >> Hi, >> >> This is a new version of my test for bug 4543. This time, I followed >> Dmitry's suggestion of using the existing functions for comparing the >> contents of EMFs. I can't build tests for Windows both due to bug 20763 >> and due to the fact that I don't have any Windows boxes, so once again I >> need people to run this test on Windows to make sure it's an accurate >> representation of Windows' behavior. The test currently succeeds on Wine. >> >> Thanks in advance. >> >> Chip >> >> From 574bb4f7b2b90a209b1693b7f8048a2eb271ada8 Mon Sep 17 00:00:00 2001 >> From: Charles Davis <cdavis(a)mymail.mines.edu> >> Date: Tue, 17 Nov 2009 11:10:50 -0700 >> Subject: [PATCH] gdi32/tests: Test BitBlt() to an enhanced metafile. >> To: wine-patches <wine-patches(a)winehq.org> >> Reply-To: wine-devel <wine-devel(a)winehq.org> >> >> --- >> dlls/gdi32/tests/metafile.c | 125 +++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 125 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c >> index b559901..3bd413b 100644 >> --- a/dlls/gdi32/tests/metafile.c >> +++ b/dlls/gdi32/tests/metafile.c >> @@ -1030,6 +1030,63 @@ static const unsigned char EMF_LINETO_MM_TEXT_BITS[] = { >> 0x14, 0x00, 0x00, 0x00 >> }; >> >> +static const unsigned char EMF_BITBLT[] = >> +{ >> + 0x01, 0x00, 0x00, 0x00, 0x6c, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x94, 0x00, 0x00, 0x00, 0x79, 0x00, 0x00, 0x00, >> + 0x20, 0x45, 0x4d, 0x46, 0x00, 0x00, 0x01, 0x00, >> + 0xa0, 0x01, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, >> + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x04, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, >> + 0xfc, 0x01, 0x00, 0x00, 0x38, 0x01, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x60, 0xc0, 0x07, 0x00, >> + 0xc0, 0xc2, 0x04, 0x00, 0x4c, 0x00, 0x00, 0x00, >> + 0xbc, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, >> + 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, >> + 0x04, 0x00, 0x00, 0x00, 0x20, 0x00, 0xcc, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x64, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, >> + 0x8c, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, >> + 0x28, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, >> + 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, >> + 0xc4, 0x0e, 0x00, 0x00, 0xc4, 0x0e, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x4c, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x04, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, >> + 0x62, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, >> + 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x10, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00 >> +}; >> + >> + >> /* For debugging or dumping the raw metafiles produced by >> * new test functions. >> */ >> @@ -1382,6 +1439,73 @@ static int compare_emf_bits(const HENHMETAFILE mf, const unsigned char *bits, >> return 0; >> } >> >> + >> +/* tests blitting to an EMF */ >> +static void test_emf_BitBlt(void) >> +{ >> + HDC hdcDisplay, hdcMetafile, hdcBitmap; >> + HBITMAP hBitmap, hOldBitmap; >> + HENHMETAFILE hMetafile; >> +#define BMP_DIM 4 >> + BITMAPINFOHEADER bmih = >> + { >> + sizeof(BITMAPINFOHEADER), >> + BMP_DIM,/* biWidth */ >> + BMP_DIM,/* biHeight */ >> + 1, /* biPlanes */ >> + 24, /* biBitCount */ >> + BI_RGB, /* biCompression */ >> + 0, /* biXPelsPerMeter */ >> + 0, /* biYPelsPerMeter */ >> + 0, /* biClrUsed */ >> + 0, /* biClrImportant */ >> + }; >> + void *bits; >> + BOOL ret; >> + >> + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); >> + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); >> + >> + hdcBitmap = CreateCompatibleDC(hdcDisplay); >> + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); >> + bmih.biXPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSX), 100, 3937); >> + bmih.biYPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSY), 100, 3937); >> + hBitmap = CreateDIBSection(hdcDisplay, (const BITMAPINFO *)&bmih, >> + DIB_RGB_COLORS, &bits, NULL, 0); >> + hOldBitmap = SelectObject(hdcBitmap, hBitmap); >> + >> + hdcMetafile = CreateEnhMetaFileA(hdcBitmap, NULL, NULL, NULL); >> + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); >> + >> + /* First fill the bitmap DC with something recognizable, like BLACKNESS */ >> + ret = BitBlt(hdcBitmap, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, BLACKNESS); >> + ok( ret, "BitBlt(BLACKNESS) failed\n" ); >> + >> + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, hdcBitmap, 0, 0, SRCCOPY); >> + ok( ret, "BitBlt(SRCCOPY) failed\n" ); >> + if(0) /* Crashes on wine */ >> + { >> + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, WHITENESS); >> + ok( ret, "BitBlt(WHITENESS) failed\n" ); >> + } >> + >> + hMetafile = CloseEnhMetaFile(hdcMetafile); >> + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); >> + >> + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), >> + "emf_BitBlt", FALSE) != 0) >> + { >> + dump_emf_bits(hMetafile, "emf_BitBlt"); >> + dump_emf_records(hMetafile, "emf_BitBlt"); >> + } >> + >> + SelectObject(hdcBitmap, hOldBitmap); >> + DeleteObject(hBitmap); >> + DeleteDC(hdcBitmap); >> + DeleteDC(hdcDisplay); >> +#undef BMP_DIM >> +} >> + >> /* Test a blank metafile. May be used as a template for new tests. */ >> >> static void test_mf_Blank(void) >> @@ -2628,6 +2752,7 @@ START_TEST(metafile) >> /* For enhanced metafiles (enhmfdrv) */ >> test_ExtTextOut(); >> test_SaveDC(); >> + test_emf_BitBlt(); >> >> /* For win-format metafiles (mfdrv) */ >> test_mf_SaveDC(); >> -- >> 1.6.5.2 >> >> >> >> >> > it would really help you get some more tests if you just cross > compiled the dll, hosted it somewhere and gave the link on the email > ;) not all of us are on linux when we read the mail or have a compiler > ready on windows :) I told you, I can't cross-compile for Windows right now. See bug 20763. Chip

Nov. 19, 2009

Re: msi regression in today's git -- NEVER MIND

by Susan Cragin

I had a bad git. Re-did everything and now it works. Sorry about that. Susan -----Original Message----- >Installed Dragon NaturallySpeaking using clean prefix and today's git. >Instal went "without errors" but when I tried to open the program it said that the install hadn't completed correctly. >Specifically, iexplore.exe was missing. >I looked at the terminal output for the run but there wasn't anything interesting. > >Susan >

Nov. 19, 2009

Re: New version of my test for bug 4543

by Ricardo Filipe

2009/11/19 Charles Davis <cdavis(a)mymail.mines.edu>: > Hi, > > This is a new version of my test for bug 4543. This time, I followed > Dmitry's suggestion of using the existing functions for comparing the > contents of EMFs. I can't build tests for Windows both due to bug 20763 > and due to the fact that I don't have any Windows boxes, so once again I > need people to run this test on Windows to make sure it's an accurate > representation of Windows' behavior. The test currently succeeds on Wine. > > Thanks in advance. > > Chip > > From 574bb4f7b2b90a209b1693b7f8048a2eb271ada8 Mon Sep 17 00:00:00 2001 > From: Charles Davis <cdavis(a)mymail.mines.edu> > Date: Tue, 17 Nov 2009 11:10:50 -0700 > Subject: [PATCH] gdi32/tests: Test BitBlt() to an enhanced metafile. > To: wine-patches <wine-patches(a)winehq.org> > Reply-To: wine-devel <wine-devel(a)winehq.org> > > --- > dlls/gdi32/tests/metafile.c | 125 +++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 125 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c > index b559901..3bd413b 100644 > --- a/dlls/gdi32/tests/metafile.c > +++ b/dlls/gdi32/tests/metafile.c > @@ -1030,6 +1030,63 @@ static const unsigned char EMF_LINETO_MM_TEXT_BITS[] = { > 0x14, 0x00, 0x00, 0x00 > }; > > +static const unsigned char EMF_BITBLT[] = > +{ > + 0x01, 0x00, 0x00, 0x00, 0x6c, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x94, 0x00, 0x00, 0x00, 0x79, 0x00, 0x00, 0x00, > + 0x20, 0x45, 0x4d, 0x46, 0x00, 0x00, 0x01, 0x00, > + 0xa0, 0x01, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, > + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x04, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, > + 0xfc, 0x01, 0x00, 0x00, 0x38, 0x01, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x60, 0xc0, 0x07, 0x00, > + 0xc0, 0xc2, 0x04, 0x00, 0x4c, 0x00, 0x00, 0x00, > + 0xbc, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, > + 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, > + 0x04, 0x00, 0x00, 0x00, 0x20, 0x00, 0xcc, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x64, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, > + 0x8c, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, > + 0x28, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, > + 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, > + 0xc4, 0x0e, 0x00, 0x00, 0xc4, 0x0e, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x4c, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x04, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, > + 0x62, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, > + 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x10, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00 > +}; > + > + > /* For debugging or dumping the raw metafiles produced by > * new test functions. > */ > @@ -1382,6 +1439,73 @@ static int compare_emf_bits(const HENHMETAFILE mf, const unsigned char *bits, > return 0; > } > > + > +/* tests blitting to an EMF */ > +static void test_emf_BitBlt(void) > +{ > + HDC hdcDisplay, hdcMetafile, hdcBitmap; > + HBITMAP hBitmap, hOldBitmap; > + HENHMETAFILE hMetafile; > +#define BMP_DIM 4 > + BITMAPINFOHEADER bmih = > + { > + sizeof(BITMAPINFOHEADER), > + BMP_DIM,/* biWidth */ > + BMP_DIM,/* biHeight */ > + 1, /* biPlanes */ > + 24, /* biBitCount */ > + BI_RGB, /* biCompression */ > + 0, /* biXPelsPerMeter */ > + 0, /* biYPelsPerMeter */ > + 0, /* biClrUsed */ > + 0, /* biClrImportant */ > + }; > + void *bits; > + BOOL ret; > + > + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); > + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); > + > + hdcBitmap = CreateCompatibleDC(hdcDisplay); > + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); > + bmih.biXPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSX), 100, 3937); > + bmih.biYPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSY), 100, 3937); > + hBitmap = CreateDIBSection(hdcDisplay, (const BITMAPINFO *)&bmih, > + DIB_RGB_COLORS, &bits, NULL, 0); > + hOldBitmap = SelectObject(hdcBitmap, hBitmap); > + > + hdcMetafile = CreateEnhMetaFileA(hdcBitmap, NULL, NULL, NULL); > + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); > + > + /* First fill the bitmap DC with something recognizable, like BLACKNESS */ > + ret = BitBlt(hdcBitmap, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, BLACKNESS); > + ok( ret, "BitBlt(BLACKNESS) failed\n" ); > + > + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, hdcBitmap, 0, 0, SRCCOPY); > + ok( ret, "BitBlt(SRCCOPY) failed\n" ); > + if(0) /* Crashes on wine */ > + { > + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, WHITENESS); > + ok( ret, "BitBlt(WHITENESS) failed\n" ); > + } > + > + hMetafile = CloseEnhMetaFile(hdcMetafile); > + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); > + > + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), > + "emf_BitBlt", FALSE) != 0) > + { > + dump_emf_bits(hMetafile, "emf_BitBlt"); > + dump_emf_records(hMetafile, "emf_BitBlt"); > + } > + > + SelectObject(hdcBitmap, hOldBitmap); > + DeleteObject(hBitmap); > + DeleteDC(hdcBitmap); > + DeleteDC(hdcDisplay); > +#undef BMP_DIM > +} > + > /* Test a blank metafile. May be used as a template for new tests. */ > > static void test_mf_Blank(void) > @@ -2628,6 +2752,7 @@ START_TEST(metafile) > /* For enhanced metafiles (enhmfdrv) */ > test_ExtTextOut(); > test_SaveDC(); > + test_emf_BitBlt(); > > /* For win-format metafiles (mfdrv) */ > test_mf_SaveDC(); > -- > 1.6.5.2 > > > > > it would really help you get some more tests if you just cross compiled the dll, hosted it somewhere and gave the link on the email ;) not all of us are on linux when we read the mail or have a compiler ready on windows :)

Nov. 19, 2009

New version of my test for bug 4543

by Charles Davis

Hi, This is a new version of my test for bug 4543. This time, I followed Dmitry's suggestion of using the existing functions for comparing the contents of EMFs. I can't build tests for Windows both due to bug 20763 and due to the fact that I don't have any Windows boxes, so once again I need people to run this test on Windows to make sure it's an accurate representation of Windows' behavior. The test currently succeeds on Wine. Thanks in advance. Chip >From 574bb4f7b2b90a209b1693b7f8048a2eb271ada8 Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to an enhanced metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 125 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 125 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..3bd413b 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -1030,6 +1030,63 @@ static const unsigned char EMF_LINETO_MM_TEXT_BITS[] = { 0x14, 0x00, 0x00, 0x00 }; +static const unsigned char EMF_BITBLT[] = +{ + 0x01, 0x00, 0x00, 0x00, 0x6c, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x94, 0x00, 0x00, 0x00, 0x79, 0x00, 0x00, 0x00, + 0x20, 0x45, 0x4d, 0x46, 0x00, 0x00, 0x01, 0x00, + 0xa0, 0x01, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x04, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, + 0xfc, 0x01, 0x00, 0x00, 0x38, 0x01, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x60, 0xc0, 0x07, 0x00, + 0xc0, 0xc2, 0x04, 0x00, 0x4c, 0x00, 0x00, 0x00, + 0xbc, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x04, 0x00, 0x00, 0x00, 0x20, 0x00, 0xcc, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x64, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, + 0x8c, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, + 0x28, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, + 0xc4, 0x0e, 0x00, 0x00, 0xc4, 0x0e, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x4c, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x04, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x62, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, + 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x10, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00 +}; + + /* For debugging or dumping the raw metafiles produced by * new test functions. */ @@ -1382,6 +1439,73 @@ static int compare_emf_bits(const HENHMETAFILE mf, const unsigned char *bits, return 0; } + +/* tests blitting to an EMF */ +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; +#define BMP_DIM 4 + BITMAPINFOHEADER bmih = + { + sizeof(BITMAPINFOHEADER), + BMP_DIM,/* biWidth */ + BMP_DIM,/* biHeight */ + 1, /* biPlanes */ + 24, /* biBitCount */ + BI_RGB, /* biCompression */ + 0, /* biXPelsPerMeter */ + 0, /* biYPelsPerMeter */ + 0, /* biClrUsed */ + 0, /* biClrImportant */ + }; + void *bits; + BOOL ret; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + bmih.biXPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSX), 100, 3937); + bmih.biYPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSY), 100, 3937); + hBitmap = CreateDIBSection(hdcDisplay, (const BITMAPINFO *)&bmih, + DIB_RGB_COLORS, &bits, NULL, 0); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + hdcMetafile = CreateEnhMetaFileA(hdcBitmap, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + /* First fill the bitmap DC with something recognizable, like BLACKNESS */ + ret = BitBlt(hdcBitmap, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, BLACKNESS); + ok( ret, "BitBlt(BLACKNESS) failed\n" ); + + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt(SRCCOPY) failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, WHITENESS); + ok( ret, "BitBlt(WHITENESS) failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), + "emf_BitBlt", FALSE) != 0) + { + dump_emf_bits(hMetafile, "emf_BitBlt"); + dump_emf_records(hMetafile, "emf_BitBlt"); + } + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); + DeleteDC(hdcDisplay); +#undef BMP_DIM +} + /* Test a blank metafile. May be used as a template for new tests. */ static void test_mf_Blank(void) @@ -2628,6 +2752,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

Nov. 19, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Austin Lund

2009/11/19 Paul Vriens <paul.vriens.wine(a)gmail.com>: > On 11/19/2009 01:23 PM, Austin Lund wrote: >> >> - ok (pFileStructA->uFileDate == pFileStructW->uDate2&& >> - pFileStructA->uFileTime == pFileStructW->uTime2, >> - "Last write time should match last access time!\n"); >> - > > Hi Austin, > > Is there no other way to get around this? I think it's a bit of a shame > having tests removed for that odd system that has a FAT filesystem on a NT4+ > box. > The date is always within 1 day (plus or minus). I guess it would be possible to implement a calendar addition and subtraction algorithm. Is there one already available somewhere that could be used with this bit packed structure in a test? The time could be anything, except perhaps the seconds. On my trials with this, it always seems to have the seconds as zero. I'm not sure if you can set a timezone that has a delta with non-zero seconds. On thinking about this, the way I'd do this is: if dates and times are equal then pass else check the rough rules as outlined But is it ok (or even sensible to do): if (date1 == date2 && time1 == time2) ok(TRUE, "Blah"); else { /* some other test */ } or would you leave out the ok()?

Nov. 19, 2009

Re: Write-past-end in FileMonikerImpl_DecomposePath()

by Dan Kegel

Filed as http://bugs.winehq.org/show_bug.cgi?id=20760 On Thu, Nov 19, 2009 at 9:11 AM, Dan Kegel <dank(a)kegel.com> wrote: > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-hlink_hlink.txt > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-hlink_hlink.txt > shows a new error thanks to the heap tail check. > > Looks like a level-of-indirection-during-allocation error, > 1039 strgtable = CoTaskMemAlloc(len*sizeof(WCHAR)); > should be > 1039 strgtable = CoTaskMemAlloc(len*sizeof(WCHAR *)); > > Ulrich, you were in there last, could you have a look? > > Invalid write of size 4 > at FileMonikerImpl_DecomposePath (filemoniker.c:1056) > by FileMonikerImpl_Construct (filemoniker.c:1375) > by CreateFileMoniker (filemoniker.c:1443) > by FileMoniker_CreateFromDisplayName (filemoniker.c:1484) > by MkParseDisplayName (moniker.c:1130) > by HlinkCreateFromString (hlink_main.c:124) > by test_persist (hlink.c:479) > by func_hlink (hlink.c:1122) > by run_test (test.h:535) > by main (test.h:585) > Address 0x7f04416c is 4 bytes inside a block of size 6 alloc'd > at notify_alloc (heap.c:279) > by RtlAllocateHeap (heap.c:1521) > by IMalloc_fnAlloc (ifs.c:186) > by CoTaskMemAlloc (ifs.c:562) > by FileMonikerImpl_DecomposePath (filemoniker.c:1039) > by FileMonikerImpl_Construct (filemoniker.c:1375) > by CreateFileMoniker (filemoniker.c:1443) > by FileMoniker_CreateFromDisplayName (filemoniker.c:1484) > by MkParseDisplayName (moniker.c:1130) > by HlinkCreateFromString (hlink_main.c:124) > by test_persist (hlink.c:479) >

Nov. 19, 2009

Re: winspool.drv: Acroread 9.2 relies on the buffer sizes returned by GetPrinterA and GetPrinterDriverA being large enough to hold their respective unicode versions' data.

by Detlef Riekenberg

On Do, 2009-11-19 at 13:18 +0000, Huw Davies wrote: > --- > dlls/winspool.drv/info.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) ANSI functions in winspool.drv have this behavior since w2k. We have already a test for EnumPrintersA/W [required by Outlook2003) I prefer to make such buffer size requirements also the default in Wine. We are able to simplify a lot of ANSI Functions, when we use this way. Alexandre, is this acceptable for you? -- By by ... Detlef

Nov. 19, 2009

Re: FAT32 support (was: [RFC] Handle process token groups in server/file.c::sd_to_mode)

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Chitescu wrote: > How should server/file.c sd_to_mode() deal with filesystems that don't support > full POSIX ownership and access permissions? It is quite popular to mount FAT > filesystems - either from a removable media or a partition shared with a > Windows installation. FAT32 support To support this, I think the following would need to be done: * Possibly split out and extended the filesystem type autodetection code in dlls/ntdll/file.c::get_device_info() to autodetect the filesystem's ability to hold ACLs * Implement NtQueryVolumeInformationFile(FileFsAttributeInformation) - this has flags such as: * FILE_PERSISTENT_ACLS: Persistent ACLs (NTFS vs FAT32), * FILE_CASE_SENSITIVE_SEARCH: case-sensitive search (POSIX) - this also has the name of the filesystem (e.g. NTFS, FAT32). * Implement the honouring of FILE_PERSISTENT_ACLS in NtQuerySecurityObject, NtSetSecurityObject * Possibly add a filesystem type configuration option to winecfg (separate to media type). * Possibly honour the media and filesystem type settings as configured by winecfg. > Furthermore, there could be symlinks to such files so filesystem capability > should be detected somehow from the file itself. Volume Mount Point support * Possibly extend dosdevices to include devices for Volume Mount Points. * Possibly implement detection of symbolic links leading to mount points as volume mount points - i.e. create \Device entries for mount points, and redirect Volume Mount Point targets to those devices. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksFo3YACgkQTHDAI68NsunoigCfTQQQI6UpD8kCOBL5G83hzjgh ahMAniPZq9CsVOnZHyko/1Hucc362Wql =oWXW -----END PGP SIGNATURE-----

Nov. 19, 2009

Re: Problem to download git

by Paul Vriens

On 11/19/2009 07:43 PM, paulo lesgaz wrote: > I still have the same problem today > And I use Linux. Not a mac. > I have a very slow connection here (128kb/s) (French polynesia :D). > Could it be the culprit? > > D. Adam > I had issues a few hours ago and I have 20Mb/s. I don't use a proxy and on second try things worked. -- Cheers, Paul.

Nov. 19, 2009

Re: Problem to download git

by paulo lesgaz

I still have the same problem today And I use Linux. Not a mac. I have a very slow connection here (128kb/s) (French polynesia :D). Could it be the culprit? D. Adam dadam(a)analyst:~$ export http_proxy=”http://proxy.upf.pf:8080″ dadam(a)analyst:~$ git clone http://source.winehq.org/git/wine.git ~/wine Initialized empty Git repository in /home/dadam/wine/.git/ Getting alternates list for http://source.winehq.org/git/wine.git Getting pack list for http://source.winehq.org/git/wine.git Getting index for pack 0ece042377e5e1fe77ac71b065cf360c0244774e Getting index for pack 72c84da3f0d9b4fd0dad04f1ce7244dadce37a43 Getting index for pack 6c18f6d3a2d8e85a33e7981ead83b64e4c36bc8c Getting index for pack 7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75 Getting pack 7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75 which contains 7f5b24ed9186d457acd7803a97d4171f332c5fb2 walk 7f5b24ed9186d457acd7803a97d4171f332c5fb2 Getting pack 0ece042377e5e1fe77ac71b065cf360c0244774e which contains 30815a50ed6a1b7ede26a1f0685bf687bf56e0ed error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack-0ece042377e5e1fe77a… transfer closed with 110180858 bytes remaining to read error: Unable to find 30815a50ed6a1b7ede26a1f0685bf687bf56e0ed under http://source.winehq.org/git/wine.git Cannot obtain needed object 30815a50ed6a1b7ede26a1f0685bf687bf56e0ed while processing commit 7f5b24ed9186d457acd7803a97d4171f332c5fb2. --- En date de : Jeu 19.11.09, Juan Lang <juan.lang(a)gmail.com> a écrit : De: Juan Lang <juan.lang(a)gmail.com> Objet: Re: Problem to download git À: "paulo lesgaz" <jeremielapuree(a)yahoo.fr> Cc: "wine" <wine-devel(a)winehq.org> Date: Jeudi 19 Novembre 2009, 5h16 > error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack-7c2ab792c6e1c8f603b… Is this on a Mac, by any chance? I had similar problems using MacPorts's git with a proxy server. I also had Linux running in a VM on that machine, and fetching from the Linux VM always succeeded. The odd thing is, fetching from Linux also fixed the MacPorts git fetch for me, at least until the next day's update. If this isn't on a Mac, I don't know what to tell you. --Juan

Nov. 19, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Dan Kegel

On Thu, Nov 19, 2009 at 7:37 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/ >> is the first full run with the heap tail check enabled. > > So you use some private patches for that, why aren't they merged? 'Cause I just wrote it an hour before that message? I already posted it to wine-devel for the curious. I'll try to post to wine-patches today or so. In the meantime I've updated http://wiki.winehq.org/Valgrind to link to the patch. I'm not sure about the user (i.e. developer) interface for turning the heap check on. Should it be automatic when one does warn+heap? Or should it need an environment variable or registry setting to turn it on? How should the user control the size of the redzone (a feature Microsoft doesn't seem to offer)? For what it's worth, Windows seems to turn the debug heap on by default when running apps under a debugger, and lets you disable it by setting the environment variable _NO_DEBUG_HEAP=1. That makes me think we should turn this feature on automatically under warn+heap. For finer control, setting _NO_DEBUG_HEAP=1 would disable it, and setting WINE_HEAP_REDZONE would let you pick how big a redzone to use. (Usually 16 bytes is enough, but I've seen bugs that misses but 64 bytes catches.) - Dan

Nov. 19, 2009

Re: GdiplusAbort type needs to be translated from C++ to C

by Vincent Povirk

On Thu, Nov 19, 2009 at 11:05 AM, Frank Richter <frank.richter(a)gmail.com> wrote: >> Does this look correct? > > You forgot __stdcall on 'Abort' member of gpabort_vtable. WINAPI should be equivalent, but you're probably right. I should match the windows headers/documentation. -- Vincent Povirk

Nov. 19, 2009

Write-past-end in FileMonikerImpl_DecomposePath()

by Dan Kegel

http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-hlink_hlink.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-hlink_hlink.txt shows a new error thanks to the heap tail check. Looks like a level-of-indirection-during-allocation error, 1039 strgtable = CoTaskMemAlloc(len*sizeof(WCHAR)); should be 1039 strgtable = CoTaskMemAlloc(len*sizeof(WCHAR *)); Ulrich, you were in there last, could you have a look? Invalid write of size 4 at FileMonikerImpl_DecomposePath (filemoniker.c:1056) by FileMonikerImpl_Construct (filemoniker.c:1375) by CreateFileMoniker (filemoniker.c:1443) by FileMoniker_CreateFromDisplayName (filemoniker.c:1484) by MkParseDisplayName (moniker.c:1130) by HlinkCreateFromString (hlink_main.c:124) by test_persist (hlink.c:479) by func_hlink (hlink.c:1122) by run_test (test.h:535) by main (test.h:585) Address 0x7f04416c is 4 bytes inside a block of size 6 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:562) by FileMonikerImpl_DecomposePath (filemoniker.c:1039) by FileMonikerImpl_Construct (filemoniker.c:1375) by CreateFileMoniker (filemoniker.c:1443) by FileMoniker_CreateFromDisplayName (filemoniker.c:1484) by MkParseDisplayName (moniker.c:1130) by HlinkCreateFromString (hlink_main.c:124) by test_persist (hlink.c:479)

Nov. 19, 2009

msi regression in today's git

by Susan Cragin

Installed Dragon NaturallySpeaking using clean prefix and today's git. Instal went "without errors" but when I tried to open the program it said that the install hadn't completed correctly. Specifically, iexplore.exe was missing. I looked at the terminal output for the run but there wasn't anything interesting. Susan

Nov. 19, 2009

Re: GdiplusAbort type needs to be translated from C++ to C

by Frank Richter

On 19.11.2009 17:23, Vincent Povirk wrote: > The Windows SDK defines the following type: > > struct __declspec(novtable) GdiplusAbort > { > virtual HRESULT __stdcall Abort(void) = 0; > }; > > I don't think I can provide a proper C++ definition because the abi > depends on the compiler. Depends; with limitations this is possible. For cases like above - ie "interface" kind of structs with no members, only virtual methods and explicit calling convention specified - the resulting struct layout is the same between MSVC and g++ (at least on MinGW) and can be passed from binary code of one to another. If Linux g++ produces the same struct layout as it does on mingw it would be viable to keep the C++ version for, well, client sources written in C++. > Does this look correct? You forgot __stdcall on 'Abort' member of gpabort_vtable. -f.r.

Nov. 19, 2009

UMR in CRYPT_RemoveStringFromMultiString()

by Dan Kegel

Hi Juan, http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-crypt32_oid.txt says Invalid read of size 1 at memmove (mc_replace_strmem.c:613) by CRYPT_RemoveStringFromMultiString (oid.c:885) by CryptUnregisterDefaultOIDFunction (oid.c:1010) by test_registerDefaultOIDFunction (oid.c:437) by func_oid (oid.c:601) by run_test (test.h:535) by main (test.h:585) Address 0x7f040ed4 is 0 bytes after a block of size 44 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by CryptMemAlloc (main.c:125) by CRYPT_GetDefaultOIDDlls (oid.c:930) by CryptUnregisterDefaultOIDFunction (oid.c:1009) by test_registerDefaultOIDFunction (oid.c:437) This is near the code changed in crypt32: Don't copy past end of buffer when removing the last string in a multistring. - Dan

Nov. 19, 2009

UMR in CertIsRDNAttrsInCertificateName()

by Dan Kegel

http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-crypt32_cert.txt shows a new UMR (purify-speak for uninitialized memory read) error Conditional jump or move depends on uninitialised value(s) at strncmp (mc_replace_strmem.c:386) by find_matching_rdn_attr (cert.c:1877) by CertIsRDNAttrsInCertificateName (cert.c:1907) by testIsRDNAttrsInCertificateName (cert.c:2698) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:192) by RtlAllocateHeap (heap.c:1526) by HeapAlloc (heap.c:276) by GlobalAlloc (heap.c:369) by LocalAlloc (heap.c:969) by CRYPT_DecodeEnsureSpace (decode.c:218) by CRYPT_AsnDecodeName (decode.c:1918) by CryptDecodeObjectEx (decode.c:5909) by CertIsRDNAttrsInCertificateName (cert.c:1901) by testIsRDNAttrsInCertificateName (cert.c:2698) Juan, I think that's yours, could you have a look? - Dan

Nov. 19, 2009

GdiplusAbort type needs to be translated from C++ to C

by Vincent Povirk

The Windows SDK defines the following type: struct __declspec(novtable) GdiplusAbort { virtual HRESULT __stdcall Abort(void) = 0; }; I think that the following is a workable translation: diff --git a/include/gdiplustypes.h b/include/gdiplustypes.h index 4f97432..444123f 100644 --- a/include/gdiplustypes.h +++ b/include/gdiplustypes.h @@ -55,6 +55,18 @@ typedef BOOL (CALLBACK * ImageAbort)(VOID *); typedef ImageAbort DrawImageAbort; typedef ImageAbort GetThumbnailImageAbort; +struct GdiplusAbort; + +typedef struct gpabort_vtable +{ + HRESULT WINAPI (*Abort)(struct GdiplusAbort*); +} + +typedef struct GdiplusAbort +{ + struct gpabort_vtable *vtable_ptr; +} GdiplusAbort; + #ifdef __cplusplus } #endif I don't think I can provide a proper C++ definition because the abi depends on the compiler. Does this look correct? -- Vincent Povirk

Nov. 19, 2009

Re: Fedora users, please test mci patch about time-out/hanging machine

by Hin-Tak Leung

pulseaudio occasionally gets into a confusion by itself. I found I need to do pulseaudio --cleanup-shm from time to time. --- On Thu, 19/11/09, Joerg-Cyril.Hoehle(a)t-systems.com <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > Testhq.org results from 17th of November about winmm:mci > were striking: > All machines producing a timeout had "f11" in their name. > (Another day, some f11 machines passed the tests). > http://test.winehq.org/data/4990ca0ea342bd115a9a46047b3b2de599cb916e/index_… > > Please test whether the following patch correlates with > hanging machines. > Not checking waveoutwrite's return code for sure has the > potential to hang the > play loop, waiting for a buffer to come back that was never > sent out in case of error. > > But then, why did waveOutWrite fail? That's what I'd like > you to investigate. Why Fedora 11? > > Below patch only adds error reporting to the mciplay loop. > Feel free to add the same to the mcirecord loop. > > diff --git a/dlls/mciwave/mciwave.c > b/dlls/mciwave/mciwave.c > index cdf9146..fdb6b18 100644 > --- a/dlls/mciwave/mciwave.c > +++ b/dlls/mciwave/mciwave.c > @@ -882,6 +882,7 @@ static DWORD WAVE_mciPlay(MCIDEVICEID > wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, > > &waveHdr[whidx], waveHdr[whidx].dwBufferLength, > > waveHdr[whidx].dwBytesRecorded); > dwRet = waveOutWrite(wmw->hWave, > &waveHdr[whidx], sizeof(WAVEHDR)); > + if (dwRet) ERR("Write %d\n", dwRet); > left -= count; > wmw->dwPosition += count; > TRACE("after WODM_WRITE > dwPosition=%u\n", wmw->dwPosition); > @@ -893,7 +894,8 @@ static DWORD WAVE_mciPlay(MCIDEVICEID > wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, > WAVE_mciPlayWaitDone(wmw); /* to > balance first buffer */ > > /* just to get rid of some race > conditions between play, stop and pause */ > - waveOutReset(wmw->hWave); > + dwRet = waveOutReset(wmw->hWave); > + if (dwRet) ERR("Reset %d\n", dwRet); > > > waveOutUnprepareHeader(wmw->hWave, > &waveHdr[0], sizeof(WAVEHDR)); > > waveOutUnprepareHeader(wmw->hWave, > &waveHdr[1], sizeof(WAVEHDR)); > > A future patch will abort the loop in case of error. > However so far, when creating > situations that hung on my (non-Fedora) machine (cf. bug > #20664), the above ERR message > was never triggered. > So the cause of random mci time-out on test.winehq may as > well lay elsewhere. > > Thanks for your help, > Jörg Höhle > > >

Nov. 19, 2009

Re: Difficulties with Regression Testing

by James Mckenzie

Austin English wrote: > >On Thu, Nov 19, 2009 at 9:41 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >>>From: Austin English <austinenglish(a)gmail.com> >>>Sent: Nov 19, 2009 10:31 AM >>>To: James Mckenzie <jjmckenzie51(a)earthlink.net> >>>Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >>>Subject: Re: Difficulties with Regression Testing >>> >>>On Thu, Nov 19, 2009 at 8:51 AM, James Mckenzie >>><jjmckenzie51(a)earthlink.net> wrote: >>>> All: >>>> >>>> I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE >>>> patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the >>>> instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different >>>> problems: >>>> >>>> 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of >>>> any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes >>>> the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct >>>> wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build >>>> makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine >>>> includes are not included. >>> >>>Try doing a make clean / make distclean. >>> >> I don't think this will do anything, but I'll try it. > >Ah, Makefile.in...nm, misread that. Not sure then. > Thanks for the thought. It is absolutely strange as this just started happening. I correct the Git and it happens after a few more tries at git bisect. Maybe something did change the file between wine-1.1.10 and wine-1.1.11 that git bisect corrupts. I'll be looking at this after the long ride this weekend and over the holiday next weekend. >>>> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >>>> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >>>> the tools/subdirectory. >>> >>>IIRC, that was a file for the cryptui manager that AJ forgot to >>>include with the commit needing it. Try either putting it there >>>manually from another git branch, or using make -k. >>> >> Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. > >Put it in dlls/cryptui/, or just use make -k to ignore it. > Thank you. I'll put it there and then try the build again. James McKenzie

Nov. 19, 2009

Re: Difficulties with Regression Testing

by Austin English

On Thu, Nov 19, 2009 at 9:41 AM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: >>From: Austin English <austinenglish(a)gmail.com> >>Sent: Nov 19, 2009 10:31 AM >>To: James Mckenzie <jjmckenzie51(a)earthlink.net> >>Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >>Subject: Re: Difficulties with Regression Testing >> >>On Thu, Nov 19, 2009 at 8:51 AM, James Mckenzie >><jjmckenzie51(a)earthlink.net> wrote: >>> All: >>> >>> I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE >>> patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the >>> instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different >>> problems: >>> >>> 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of >>> any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes >>> the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct >>> wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build >>> makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine >>> includes are not included. >> >>Try doing a make clean / make distclean. >> > I don't think this will do anything, but I'll try it. Ah, Makefile.in...nm, misread that. Not sure then. >>> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >>> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >>> the tools/subdirectory. >> >>IIRC, that was a file for the cryptui manager that AJ forgot to >>include with the commit needing it. Try either putting it there >>manually from another git branch, or using make -k. >> > Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. Put it in dlls/cryptui/, or just use make -k to ignore it. -- -Austin

Nov. 19, 2009

Re: Difficulties with Regression Testing

by James Mckenzie

>From: Austin English <austinenglish(a)gmail.com> >Sent: Nov 19, 2009 10:31 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >Subject: Re: Difficulties with Regression Testing > >On Thu, Nov 19, 2009 at 8:51 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> All: >> >> I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE >> patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the >> instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different >> problems: >> >> 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of >> any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes >> the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct >> wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build >> makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine >> includes are not included. > >Try doing a make clean / make distclean. > I don't think this will do anything, but I'll try it. >> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >> the tools/subdirectory. > >IIRC, that was a file for the cryptui manager that AJ forgot to >include with the commit needing it. Try either putting it there >manually from another git branch, or using make -k. > Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. James McKenzie

Nov. 19, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Nikolay Sivov

Dan Kegel wrote: > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/ > is the first full run with the heap tail check enabled. > So you use some private patches for that, why aren't they merged? > Here are the first few new problems it found. > > Somehow, it found a bunch of invalid reads in > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_crypt.txt > all in a function called test_incorrect_api_usage(). > Offhand that seems like something to suppress. > > The invalid write I already posted about is in > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advapi32_lsa.txt > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_lsa.txt > > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advpack_files.txt > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advpack_files.txt > show an off-by-one buffer size issue (forgot to include space for nul char) > in advpack (fix should be easy, anybody can grab this): > Invalid write of size 2 > at strcpyW (unicode.h:224) > by lstrcpyW (string.c:104) > by AdvInstallFileW (files.c:283) > by AdvInstallFileA (files.c:216) > by test_AdvInstallFile (files.c:513) > Address 0x7f03d12e is 0 bytes after a block of size 30 alloc'd > at notify_alloc (heap.c:279) > by RtlAllocateHeap (heap.c:1521) > by AdvInstallFileW (files.c:282) > by AdvInstallFileA (files.c:216) > by test_AdvInstallFile (files.c:513) > > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt > show a more inscrutable error: > Invalid write of size 4 > at TAB_SetCurSel (tab.c:255) > by TAB_WindowProc (tab.c:3367) > by ??? (library.h:159) > by call_window_proc (winproc.c:469) > by WINPROC_CallProcAtoW (winproc.c:1023) > by CallWindowProcA (winproc.c:2299) > by tabSubclassProcess (tab.c:404) > by ??? (library.h:159) > by call_window_proc (winproc.c:469) > by WINPROC_call_window (winproc.c:2223) > by call_window_proc (message.c:1635) > by send_message (message.c:2482) > by SendMessageA (message.c:2627) > by test_getters_setters (tab.c:752) > by func_tab (tab.c:1174) > by run_test (test.h:535) > by main (test.h:585) > Address 0x7f044098 is not stack'd, malloc'd or (recently) free'd > > Nikolay touched that code back in March, perhaps he should have a look. > Yeah, this one is pretty obvious, I'll send a patch for tomorrow commit set. > etc. etc. Lots of triage to do. It'd be nice if somebody could > volunteer to go through these, file bugs, and assign provision blame > using 'git blame'... > - Dan >

Nov. 19, 2009

Re: shell32: deal better with spaces in ASSOCSTR_COMMAND values

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -324,7 +324,14 @@ static HRESULT ASSOC_GetExecutable(IQueryAssociationsImpl *This, > else > { > pszStart = pszCommand; > - pszEnd = strchrW(pszStart, ' '); > + for (pszEnd = pszStart; (pszEnd = strchrW(pszEnd, ' ')); pszEnd++) > + { > + WCHAR c = *pszEnd; > + *pszEnd = 0; > + if (SearchPathW(NULL, pszStart, NULL, pathlen, path, NULL)) > + break; > + *pszEnd = c; You have a redundant SearchPath call now. -- Alexandre Julliard julliard(a)winehq.org

Nov. 19, 2009

Re: winspool.drv: Acroread 9.2 relies on the buffer sizes returned by GetPrinterA and GetPrinterDriverA being large enough to hold their respective unicode versions' data.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/winspool.drv/info.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) This doesn't work here: ../../../tools/runtest -q -P wine -M winspool.drv -T ../../.. -p winspool.drv_test.exe.so info.c && touch info.ok info.c:2269: Test failed: needed 38 != filled 21 info.c:2269: Test failed: needed 414 != filled 219 info.c:2269: Test failed: needed 438 != filled 239 info.c:2269: Test failed: needed 446 != filled 245 info.c:2269: Test failed: needed 426 != filled 231 info.c:2269: Test failed: needed 482 != filled 281 make: *** [info.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

Nov. 19, 2009

Re: Difficulties with Regression Testing

by Austin English

On Thu, Nov 19, 2009 at 8:51 AM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > All: > > I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different problems: > > 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine includes are not included. Try doing a make clean / make distclean. > 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in the tools/subdirectory. IIRC, that was a file for the cryptui manager that AJ forgot to include with the commit needing it. Try either putting it there manually from another git branch, or using make -k. -- -Austin

Nov. 19, 2009

New valgrind results, this time with overrun checks and lots of new errors.

by Dan Kegel

http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/ is the first full run with the heap tail check enabled. Here are the first few new problems it found. Somehow, it found a bunch of invalid reads in http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_crypt.txt all in a function called test_incorrect_api_usage(). Offhand that seems like something to suppress. The invalid write I already posted about is in http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advapi32_lsa.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_lsa.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advpack_files.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advpack_files.txt show an off-by-one buffer size issue (forgot to include space for nul char) in advpack (fix should be easy, anybody can grab this): Invalid write of size 2 at strcpyW (unicode.h:224) by lstrcpyW (string.c:104) by AdvInstallFileW (files.c:283) by AdvInstallFileA (files.c:216) by test_AdvInstallFile (files.c:513) Address 0x7f03d12e is 0 bytes after a block of size 30 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by AdvInstallFileW (files.c:282) by AdvInstallFileA (files.c:216) by test_AdvInstallFile (files.c:513) http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt show a more inscrutable error: Invalid write of size 4 at TAB_SetCurSel (tab.c:255) by TAB_WindowProc (tab.c:3367) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_CallProcAtoW (winproc.c:1023) by CallWindowProcA (winproc.c:2299) by tabSubclassProcess (tab.c:404) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2223) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageA (message.c:2627) by test_getters_setters (tab.c:752) by func_tab (tab.c:1174) by run_test (test.h:535) by main (test.h:585) Address 0x7f044098 is not stack'd, malloc'd or (recently) free'd Nikolay touched that code back in March, perhaps he should have a look. etc. etc. Lots of triage to do. It'd be nice if somebody could volunteer to go through these, file bugs, and assign provision blame using 'git blame'... - Dan

Nov. 19, 2009

Re: Wine Icons - final round

by Reece Dunn

2009/11/18 Joel Holdsworth <joel(a)airwebreathe.org.uk>: > Hi All, > > Please let me know what you think - or if you have any comments. After > the last two rounds, I'm hoping that we should basically be at a stage > where most people are happy. Very nice! My only comment is that the monitor for mycomputer.ico in the large icon looks distorted; the borders look fuzzy as well (top left, especially the outer line, and mid right - just below the dark blue curve). - Reece

Nov. 19, 2009

Difficulties with Regression Testing

by James Mckenzie

All: I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different problems: 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine includes are not included. 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in the tools/subdirectory. Can anyone confirm/deny that they are experiencing the same problems with a git build? Thank you.

Nov. 19, 2009

Re: Problem to download git

by James Mckenzie

> >> error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack- >>7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75.pack > >Is this on a Mac, by any chance? I had similar problems using >MacPorts's git with a proxy server. I also had Linux running in a VM >on that machine, and fetching from the Linux VM always succeeded. The >odd thing is, fetching from Linux also fixed the MacPorts git fetch >for me, at least until the next day's update. > >If this isn't on a Mac, I don't know what to tell you. Mine was. I don't think Dan has a Mac though. It looks like the Git server was being a problem last night. I had to pull a full git as I thought that I had messed mine up. More on this in a separate message. James McKenzie

Nov. 19, 2009

Re: Problem to download git

by James Mckenzie

>On Wed, Nov 18, 2009 at 11:22 PM, Dan Kegel <dank(a)kegel.com> wrote: >> I'm having network errors with git tonight, too. e.g. >> >> $ git pull >> fatal: The remote end hung up unexpectedly >> >> >> > >Hangs up about half the time for me too tonight. > +1. The second pull worked. James McKenzie

Nov. 19, 2009

Re: Wine Icons - final round

by André Hentschel

Joel Holdsworth schrieb: > Please let me know what you think - or if you have any comments. After > the last two rounds, I'm hoping that we should basically be at a stage > where most people are happy. I love it! The only thing disturbing is that wineglass of notepad is on the left, where all others are on the right. Winecfg and Winetest have centered/left glasses, which is ok as they are "special cases". I think we already had that discussion, but i cant remember the end of it. -- Best Regards, André Hentschel

Nov. 19, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Paul Vriens

On 11/19/2009 01:23 PM, Austin Lund wrote: > - ok (pFileStructA->uFileDate == pFileStructW->uDate2&& > - pFileStructA->uFileTime == pFileStructW->uTime2, > - "Last write time should match last access time!\n"); > - Hi Austin, Is there no other way to get around this? I think it's a bit of a shame having tests removed for that odd system that has a FAT filesystem on a NT4+ box. -- Cheers, Paul.

Nov. 19, 2009

Re: [PATCH 4/5] comctl32/tests: Add further tests for IImageList

by Nikolay Sivov

Owen Rudge wrote: >> Owen, also please use more reasonable names for particular tests - >> dotest means nothing. > > I agree that the test names are not particularly descriptive. However, > I chose those names to indicate that the tests match the existing > DoTest functions. Perhaps both sets of functions should ideally given > more descriptive names. > Sure. Also existing DoTest could be merged to a single function maybe, so some simplification could be done here. > Cheers, > > Owen > > >

Nov. 19, 2009

Re: Test for Bug 4543: Testers needed

by Dmitry Timoshkov

"Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >>>> Why don't you use the same way of comparing EMFs as other tests do, >>>> compare_emf_bits()/dump_emf_bits()/dump_emf_records()? >>>> >>> Because I didn't look. I guess I'll rewrite the tests to use these >>> functions. >> OK, here's a version that uses the same method of comparing EMFs as the >> other tests. It passes on Wine (at least on my system). >> >> Chip >> > Sorry, that last version had some issues. Here's one that fixes them. I fail to see an improvement. -- Dmitry.

Nov. 19, 2009

Re: Fedora users, please test mci patch about time-out/hanging machine

by Michael Stefaniuc

Hello! Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Testhq.org results from 17th of November about winmm:mci were striking: > All machines producing a timeout had "f11" in their name. > (Another day, some f11 machines passed the tests). > http://test.winehq.org/data/4990ca0ea342bd115a9a46047b3b2de599cb916e/index_… > > Please test whether the following patch correlates with hanging machines. > Not checking waveoutwrite's return code for sure has the potential to hang the > play loop, waiting for a buffer to come back that was never sent out in case of error. > > But then, why did waveOutWrite fail? That's what I'd like you to investigate. Why Fedora 11? > > Below patch only adds error reporting to the mciplay loop. Feel free to add the same to the mcirecord loop. > > diff --git a/dlls/mciwave/mciwave.c b/dlls/mciwave/mciwave.c > index cdf9146..fdb6b18 100644 > --- a/dlls/mciwave/mciwave.c > +++ b/dlls/mciwave/mciwave.c > @@ -882,6 +882,7 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, > &waveHdr[whidx], waveHdr[whidx].dwBufferLength, > waveHdr[whidx].dwBytesRecorded); > dwRet = waveOutWrite(wmw->hWave, &waveHdr[whidx], sizeof(WAVEHDR)); > + if (dwRet) ERR("Write %d\n", dwRet); > left -= count; > wmw->dwPosition += count; > TRACE("after WODM_WRITE dwPosition=%u\n", wmw->dwPosition); > @@ -893,7 +894,8 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, > WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */ > > /* just to get rid of some race conditions between play, stop and pause */ > - waveOutReset(wmw->hWave); > + dwRet = waveOutReset(wmw->hWave); > + if (dwRet) ERR("Reset %d\n", dwRet); > > waveOutUnprepareHeader(wmw->hWave, &waveHdr[0], sizeof(WAVEHDR)); > waveOutUnprepareHeader(wmw->hWave, &waveHdr[1], sizeof(WAVEHDR)); > > A future patch will abort the loop in case of error. However so far, when creating > situations that hung on my (non-Fedora) machine (cf. bug #20664), the above ERR message > was never triggered. > So the cause of random mci time-out on test.winehq may as well lay elsewhere. Like in PulseAudio? That may well be. PA in F11 made sound be more broken in Wine. bye michael

Nov. 19, 2009

Fedora users, please test mci patch about time-out/hanging machine

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Testhq.org results from 17th of November about winmm:mci were striking: All machines producing a timeout had "f11" in their name. (Another day, some f11 machines passed the tests). http://test.winehq.org/data/4990ca0ea342bd115a9a46047b3b2de599cb916e/index_… Please test whether the following patch correlates with hanging machines. Not checking waveoutwrite's return code for sure has the potential to hang the play loop, waiting for a buffer to come back that was never sent out in case of error. But then, why did waveOutWrite fail? That's what I'd like you to investigate. Why Fedora 11? Below patch only adds error reporting to the mciplay loop. Feel free to add the same to the mcirecord loop. diff --git a/dlls/mciwave/mciwave.c b/dlls/mciwave/mciwave.c index cdf9146..fdb6b18 100644 --- a/dlls/mciwave/mciwave.c +++ b/dlls/mciwave/mciwave.c @@ -882,6 +882,7 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, &waveHdr[whidx], waveHdr[whidx].dwBufferLength, waveHdr[whidx].dwBytesRecorded); dwRet = waveOutWrite(wmw->hWave, &waveHdr[whidx], sizeof(WAVEHDR)); + if (dwRet) ERR("Write %d\n", dwRet); left -= count; wmw->dwPosition += count; TRACE("after WODM_WRITE dwPosition=%u\n", wmw->dwPosition); @@ -893,7 +894,8 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */ /* just to get rid of some race conditions between play, stop and pause */ - waveOutReset(wmw->hWave); + dwRet = waveOutReset(wmw->hWave); + if (dwRet) ERR("Reset %d\n", dwRet); waveOutUnprepareHeader(wmw->hWave, &waveHdr[0], sizeof(WAVEHDR)); waveOutUnprepareHeader(wmw->hWave, &waveHdr[1], sizeof(WAVEHDR)); A future patch will abort the loop in case of error. However so far, when creating situations that hung on my (non-Fedora) machine (cf. bug #20664), the above ERR message was never triggered. So the cause of random mci time-out on test.winehq may as well lay elsewhere. Thanks for your help, Jörg Höhle

Nov. 19, 2009

Re: Wineconf?

by Austin English

On Thu, Nov 19, 2009 at 1:50 AM, Tom Wickline <twickline(a)gmail.com> wrote: > > > On Thu, Nov 19, 2009 at 3:44 PM, Austin English <austinenglish(a)gmail.com> > wrote: >> >> On Thu, Nov 19, 2009 at 1:39 AM, Tom Wickline <twickline(a)gmail.com> wrote: >> > On Thu, Nov 19, 2009 at 3:21 PM, Austin English >> > <austinenglish(a)gmail.com> >> > wrote: >> >> >> >> On Wed, Nov 18, 2009 at 4:18 AM, Tom Wickline <twickline(a)gmail.com> >> >> wrote: >> >> > Scott posted about Wineconf 2009 on his blog :) >> >> > I have shamelessly reposted it to my site with a link back to his >> >> > original >> >> > post. >> >> > >> >> > A brief summary of Wineconf 2009 by Scott Ritchie : >> >> > >> >> > >> >> > >> >> > http://www.wine-reviews.net/wine-reviews/news/a-brief-summary-of-wineconf-2… >> >> >> >> Very good summary, but it was missing a bit, at least, I noticed the >> >> CxTest presentation was missing (and my impromptu talk about >> >> Appinstall). I wasn't too worried about bringing it up, but with the >> >> big push to do more gui testing, figured it should be mentioned... >> >> >> >> -- >> >> -Austin >> > >> > >> > Can you write up a summery of what you think is missing?, the CxTest >> > presentation >> > and your presentation / talk about Appinstall isn't on the wiki page as >> > well. What other presentations >> > were given? and the speaker? anyone have any PPT slides or PDF files >> > they >> > want to share? >> >> The CxTest presentation was pretty neat, with PPT slides and >> everything, whereas mine was quite impromptu...to be honest, it was >> mostly http://wiki.winehq.org/Appinstall_Testing repeated from memory. >> There was some discussion afterward about how to leverage it for >> greater regression prevention and adding more tests, but not anything >> groundbreaking. >> >> > I can edit my post and revise it with the new information, so others who >> > couldn't make it to the >> > conference can know more about what actually took place at Wineconf 2009 >> >> Would probably be better to watch those videos that were recorded for >> parts of it (or were they usable?). >> >> -- >> -Austin > > Videos would be nice, do you know how we can contact the person who recorded > them and ask them to put > them up on youtube or have a mp4 download hosted somewhere? I believe Roderick and/or Julius were in charge of that, or would at least know the right person to ask. -- -Austin

Nov. 19, 2009

Re: switching to redmine?

by Kai Blin

On Thursday 19 November 2009 06:39:27 Dan Kegel wrote: > I'm highly skeptical of these newfangled wiki+bugzilla+scm+mailinglist > thingies. It's really hard to do all those jobs well. I think that was the general consensus on this suggestion. Most developers don't seem to think the current set-up is broken enough to make this change worth all the trouble it'll cause. IIRC Scott decided to go and give it a try anyway, so at least one of us could have an informed opinion. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 19, 2009

Re: Wineconf?

by Tom Wickline

On Thu, Nov 19, 2009 at 3:44 PM, Austin English <austinenglish(a)gmail.com>wrote: > On Thu, Nov 19, 2009 at 1:39 AM, Tom Wickline <twickline(a)gmail.com> wrote: > > On Thu, Nov 19, 2009 at 3:21 PM, Austin English <austinenglish(a)gmail.com > > > > wrote: > >> > >> On Wed, Nov 18, 2009 at 4:18 AM, Tom Wickline <twickline(a)gmail.com> > wrote: > >> > Scott posted about Wineconf 2009 on his blog :) > >> > I have shamelessly reposted it to my site with a link back to his > >> > original > >> > post. > >> > > >> > A brief summary of Wineconf 2009 by Scott Ritchie : > >> > > >> > > >> > > http://www.wine-reviews.net/wine-reviews/news/a-brief-summary-of-wineconf-2… > >> > >> Very good summary, but it was missing a bit, at least, I noticed the > >> CxTest presentation was missing (and my impromptu talk about > >> Appinstall). I wasn't too worried about bringing it up, but with the > >> big push to do more gui testing, figured it should be mentioned... > >> > >> -- > >> -Austin > > > > > > Can you write up a summery of what you think is missing?, the CxTest > > presentation > > and your presentation / talk about Appinstall isn't on the wiki page as > > well. What other presentations > > were given? and the speaker? anyone have any PPT slides or PDF files they > > want to share? > > The CxTest presentation was pretty neat, with PPT slides and > everything, whereas mine was quite impromptu...to be honest, it was > mostly http://wiki.winehq.org/Appinstall_Testing repeated from memory. > There was some discussion afterward about how to leverage it for > greater regression prevention and adding more tests, but not anything > groundbreaking. > > > I can edit my post and revise it with the new information, so others who > > couldn't make it to the > > conference can know more about what actually took place at Wineconf 2009 > > Would probably be better to watch those videos that were recorded for > parts of it (or were they usable?). > > -- > -Austin > Videos would be nice, do you know how we can contact the person who recorded them and ask them to put them up on youtube or have a mp4 download hosted somewhere? -- Tom

Nov. 19, 2009

Re: switching to redmine?

by Luke Benstead

2009/11/19 Dan Kegel <dank(a)kegel.com>: > http://yokozar.org/blog/archives/171 > is a nice writeup (thanks Scott) of wineconf. > > It all sounds good except for that switching to redmine part... > The current wiki and bugzilla are working reasonably well, > doesn't seem worth the disruption to switch. > I'm highly skeptical of these newfangled wiki+bugzilla+scm+mailinglist > thingies. It's really hard to do all those jobs well. > Sourceforge was the first, and it was really rough. > Google Code is kind of ok, but it doesn't support git yet, > and its svn has performance issues (for the moment). > Launchpad is also kind of ok, and kind of supports git... > Yet Another WBSM Thingy that I've never > heard of seems unlikely to be as robust as > the above systems. > - Dan > > > You might well be pleasantly surprised. We've been using Redmine where I work for about 6-8 months and I'm really impressed with it, I'd definitely say it was better than Google Code, Trac and SF. The Redmine website is actually a Redmine tracker ( http://www.redmine.org/projects/redmine ) so you can get a fair idea how it works. I don't think it's set in stone that we're switching to Redmine, I think Scott's just setting it up as an experiment to get feedback. Luke.

Nov. 19, 2009

Re: Wineconf?

by Austin English

On Thu, Nov 19, 2009 at 1:39 AM, Tom Wickline <twickline(a)gmail.com> wrote: > On Thu, Nov 19, 2009 at 3:21 PM, Austin English <austinenglish(a)gmail.com> > wrote: >> >> On Wed, Nov 18, 2009 at 4:18 AM, Tom Wickline <twickline(a)gmail.com> wrote: >> > Scott posted about Wineconf 2009 on his blog :) >> > I have shamelessly reposted it to my site with a link back to his >> > original >> > post. >> > >> > A brief summary of Wineconf 2009 by Scott Ritchie : >> > >> > >> > http://www.wine-reviews.net/wine-reviews/news/a-brief-summary-of-wineconf-2… >> >> Very good summary, but it was missing a bit, at least, I noticed the >> CxTest presentation was missing (and my impromptu talk about >> Appinstall). I wasn't too worried about bringing it up, but with the >> big push to do more gui testing, figured it should be mentioned... >> >> -- >> -Austin > > > Can you write up a summery of what you think is missing?, the CxTest > presentation > and your presentation / talk about Appinstall isn't on the wiki page as > well. What other presentations > were given? and the speaker? anyone have any PPT slides or PDF files they > want to share? The CxTest presentation was pretty neat, with PPT slides and everything, whereas mine was quite impromptu...to be honest, it was mostly http://wiki.winehq.org/Appinstall_Testing repeated from memory. There was some discussion afterward about how to leverage it for greater regression prevention and adding more tests, but not anything groundbreaking. > I can edit my post and revise it with the new information, so others who > couldn't make it to the > conference can know more about what actually took place at Wineconf 2009 Would probably be better to watch those videos that were recorded for parts of it (or were they usable?). -- -Austin

Nov. 19, 2009

Re: Wineconf?

by Tom Wickline

On Thu, Nov 19, 2009 at 3:21 PM, Austin English <austinenglish(a)gmail.com>wrote: > On Wed, Nov 18, 2009 at 4:18 AM, Tom Wickline <twickline(a)gmail.com> wrote: > > Scott posted about Wineconf 2009 on his blog :) > > I have shamelessly reposted it to my site with a link back to his > original > > post. > > > > A brief summary of Wineconf 2009 by Scott Ritchie : > > > > > http://www.wine-reviews.net/wine-reviews/news/a-brief-summary-of-wineconf-2… > > Very good summary, but it was missing a bit, at least, I noticed the > CxTest presentation was missing (and my impromptu talk about > Appinstall). I wasn't too worried about bringing it up, but with the > big push to do more gui testing, figured it should be mentioned... > > -- > -Austin > Can you write up a summery of what you think is missing?, the CxTest presentation and your presentation / talk about Appinstall isn't on the wiki page as well. What other presentations were given? and the speaker? anyone have any PPT slides or PDF files they want to share? I can edit my post and revise it with the new information, so others who couldn't make it to the conference can know more about what actually took place at Wineconf 2009 Thanks! Tom

Nov. 19, 2009

Re: Wineconf?

by Austin English

On Wed, Nov 18, 2009 at 4:18 AM, Tom Wickline <twickline(a)gmail.com> wrote: > Scott posted about Wineconf 2009 on his blog :) > I have shamelessly reposted it to my site with a link back to his original > post. > > A brief summary of Wineconf 2009 by Scott Ritchie : > > http://www.wine-reviews.net/wine-reviews/news/a-brief-summary-of-wineconf-2… Very good summary, but it was missing a bit, at least, I noticed the CxTest presentation was missing (and my impromptu talk about Appinstall). I wasn't too worried about bringing it up, but with the big push to do more gui testing, figured it should be mentioned... -- -Austin

Nov. 19, 2009

Buffer overrun in LsaLookupNames2() found with valgrind+wine+new heap patch

by Dan Kegel

Here's the first error it helped Valgrind find in tonight's automated run: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so lsa.c && touch lsa.ok ... Invalid write of size 1 at memmove (mc_replace_strmem.c:613) by RtlCopySid (sec.c:376) by CopySid (security.c:905) by lookup_local_wellknown_name (security.c:2800) by lookup_name (lsa.c:308) by LsaLookupNames2 (lsa.c:411) by test_LsaLookupNames2 (lsa.c:336) by func_lsa (lsa.c:362) Address 0x7f03c550 is 6 bytes after a block of size 26 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by LsaLookupNames2 (lsa.c:402) by test_LsaLookupNames2 (lsa.c:336) by func_lsa (lsa.c:362) Offhand that looks like a real problem. Aric, you may have touched that code last, could you have a look? Oh, and here's a bit that was missing from the patch. - Dan

Nov. 19, 2009

switching to redmine?

by Dan Kegel

http://yokozar.org/blog/archives/171 is a nice writeup (thanks Scott) of wineconf. It all sounds good except for that switching to redmine part... The current wiki and bugzilla are working reasonably well, doesn't seem worth the disruption to switch. I'm highly skeptical of these newfangled wiki+bugzilla+scm+mailinglist thingies. It's really hard to do all those jobs well. Sourceforge was the first, and it was really rough. Google Code is kind of ok, but it doesn't support git yet, and its svn has performance issues (for the moment). Launchpad is also kind of ok, and kind of supports git... Yet Another WBSM Thingy that I've never heard of seems unlikely to be as robust as the above systems. - Dan

Nov. 18, 2009

Re: Problem to download git

by John Klehm

On Wed, Nov 18, 2009 at 11:22 PM, Dan Kegel <dank(a)kegel.com> wrote: > I'm having network errors with git tonight, too. e.g. > > $ git pull > fatal: The remote end hung up unexpectedly > > > Hangs up about half the time for me too tonight.

Nov. 18, 2009

re: Problem to download git

by Dan Kegel

I'm having network errors with git tonight, too. e.g. $ git pull fatal: The remote end hung up unexpectedly

Nov. 18, 2009

Re: Problem to download git

by Juan Lang

> error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack-7c2ab792c6e1c8f603b… Is this on a Mac, by any chance? I had similar problems using MacPorts's git with a proxy server. I also had Linux running in a VM on that machine, and fetching from the Linux VM always succeeded. The odd thing is, fetching from Linux also fixed the MacPorts git fetch for me, at least until the next day's update. If this isn't on a Mac, I don't know what to tell you. --Juan

Nov. 18, 2009

Re: ntdll: implement FLG_HEAP_ENABLE_TAIL_CHECK

by Dan Kegel

OK, here's something that seems to mostly work, and even gives reasonable valgrind errors. To use it, apply the patch and then do export WINE_HEAP_REDZONE=16 or so. (Bigger values catch more problems but add more overhead.) Only eleven tests generate warnings with that set: runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so lsa.c invalid arena 0x14c520, buffer 0x14c528, corrupt at 0x14c548 (byte 32 of 26) runtest -q -P wine -M advpack.dll -T ../../.. -p advpack_test.exe.so files.c invalid arena 0x14d108, buffer 0x14d110, corrupt at 0x14d12e (byte 30 of 30) invalid arena 0x14d140, buffer 0x14d148, corrupt at 0x14d166 (byte 30 of 30) runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so path.c invalid arena 0x14bb40, buffer 0x14bb48, corrupt at 0x14bb48 (byte 0 of 0) runtest -q -P wine -M hlink.dll -T ../../.. -p hlink_test.exe.so hlink.c invalid arena 0x154158, buffer 0x154160, corrupt at 0x154166 (byte 6 of 6) runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so format_msg.c invalid arena 0x14c128, buffer 0x14c130, corrupt at 0x14c132 (byte 2 of 2) invalid arena 0x14c148, buffer 0x14c150, corrupt at 0x14c152 (byte 2 of 2) invalid arena 0x14c168, buffer 0x14c170, corrupt at 0x14c172 (byte 2 of 2) invalid arena 0x14c188, buffer 0x14c190, corrupt at 0x14c192 (byte 2 of 2) runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c invalid arena 0x164c20, buffer 0x164c28, corrupt at 0x164c2d (byte 5 of 5) runtest -q -P wine -M netapi32.dll -T ../../.. -p netapi32_test.exe.so access.c invalid arena 0x110b60, buffer 0x110b68, corrupt at 0x110bea (byte 130 of 130) runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so moniker.c invalid arena 0x14fdf8, buffer 0x14fe00, corrupt at 0x14fe00 (byte 0 of 0) ... invalid arena 0x155ce8, buffer 0x155cf0, corrupt at 0x155cf0 (byte 0 of 0) runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so usrmarshal.c invalid arena 0x14fbc0, buffer 0x14fbc8, corrupt at 0x14fbee (byte 38 of 38) runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c invalid arena 0x1568f0, buffer 0x1568f8, corrupt at 0x1568fe (byte 6 of 6) runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so usrmarshal.c invalid arena 0x14ebb8, buffer 0x14ebc0, corrupt at 0x14ebc0 (byte 0 of 0) and at least some of those seem to be real errors. To get more details, run under valgrind; it will show you the stack of where the bad write occurred. I'll try to provide logs tomorrow. There are still some rough edges, but it might be useful already. It also adds a missing valgrind annotation in mark_free_block() that's only needed in the WINEDEBUG=+heap case, works around a small valgrind quirk that confuses wine's environment setup, and fixes a whitespace mistake... - Dan

Nov. 18, 2009

Problem to download git

by paulo lesgaz

Hello, when I try to download git, I have the following error. Is it for me only, or does it occur for anyone? I tried to download it several times. I obtain always the same error. dadam(a)analyst:~$ export http_proxy=”http://proxy.upf.pf:8080″ dadam(a)analyst:~$ git clone http://source.winehq.org/git/wine.git ~/wine Initialized empty Git repository in /home/dadam/wine/.git/ Getting alternates list for http://source.winehq.org/git/wine.git Getting pack list for http://source.winehq.org/git/wine.git Getting index for pack 0ece042377e5e1fe77ac71b065cf360c0244774e Getting index for pack 72c84da3f0d9b4fd0dad04f1ce7244dadce37a43 Getting index for pack 6c18f6d3a2d8e85a33e7981ead83b64e4c36bc8c Getting index for pack 7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75 Getting pack 7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75 which contains 7f5b24ed9186d457acd7803a97d4171f332c5fb2 error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack-7c2ab792c6e1c8f603b… transfer closed with 1152650 bytes remaining to read error: Unable to find 7f5b24ed9186d457acd7803a97d4171f332c5fb2 under http://source.winehq.org/git/wine.git Cannot obtain needed object 7f5b24ed9186d457acd7803a97d4171f332c5fb2 fatal: Fetch failed. D. Adam

Nov. 18, 2009

Re: Resetting screen resolution on crash

by Henri Verbeet

2009/11/18 Erich Hoover <ehoover(a)mines.edu>: > I was reading the brief summary on WineConf > (http://yokozar.org/blog/archives/171) and saw an interesting item: >> >> We need some help from Freedesktop.org for solving bug 10841. Essentially >> we need a standard way of saying “hey reset the resolution when I’m done, >> even if I crash.” I was “volunteered” for the task of approaching the >> respective projects. > > > I believe this is a case that we can detect on our own, attached is a small > standalone example of using fork() in such a way that you could reset the > screen resolution even if an application crashed. > That's not what the bug is about. The bug is about the case where you have a fullscreen application in a different resolution from the desktop, and you switch to a different (non-fullscreen) application. In that case the display resolution should be reset to the desktop resolution again. At least part of that involves properly handling the CDS_FULLSCREEN flag to ChangeDisplayMode().

Nov. 18, 2009

Re: ntdll: implement FLG_HEAP_ENABLE_TAIL_CHECK

by Dan Kegel

On Wed, Nov 18, 2009 at 2:28 PM, Dan Kegel <dank(a)kegel.com> wrote: > Here's a second try, this time only for large arenas, but > with valgrind integration working. (It also has a workaround for > a strange valgrind problem that leaves an empty variable in > the environment that confuses wine.) Found buglets already, so don't bother doing detailed review...

Nov. 18, 2009

Re: ntdll: implement FLG_HEAP_ENABLE_TAIL_CHECK

by Dan Kegel

On Wed, Nov 18, 2009 at 12:47 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > interesting stuff > however, you don't handle correctly HeapReAlloc(..., ZERO_MEMORY,...) calls > when the already allocated block grows in place Thanks for catching that. I decided to start over and push the tail fill down into the heap routines rather than try to put it in a wrapper; the extra abstraction wasn't helping. Here's a second try, this time only for large arenas, but with valgrind integration working. (It also has a workaround for a strange valgrind problem that leaves an empty variable in the environment that confuses wine.) This time around, the only test that fails with WINE_GLOBAL_FLAG=0x10 is comctl32/dpa.c, and I could well imagine that might have a real problem lurking. Now to tackle the small arena case... - Dan

Nov. 18, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

Charles Davis wrote: > Charles Davis wrote: >> Dmitry Timoshkov wrote: >>> "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >>> >>>> I've attached the patch so you can build a gdi32_test.exe that contains >>>> my tests. >>> Why don't you use the same way of comparing EMFs as other tests do, >>> compare_emf_bits()/dump_emf_bits()/dump_emf_records()? >>> >> Because I didn't look. I guess I'll rewrite the tests to use these >> functions. > OK, here's a version that uses the same method of comparing EMFs as the > other tests. It passes on Wine (at least on my system). > > Chip > Sorry, that last version had some issues. Here's one that fixes them. Chip >From a2607301f33c42265f441b84dfc8f99467201ff9 Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 169 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 169 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..02e5e9b 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -1382,6 +1382,174 @@ static int compare_emf_bits(const HENHMETAFILE mf, const unsigned char *bits, return 0; } +/*********************************************************************** + * DIB_GetDIBWidthBytes + * + * Return the width of a DIB bitmap in bytes. DIB bitmap data is 32-bit aligned. + * Shamelessly borrowed from dlls/gdi32/dib.c. + */ +static int DIB_GetDIBWidthBytes( int width, int depth ) +{ + int words; + + switch(depth) + { + case 1: words = (width + 31) / 32; break; + case 4: words = (width + 7) / 8; break; + case 8: words = (width + 3) / 4; break; + case 15: + case 16: words = (width + 1) / 2; break; + case 24: words = (width * 3 + 3)/4; break; + + default: + /* fall through */ + case 32: + words = width; + } + return 4 * words; +} + +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + (*pi)++; + if(*pi > 2) return 1; + if(*pi == 1) /* First BitBlt */ + { + EMRBITBLT *first_bb; + DWORD size, bits_size, bmi_size; + DWORD nBPP; + BITMAP bm; + HBITMAP hbm = GetCurrentObject(hdc, OBJ_BITMAP); + BITMAPINFOHEADER *bmi; + + GetObjectW(hbm, sizeof(bm), &bm); + nBPP = bm.bmPlanes * bm.bmBitsPixel; + if(nBPP > 8) nBPP = 24; /* FIXME */ + + bits_size = DIB_GetDIBWidthBytes(bm.bmWidth, nBPP) * bm.bmHeight; + bmi_size = sizeof(BITMAPINFOHEADER) + + (nBPP <= 8 ? 1 << nBPP : 0) * sizeof(RGBQUAD); + size = sizeof(EMRBITBLT) + bits_size + bmi_size; + first_bb = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); + if(!first_bb) + { + skip("Not enough memory for EMF record\n"); + return 1; + } + + first_bb->emr.iType = EMR_BITBLT; + first_bb->emr.nSize = size; + first_bb->rclBounds.right = GetSystemMetrics(SM_CXSCREEN)-1; + first_bb->rclBounds.bottom = GetSystemMetrics(SM_CYSCREEN)-1; + first_bb->cxDest = GetSystemMetrics(SM_CXSCREEN); + first_bb->cyDest = GetSystemMetrics(SM_CYSCREEN); + first_bb->dwRop = SRCCOPY; + first_bb->xformSrc.eM11 = 1.0; + first_bb->xformSrc.eM12 = 0.0; + first_bb->xformSrc.eM21 = 0.0; + first_bb->xformSrc.eM22 = 1.0; + first_bb->xformSrc.eDx = 0.0; + first_bb->xformSrc.eDy = 0.0; + first_bb->crBkColorSrc = GetBkColor(hdc); + first_bb->iUsageSrc = DIB_RGB_COLORS; + first_bb->offBmiSrc = sizeof(EMRBITBLT); + first_bb->cbBmiSrc = bmi_size; + first_bb->offBitsSrc = sizeof(EMRBITBLT) + bmi_size; + first_bb->cbBitsSrc = bits_size; + + bmi = (BITMAPINFOHEADER *)((BYTE *)first_bb + first_bb->offBmiSrc); + bmi->biSize = sizeof(BITMAPINFOHEADER); + bmi->biWidth = bm.bmWidth; + bmi->biHeight = bm.bmHeight; + bmi->biPlanes = bm.bmPlanes; + bmi->biBitCount = nBPP; + bmi->biCompression = BI_RGB; + bmi->biSizeImage = bits_size; + bmi->biYPelsPerMeter = MulDiv(GetDeviceCaps(hdc, LOGPIXELSX), 3937, 100); + bmi->biXPelsPerMeter = MulDiv(GetDeviceCaps(hdc, LOGPIXELSY), 3937, 100); + bmi->biClrUsed = nBPP <= 8 ? 1 << nBPP : 0; + bmi->biClrImportant = 0; + + GetDIBits(hdc, hbm, 0, (UINT)bmi->biHeight, + (BYTE *)first_bb + first_bb->offBitsSrc, + (BITMAPINFO *)bmi, DIB_RGB_COLORS); + + match_emf_record((ENHMETARECORD *)first_bb, emfr, "emr_BitBlt_first", FALSE); + } + else if(0) + { + EMRBITBLT second_bb = + { + {EMR_BITBLT, sizeof(EMRBITBLT)}, + {0, 0, 0, 0}, + 0, 0, + 0, 0, + WHITENESS, + 0, 0, + {1.0, 0.0, 0.0, 1.0, 0.0, 0.0}, + 0, + 0, + 0, 0, 0, 0 + }; + + second_bb.rclBounds.right = GetSystemMetrics(SM_CXSCREEN)-1; + second_bb.rclBounds.bottom = GetSystemMetrics(SM_CYSCREEN)-1; + second_bb.cxDest = GetSystemMetrics(SM_CXSCREEN); + second_bb.cyDest = GetSystemMetrics(SM_CYSCREEN); + match_emf_record((ENHMETARECORD *)&second_bb, emfr, "emr_BitBlt_second", FALSE); + } + return 1; +} + +/* tests blitting to an EMF */ +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; + BOOL ret; + UINT i; + RECT rc; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + i = 0; + SetRect(&rc, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + EnumEnhMetaFile(hdcBitmap, hMetafile, test_BitBlt_record, &i, &rc); + if(0) + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); +} + /* Test a blank metafile. May be used as a template for new tests. */ static void test_mf_Blank(void) @@ -2628,6 +2796,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

Nov. 18, 2009

Resetting screen resolution on crash

by Erich Hoover

I was reading the brief summary on WineConf ( http://yokozar.org/blog/archives/171) and saw an interesting item: > We need some help from Freedesktop.org for solving bug 10841. Essentially > we need a standard way of saying “hey reset the resolution when I’m done, > even if I crash.” I was “volunteered” for the task of approaching the > respective projects. I believe this is a case that we can detect on our own, attached is a small standalone example of using fork() in such a way that you could reset the screen resolution even if an application crashed. Erich Hoover ehoover(a)mines.edu

Nov. 18, 2009

Wine Icons - final round

by Joel Holdsworth

Hi All, I wanted to fill you in on the progress on the Tango icon set. You can see it here: http://www.airwebreathe.org.uk/wine-icon/ Please let me know what you think - or if you have any comments. After the last two rounds, I'm hoping that we should basically be at a stage where most people are happy. The main change since last time is that I've replaced the user32 icons with icons that are similar to the Windows 7/Vista standard - but Tango compliant. I was unable to clarify the license for the icon I was using for the ramdisk icon, so I redrew one of my own - a DIMM, which in the end is more suitable than the SOIC chip we had before. The other major change is that I've decided to hold off on cryptui.dll. I'm not happy with the artwork yet, and cryptui.dll needs to be modified so that it uses HICONs rather the HBITMAPs, which don't cope with different colour depths well. When everyone is happy, I really need to freeze the icons from further modifications, because I need to begin the laborious process of making 8 and 4-bit versions. If anyone would like to help with this I'd be happy to have some helpers. But for now let me know if you have any thoughts. Best Regards Joel Holdsworth

Nov. 18, 2009

Re: ntdll: implement FLG_HEAP_ENABLE_TAIL_CHECK

by Eric Pouech

Dan Kegel a écrit : > (Without a change like this, Valgrind can't properly > detect buffer overruns, but even without Valgrind, > this change will improve Wine's ability to detect > buffer overruns.) > > With this change, users can enable buffer overrun > detection in Wine by setting WINE_GLOBAL_FLAGS=0x10. > This is like the overrun detection in Windows enabled by > setting NtGlobalFlags to 0x10, but checks 16 bytes > rather than 8, and works for large allocations, > not just small ones. > > With this enabled, a remarkable number of tests break. > > I'm posting this to wine-devel for review while I > add valgrind annotations (which should make > it easier to tell whether the errors it detects are real or spurious) > and fix the spurious breakages. > > Note that this change is a no-op under normal circumstances; > without setting WINE_GLOBAL_FLAGS, you shouldn't > see any breakage. > > ------------------------------------------------------------------------ > > Hi Dan interesting stuff however, you don't handle correctly HeapReAlloc(..., ZERO_MEMORY,...) calls when the already allocated block grows in place => you get a block like OGN (O = old block, G=guard for old block, N=new block extension) what's zeroed out is N, whereas you should "repaint" GN into ZG (zero of size(N), Guard) which may also explain lots of errors when running the tool A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Nov. 18, 2009

Re: [PATCH 4/5] comctl32/tests: Add further tests for IImageList

by Owen Rudge

> Owen, also please use more reasonable names for particular tests - > dotest means nothing. I agree that the test names are not particularly descriptive. However, I chose those names to indicate that the tests match the existing DoTest functions. Perhaps both sets of functions should ideally given more descriptive names. Cheers, Owen

Nov. 18, 2009

Re: [PATCH 6/6] msxml3: Implemented xmlnode_get_nodeTypedValue date related data types handling

by Paul Vriens

On 11/18/2009 12:51 AM, Piotr Caban wrote: > --- > dlls/msxml3/node.c | 67 ++++++++++++++++++++++++++++++++++++++++ > dlls/msxml3/tests/domdoc.c | 72 > ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 139 insertions(+), 0 deletions(-) > > Hi Piotr, These new tests introduce failures on XP and W2K3: http://test.winehq.org/data/tests/msxml3:domdoc.html (These two are the only platforms in as of this writing). Could you have a look? -- Cheers, Paul.

Nov. 18, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

Charles Davis wrote: > Dmitry Timoshkov wrote: >> "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >> >>> I've attached the patch so you can build a gdi32_test.exe that contains >>> my tests. >> Why don't you use the same way of comparing EMFs as other tests do, >> compare_emf_bits()/dump_emf_bits()/dump_emf_records()? >> > Because I didn't look. I guess I'll rewrite the tests to use these > functions. OK, here's a version that uses the same method of comparing EMFs as the other tests. It passes on Wine (at least on my system). Chip >From d1f2029efc5ab0a335c6b95002de4ee5e394bcf5 Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 167 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 167 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..de8cd41 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -1382,6 +1382,172 @@ static int compare_emf_bits(const HENHMETAFILE mf, const unsigned char *bits, return 0; } +/*********************************************************************** + * DIB_GetDIBWidthBytes + * + * Return the width of a DIB bitmap in bytes. DIB bitmap data is 32-bit aligned. + * Shamelessly borrowed from dlls/gdi32/dib.c. + */ +int DIB_GetDIBWidthBytes( int width, int depth ) +{ + int words; + + switch(depth) + { + case 1: words = (width + 31) / 32; break; + case 4: words = (width + 7) / 8; break; + case 8: words = (width + 3) / 4; break; + case 15: + case 16: words = (width + 1) / 2; break; + case 24: words = (width * 3 + 3)/4; break; + + default: + /* fall through */ + case 32: + words = width; + } + return 4 * words; +} + +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + (*pi)++; + if(*pi > 2) return 1; + if(*pi == 1) /* First BitBlt */ + { + EMRBITBLT *first_bb; + DWORD size, bits_size, bmi_size; + DWORD nBPP; + BITMAP bm; + HBITMAP hbm = GetCurrentObject(hdc, OBJ_BITMAP); + BITMAPINFOHEADER *bmi; + + GetObjectW(hbm, sizeof(bm), &bm); + nBPP = bm.bmPlanes * bm.bmBitsPixel; + + bits_size = DIB_GetDIBWidthBytes(bm.bmWidth, nBPP) * bm.bmHeight; + bmi_size = sizeof(BITMAPINFOHEADER) + + (nBPP <= 8 ? 1 << nBPP : 0) * sizeof(RGBQUAD); + trace("bits_size = %d, bmi_size = %d\n", bits_size, bmi_size); + size = sizeof(EMRBITBLT) + bits_size + bmi_size; + first_bb = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size); + if(!first_bb) + { + skip("Not enough memory for EMF record\n"); + return 1; + } + + first_bb->emr.iType = EMR_BITBLT; + first_bb->emr.nSize = size; + first_bb->rclBounds.right = GetSystemMetrics(SM_CXSCREEN); + first_bb->rclBounds.bottom = GetSystemMetrics(SM_CYSCREEN); + first_bb->cxDest = GetSystemMetrics(SM_CXSCREEN); + first_bb->cyDest = GetSystemMetrics(SM_CYSCREEN); + first_bb->dwRop = SRCCOPY; + first_bb->xformSrc.eM11 = 1.0; + first_bb->xformSrc.eM12 = 0.0; + first_bb->xformSrc.eM21 = 0.0; + first_bb->xformSrc.eM22 = 1.0; + first_bb->xformSrc.eDx = 0.0; + first_bb->xformSrc.eDy = 0.0; + first_bb->crBkColorSrc = GetBkColor(hdc); + first_bb->iUsageSrc = DIB_RGB_COLORS; + first_bb->offBmiSrc = sizeof(EMRBITBLT); + first_bb->cbBmiSrc = bmi_size; + first_bb->offBitsSrc = sizeof(EMRBITBLT) + bmi_size; + first_bb->cbBitsSrc = bits_size; + + bmi = (BITMAPINFOHEADER *)((BYTE *)first_bb + first_bb->offBmiSrc); + bmi->biSize = sizeof(BITMAPINFOHEADER); + bmi->biWidth = bm.bmWidth; + bmi->biHeight = bm.bmHeight; + bmi->biPlanes = bm.bmPlanes; + bmi->biBitCount = nBPP; + bmi->biCompression = BI_RGB; + bmi->biSizeImage = bits_size; + bmi->biYPelsPerMeter = MulDiv(GetDeviceCaps(hdc, LOGPIXELSX), 3937, 100); + bmi->biXPelsPerMeter = MulDiv(GetDeviceCaps(hdc, LOGPIXELSY), 3937, 100); + bmi->biClrUsed = nBPP <= 8 ? 1 << nBPP : 0; + bmi->biClrImportant = 0; + + GetDIBits(hdc, hbm, 0, (UINT)bmi->biHeight, + (BYTE *)first_bb + first_bb->offBitsSrc, + (BITMAPINFO *)bmi, DIB_RGB_COLORS); + + match_emf_record(emfr, (ENHMETARECORD *)first_bb, "emr_BitBlt_first", FALSE); + } + else if(0) + { + EMRBITBLT second_bb = + { + {EMR_BITBLT, sizeof(EMRBITBLT)}, + {0, 0, 0, 0}, + 0, 0, + 0, 0, + WHITENESS, + 0, 0, + {1.0, 0.0, 0.0, 1.0, 0.0, 0.0}, + 0, + 0, + 0, 0, 0, 0 + }; + + second_bb.rclBounds.right = GetSystemMetrics(SM_CXSCREEN); + second_bb.rclBounds.bottom = GetSystemMetrics(SM_CYSCREEN); + second_bb.cxDest = GetSystemMetrics(SM_CXSCREEN); + second_bb.cyDest = GetSystemMetrics(SM_CYSCREEN); + match_emf_record(emfr, (ENHMETARECORD *)&second_bb, "emr_BitBlt_second", FALSE); + } + return 1; +} + +/* tests blitting to an EMF */ +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + i = 0; + EnumEnhMetaFile(hdcBitmap, hMetafile, test_BitBlt_record, &i, NULL); + if(0) + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); +} + /* Test a blank metafile. May be used as a template for new tests. */ static void test_mf_Blank(void) @@ -2628,6 +2794,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

Nov. 18, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

Dmitry Timoshkov wrote: > "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > >> I've attached the patch so you can build a gdi32_test.exe that contains >> my tests. > > Why don't you use the same way of comparing EMFs as other tests do, > compare_emf_bits()/dump_emf_bits()/dump_emf_records()? > Because I didn't look. I guess I'll rewrite the tests to use these functions. Chip

Nov. 18, 2009

Re: ole32: Add a test for freeing the parent of an open stream.

by Alexandre Julliard

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > From 1d583fc07db661bd0f0d0d00ea82c6208c3b744f Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Tue, 17 Nov 2009 11:20:34 -0600 > Subject: [PATCH 4/7] ole32: Add a test for freeing the parent of an open stream. It doesn't work here: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so storage32.c && touch storage32.ok wine: Unhandled page fault on read access to 0x454556d6 at address 0x687dc2dd (thread 0045), starting debugger... Unhandled exception: page fault on read access to 0x454556d6 in 32-bit code (0x687dc2dd). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:687dc2dd ESP:0032f980 EBP:0032f9b8 EFLAGS:00010216( R- -- I -A-P- ) EAX:45455246 EBX:688587e4 ECX:00110058 EDX:00000100 ESI:45455246 EDI:00000011 Stack dump: 0x0032f980: 00000000 00000100 00000000 00000080 0x0032f990: 0032f9dc 0032f9b0 0032f9b8 7bc45af1 0x0032f9a0: 00000040 00040000 00141c80 7bc346cf 0x0032f9b0: 00141c58 688587e4 0032fa68 687dc339 0x0032f9c0: 45455246 00000002 0032f9dc 00000000 0x0032f9d0: 00000000 0032f9dc 00000000 00000000 Backtrace: =>0 0x687dc2dd StorageImpl_ReadRawDirEntry+0x3d(This=0x45455246, index=256, buffer="") [/home/julliard/wine/wine/dlls/ole32/storage32.c:3002] in ole32 (0x0032f9b8) 1 0x687dc339 StorageImpl_ReadDirEntry+0x39(This=0x45455246, index=2, buffer=0x32fa98) [/home/julliard/wine/wine/dlls/ole32/storage32.c:3127] in ole32 (0x0032fa68) 2 0x687d8268 StgStreamImpl_SetSize+0x98(iface=<register ESI not in topmost frame>, libNewSize=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/stg_stream.c:614] in ole32 (0x0032fb28) 3 0x687d86ee StgStreamImpl_Write+0x1ce(iface=0x141cd8, pv=0x6867cadc, cb=17, pcbWritten=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/stg_stream.c:420] in ole32 (0x0032fb78) 4 0x68662ea2 test_parent_free+0x222() [/home/julliard/wine/wine/dlls/ole32/tests/storage32.c:1322] in ole32_test (0x0032fbc8) 5 0x6866deea func_storage32+0x14ca() [/home/julliard/wine/wine/dlls/ole32/tests/storage32.c:2470] in ole32_test (0x0032fd98) 6 0x68671b40 run_test+0x130(name="storage32.c") [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:537] in ole32_test (0x0032fdd8) 7 0x68671d2e main+0x11e(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:586] in ole32_test (0x0032fe88) 8 0x686727b4 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ole32_test (0x0032feb8) 9 0x7b8768a5 start_process+0x55(peb=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1025] in kernel32 (0x0032fee8) 10 0x7bc6de64 call_thread_func+0xc() in ntdll (0x0032fef8) 11 0x7bc6e080 call_thread_entry_point+0x70(entry=0x7b876850, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2342] in ntdll (0x0032ffc8) 12 0x7bc4b20a in ntdll (+0x3b20a) (0x0032ffe8) 13 0x68027e4d wine_call_on_stack+0x1d() in libwine.so.1 (0x00000000) 0x687dc2dd StorageImpl_ReadRawDirEntry+0x3d [/home/julliard/wine/wine/dlls/ole32/storage32.c:3002] in ole32: movl 0x490(%eax),%eax 3002 hr = BlockChainStream_ReadAt( -- Alexandre Julliard julliard(a)winehq.org

Nov. 18, 2009

Re: To error out or to skip tests?

by Joerg-Cyril.Hoehle＠t-systems.com

Ge, >After a bit of mucking around I got sound to work on the Linux host where >those VMware Server VMs run, and enabled sound in the VMs where possible. That's great. I've not yet written the patch that'll silence machines without sound as I'm still thinking about how I'll implement "coherence tests", i.e. - a machine with no sound at all should skip everything without error; - yet a machine that passes play test #1 must also pass play test #2, i.e. the straight forward if (err==MCI_XY/*no sound*/) skip("no sound here, skipping\n"); is not acceptable. I'll do something more like ok(err==xyz && err==previous_similar_result,"..."); But it'll come... Regards, Jörg Höhle.

Nov. 18, 2009

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)

by Alexandre Julliard

Austin Lund <austin.lund(a)gmail.com> writes: > 2009/11/18 Alexandre Julliard <julliard(a)winehq.org>: >> >> Testing file system flags is not a good idea, that won't work on >> Wine. It's better to test the results of the actual call. >> > > The reason this test fails for me is because I have a FAT32 volume and > there is no ACL info stored, so the tests: > > ok(dacl != NULL, "GetSecurityInfo\n"); > ok(IsValidAcl(dacl), "GetSecurityInfo\n"); > > clearly will fail. Unless there is another way to find out if the ACL > information is persistent, then the only option left is to remove > these tests otherwise they will always fail when running on a FAT32 > drive. That doesn't mean you have to remove it all, just don't treat the case of dacl being NULL as an error. -- Alexandre Julliard julliard(a)winehq.org

Nov. 18, 2009

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)

by Austin Lund

2009/11/18 Alexandre Julliard <julliard(a)winehq.org>: > > Testing file system flags is not a good idea, that won't work on > Wine. It's better to test the results of the actual call. > The reason this test fails for me is because I have a FAT32 volume and there is no ACL info stored, so the tests: ok(dacl != NULL, "GetSecurityInfo\n"); ok(IsValidAcl(dacl), "GetSecurityInfo\n"); clearly will fail. Unless there is another way to find out if the ACL information is persistent, then the only option left is to remove these tests otherwise they will always fail when running on a FAT32 drive.

Nov. 18, 2009

Re: Wineconf?

by Tom Wickline

Scott posted about Wineconf 2009 on his blog :) I have shamelessly reposted it to my site with a link back to his original post. A brief summary of Wineconf 2009 by Scott Ritchie : http://www.wine-reviews.net/wine-reviews/news/a-brief-summary-of-wineconf-2… Tom On Wed, Nov 11, 2009 at 10:18 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > > Hello! > > Damjan Jovanovic wrote: > > Can someone please write a bit about Wineconf 2009, for those of us > > that didn't go? > > > > Also is there videos/presentations to see? > I have added mine to the bottom of http://wiki.winehq.org/WineConf2009 > > bye > michael > > -- http://www.wine-reviews.net/

Nov. 18, 2009

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)

by Alexandre Julliard

Austin Lund <austin.lund(a)gmail.com> writes: > @@ -3143,6 +3146,13 @@ static void test_GetSecurityInfo(void) > return; > } > > + if (GetVolumePathName(myARGV[0], volumepathname, 50) && > + GetVolumeInformation(volumepathname, NULL, 0, NULL, NULL, &filesystemflags, NULL, 0) && > + (filesystemflags & FILE_PERSISTENT_ACLS)) > + { > + testacl = TRUE; > + } Testing file system flags is not a good idea, that won't work on Wine. It's better to test the results of the actual call. -- Alexandre Julliard julliard(a)winehq.org

Nov. 18, 2009

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)

by Paul Vriens

On 11/18/2009 09:54 AM, Austin Lund wrote: > + TCHAR volumepathname[50]; Please don't use TCHAR's. > + BOOL testacl = FALSE; > + DWORD filesystemflags; > > if (!pGetSecurityInfo) > { > @@ -3143,6 +3146,13 @@ static void test_GetSecurityInfo(void) > return; > } > > + if (GetVolumePathName(myARGV[0], volumepathname, 50)&& > + GetVolumeInformation(volumepathname, NULL, 0, NULL, NULL,&filesystemflags, NULL, 0)&& > + (filesystemflags& FILE_PERSISTENT_ACLS)) > + { > + testacl = TRUE; > + } GetVolumePathName is not available before W2K so you should use GetProcAddress here and bail out or skip() if the function is not available. It's also probably better to use the explicit A-versions for both calls. -- Cheers, Paul.

Nov. 18, 2009

Re: Test for Bug 4543: Testers needed

by Dmitry Timoshkov

"Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > I've attached the patch so you can build a gdi32_test.exe that contains > my tests. Why don't you use the same way of comparing EMFs as other tests do, compare_emf_bits()/dump_emf_bits()/dump_emf_records()? -- Dmitry.

Nov. 18, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

Vincent Povirk wrote: > You still have the loop comparing to 0xff, and the test won't pass on > windows with the if(0). Whoops, that must have been an old version of the patch. I fixed the first one, and the second one should be fixed, too. Now the BitBlt(...,WHITENESS) call executes on Windows, but not on Wine. (There should be a function in wine/test.h for doing this.) Patch attached. > > On Tue, Nov 17, 2009 at 6:09 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> All right, this should be the last one. The tests pass on Wine, and >> should pass on Windows if you un-if(0) the call to BitBlt(..., >> WHITENESS). I still don't have any results for the many other Windows >> versions (95, 98, ME, NT4, 2000, Vista, Win7), so I'm going to wait for >> results from these other platforms before I send this to wine-patches. >> >> Chip >> >> >> From 2d5aa7c607496c1b05a7a08adfee09db446754cb Mon Sep 17 00:00:00 2001 >> From: Charles Davis <cdavis(a)mymail.mines.edu> >> Date: Tue, 17 Nov 2009 11:10:50 -0700 >> Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. >> To: wine-patches <wine-patches(a)winehq.org> >> Reply-To: wine-devel <wine-devel(a)winehq.org> >> >> --- >> dlls/gdi32/tests/metafile.c | 83 +++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 83 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c >> index b559901..19401ed 100644 >> --- a/dlls/gdi32/tests/metafile.c >> +++ b/dlls/gdi32/tests/metafile.c >> @@ -665,6 +665,88 @@ static void test_SaveDC(void) >> DestroyWindow(hwnd); >> } >> >> +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) >> +{ >> + UINT *pi = (UINT *)data; >> + EMRBITBLT *emrbb; >> + >> + if(emfr->iType != EMR_BITBLT) return 1; >> + emrbb = (EMRBITBLT *)emfr; >> + >> + (*pi)++; >> + if(*pi > 2) return 1; >> + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); >> + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); >> + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); >> + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); >> + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); >> + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); >> + if(*pi == 1) /* First BitBlt */ >> + { >> + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); >> + } >> + else >> + { >> + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); >> + } >> + return 1; >> +} >> + >> +static void test_emf_BitBlt(void) >> +{ >> + HDC hdcDisplay, hdcMetafile, hdcBitmap; >> + HBITMAP hBitmap, hOldBitmap; >> + HENHMETAFILE hMetafile; >> + ENHMETAHEADER emh; >> + BYTE *bits; >> + BOOL ret; >> + UINT i; >> + >> + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); >> + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); >> + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); >> + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); >> + >> + hdcBitmap = CreateCompatibleDC(hdcDisplay); >> + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); >> + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); >> + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); >> + hOldBitmap = SelectObject(hdcBitmap, hBitmap); >> + >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); >> + ok( ret, "BitBlt failed\n" ); >> + if(0) /* Crashes on wine */ >> + { >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); >> + ok( ret, "BitBlt failed\n" ); >> + } >> + >> + hMetafile = CloseEnhMetaFile(hdcMetafile); >> + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); >> + >> + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); >> + ok( ret != 0, "GetEnhMetaFileHeader failed\n" ); >> + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); >> + >> + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); >> + if(!bits) >> + { >> + skip( "not enough memory for EMF bits\n" ); >> + return; >> + } >> + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); >> + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); >> + for(i = 0; i < emh.nBytes; i++) >> + todo_wine ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); >> + >> + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); >> + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); >> + >> + SelectObject(hdcBitmap, hOldBitmap); >> + DeleteObject(hBitmap); >> + DeleteDC(hdcBitmap); >> +} >> + >> static void test_mf_SaveDC(void) >> { >> HDC hdcMetafile; >> @@ -2628,6 +2710,7 @@ START_TEST(metafile) >> /* For enhanced metafiles (enhmfdrv) */ >> test_ExtTextOut(); >> test_SaveDC(); >> + test_emf_BitBlt(); >> >> /* For win-format metafiles (mfdrv) */ >> test_mf_SaveDC(); >> -- >> 1.6.5.2 >> >> >> > > > Chip >From 990018e6e74279c3243d2c3b48472e94d8839c8c Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 67 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 67 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..dbeff43 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,72 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + (*pi)++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + i = 0; + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; @@ -2628,6 +2694,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Austin English

On Tue, Nov 17, 2009 at 10:52 AM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands. As Jacek pointed out, there are not any different installers for each Unix...there is no installer, just a cab file put in the right place (or downloaded on wineprefix creation). Please investigate such obvious issues before complaining about them (especially a second time after it was already explained). -- -Austin

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

All right, this should be the last one. The tests pass on Wine, and should pass on Windows if you un-if(0) the call to BitBlt(..., WHITENESS). I still don't have any results for the many other Windows versions (95, 98, ME, NT4, 2000, Vista, Win7), so I'm going to wait for results from these other platforms before I send this to wine-patches. Chip >From 2d5aa7c607496c1b05a7a08adfee09db446754cb Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 83 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 83 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..19401ed 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,88 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + (*pi)++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; + ENHMETAHEADER emh; + BYTE *bits; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); + ok( ret != 0, "GetEnhMetaFileHeader failed\n" ); + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); + + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); + if(!bits) + { + skip( "not enough memory for EMF bits\n" ); + return; + } + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); + for(i = 0; i < emh.nBytes; i++) + todo_wine ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); + + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; @@ -2628,6 +2710,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

Nov. 17, 2009

Re: flaky uninit variable in jscript

by Dan Kegel

There was a second new error in that file that is probably low hanging fruit: Conditional jump or move depends on uninitialised value(s) at invoke_constructor (function.c:243) by Function_value (function.c:521) by invoke_prop_func (dispex.c:259) by jsdisp_call (dispex.c:870) by disp_call (dispex.c:899) by new_expression_eval (engine.c:1568) by expr_eval (engine.c:42) by assign_expression_eval (engine.c:3110) by expr_eval (engine.c:42) by expression_statement_eval (engine.c:679) by stat_eval (engine.c:37) by exec_source (engine.c:473) by exec_global_code (jscript.c:107) by JScriptParse_ParseScriptText (jscript.c:717) by parse_script (run.c:765) by run_from_res (run.c:908) by run_tests (run.c:1057) by func_run (run.c:1095) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at invoke_constructor (function.c:227) Both are still happening as of the last run I have, http://kegel.com/wine/valgrind/logs/2009-11-17-07.31/vg-jscript_run.txt - Dan On Thu, Nov 5, 2009 at 7:25 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Jacek, > could you have a look at this? I think there are some variants that > aren't being > cleanly initialized. > > http://kegel.com/wine/valgrind/logs/2009-11-05-09.09/diff-jscript_run.txt > http://kegel.com/wine/valgrind/logs/2009-11-05-09.09/vg-jscript_run.txt > > Conditional jump or move depends on uninitialised value(s) > at VARIANT_ValidateType (variant.c:546) > by VariantClear (variant.c:599) > by exec_global_code (jscript.c:111) > by JScriptParse_ParseScriptText (jscript.c:717) > by parse_text (script.c:624) > by parse_inline_script (script.c:679) > by parse_script_elem (script.c:703) > by doc_insert_script (script.c:817) > by nsRunnable_Run (mutation.c:464) > by ??? > by ??? > by add_script_runner (mutation.c:196) > by push_mutation_queue (mutation.c:253) > by nsDocumentObserver_DoneAddingChildren (mutation.c:684) > by ??? > by ??? > by ??? > by ??? > by ??? > by ??? > Uninitialised value was created by a stack allocation > at exec_global_code (jscript.c:94) > > Thanks, > Dan >

Nov. 17, 2009

Re: Working on avifil32, sudden "non enough memory" error

by Julius Schwartzenberg

Marcus Meissner wrote: > On Mon, Nov 16, 2009 at 10:52:04AM +0100, Julius Schwartzenberg wrote: >> Dan Kegel wrote: >>> Julius wrote: >>>> With one file however (GOODTIME.AVI from the win95 cd) I get this >>>> error after about a second: >>>> err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 >>>> next block has PREV_FREE flag >>>> non enough memory >>>> >>>> I have no idea where this comes from and why it happens. (It appears to >>>> be unrelated to the memcpy call in avifile.c around line 1114.) With >>>> +heap I also get this before the error: >>>> HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. >>>> (the assert fails) >>> Sounds like heap corruption. You might want to cut down the >>> file to the shortest one that causes the crash, then go >>> after it (possibly using valgrind or the like) to look for >>> the error. >> With valgrind I was able to find the problem actually happens when >> AVIFILE_ReadBlock is called and a new block is about to be read. >> There doesn't seem to be anything special about this however, as for >> the previous blocks (and different files) it works just fine. > > You could insert > HeapValidate(GetProcessHeap(),0,0);FIXME("at place x\n"); > at multiple interesting places in your code and +heap will then trigger > on when the corruption happens. Thanks! I was able to find the problem. Indeed something going wrong with the size. It appears I need to add another hack and come up with some extremely good test cases...... Regards, Julius

Nov. 17, 2009

ntdll: implement FLG_HEAP_ENABLE_TAIL_CHECK

by Dan Kegel

(Without a change like this, Valgrind can't properly detect buffer overruns, but even without Valgrind, this change will improve Wine's ability to detect buffer overruns.) With this change, users can enable buffer overrun detection in Wine by setting WINE_GLOBAL_FLAGS=0x10. This is like the overrun detection in Windows enabled by setting NtGlobalFlags to 0x10, but checks 16 bytes rather than 8, and works for large allocations, not just small ones. With this enabled, a remarkable number of tests break. I'm posting this to wine-devel for review while I add valgrind annotations (which should make it easier to tell whether the errors it detects are real or spurious) and fix the spurious breakages. Note that this change is a no-op under normal circumstances; without setting WINE_GLOBAL_FLAGS, you shouldn't see any breakage.

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Vincent Povirk

On Tue, Nov 17, 2009 at 3:50 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> If I comment out the for loop and initialize i to 1, the test succeeds >> on Windows. >> > There's one test that succeeds if there are exactly two BitBlt() records > in the metafile. The test_BitBlt_record() function just increments i > (through a pointer) every time it encounters a BitBlt() record. What > happens when i is initialized to 0? Sorry, that was a typo. I really did initialize i to 0. -- Vincent Povirk

Nov. 17, 2009

Re: [RFC] Handle process token groups in server/file.c::sd_to_mode

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have just tested this patch with the World of Warcraft launcher (couldn't before due to a mismatch between 32-bit and 64-bit jpeg versions, and Gentoo masking out jpeg). After SetFileSecurityW (L"H:\\Games\\World of Warcraft", 0x4, 0x1697c8) with the ACL "(A;OICI;GA;;;BU)", the permissions on the World of Warcraft directory are rwxr-x---, and the Launcher successfully starts the Downloader. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksDHQUACgkQTHDAI68Nsumt2ACdHX9emdsvGPkfpGVfky9WRuvY DR4AoIP0qHiR4Kls1tIcKX+Wed+UwoA8 =iAmD -----END PGP SIGNATURE-----

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

Vincent Povirk wrote: > Now on windows (with s/if(0)/if(1)/) I get lots of: > > metafile.c:740: Test failed: unexpected EMF bits: got 01, expected 0xff > > metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff > > metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff > > ... > > You, uh, do realize metafiles are a vector format, right? The data > isn't really going to be all 1's. Right. I thought, though, that the GetEnhMetaFileBits() function would return the bits as they are drawn by playing the metafile. Silly me. It returns the raw bits in the metafile itself. (The use of the term "bits" confused me.) That test is going to go away then. > > If I comment out the for loop and initialize i to 1, the test succeeds > on Windows. > There's one test that succeeds if there are exactly two BitBlt() records in the metafile. The test_BitBlt_record() function just increments i (through a pointer) every time it encounters a BitBlt() record. What happens when i is initialized to 0? Chip

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Vincent Povirk

Now on windows (with s/if(0)/if(1)/) I get lots of: metafile.c:740: Test failed: unexpected EMF bits: got 01, expected 0xff metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff ... You, uh, do realize metafiles are a vector format, right? The data isn't really going to be all 1's. If I comment out the for loop and initialize i to 1, the test succeeds on Windows. -- Vincent Povirk

Nov. 17, 2009

Re: To error out or to skip tests?

by Paul Vriens

On 11/17/2009 09:38 PM, Greg Geldorp wrote: > Hi Jörg > >>> The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, >>> 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! >>> They all have no sound configured. Mostly useless. >> >> A lot of those VMware boxes are mine. They come in two flavors. Some of >> them (starting with esx-) are ESX VMs, ESX is VMware's data center > product, >> which simply doesn't support sound. The others (starting with gvg-) are >> Server VMs, which do support sound. The reason I didn't configure sound >> on them is because I'm simply not interested in sound. I'll consider >> enabling sound, but to be honest I'm a bit put off by your aggressive > tone. >> >> Anyway, the end result is that there will always be ESX VMs that can't >> run sound tests. > > After a bit of mucking around I got sound to work on the Linux host where > those VMware Server VMs run, and enabled sound in the VMs where possible. I > could not find correct sound drivers for some of the old stuff (NT4 and > below), so those still don't have sound, neither do the ESX VMs. For W98 and WinME you should be able to use: http://support.creative.com/downloads/download.aspx?nDownloadId=1843 I've installed these on both platforms without any problems. > > Best regards, Ge. > -- Cheers, Paul.

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

OK, try this one. It has the BitBlt(..., WHITENESS) call if(0)'d out, so the test doesn't crash. I also fixed the issue with the other BitBlt() failing on Wine (I used a memory DC). I also put some tests that depend on the WHITENESS call succeeding into todo_wine blocks. Oddly enough, the check for the bits being all 1s succeeds on wine, even though it's not supposed to. I also fixed the increment of the number of BitBlt() records in test_BitBlt_record(). Now instead of incrementing the pointer, it actually increments the count. (How could I have been so blind?) This should work on Windows, too. Chip >From 2d5aa7c607496c1b05a7a08adfee09db446754cb Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 83 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 83 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..19401ed 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,88 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + (*pi)++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; + ENHMETAHEADER emh; + BYTE *bits; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); + ok( ret != 0, "GetEnhMetaFileHeader failed\n" ); + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); + + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); + if(!bits) + { + skip( "not enough memory for EMF bits\n" ); + return; + } + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); + for(i = 0; i < emh.nBytes; i++) + todo_wine ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); + + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; @@ -2628,6 +2710,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

Nov. 17, 2009

Re: [PATCH 2/2] [Msvcrt]: in undname functions, no longer use a fixed-size array for storing internal information

by Eric Pouech

Paul Vriens a écrit : > > On 11/15/2009 10:07 PM, Eric Pouech wrote: >> >> (fix for #20681) > > Hi Eric, > > This new test fails on all 32bit systems: > > http://test.winehq.org/data/tests/msvcrt:cpp.html > > The only box where there are no failures is a 64bit one, but no tests > are actually run there ;) > > Could you have a look? > patch sent to wine-patches should be ok by now I _just_ hope it won't break the 64bit box <g> A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Charles Davis

Vincent Povirk wrote: > On windows, I get: > > metafile.c:705: Test failed: CreateDCA error 1801 Hmm... now that I think about it, I think the call to CreateDCA() should look like this: hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); > > metafile.c:710: Test failed: BitBlt error 1801 BitBlt() failed because there was no DC to blit from. That should go away when I fix CreateDCA(). > > metafile.c:730: Test failed: unexpected EMF bits: got 01, expected 0xff > > metafile.c:730: Test failed: unexpected EMF bits: got 00, expected 0xff > > metafile.c:730: Test failed: unexpected EMF bits: got 00, expected 0xff > > ... Now this is interesting. I would expect all the bits to be ones, yet here, they're (almost) all zeros. It's like BitBlt(..., WHITENESS) had no effect. Or, maybe I got the meaning of the bits backwards. > > On Wine, I get: > > metafile.c:710: Test failed: BitBlt error 0 Now why does that one fail? I also need to stop printing the last error, because BitBlt() apparently doesn't set the last error. (Need to pay more attention to MSDN...) > wine: Unhandled page fault on read access to 0x00000000 at address > 0x686476e5 (thread 0009), starting debugger... > (same crash that's on bug 4543) Since it crashes, I'll have to if(0) that one out. > > On Tue, Nov 17, 2009 at 2:04 PM, Vincent Povirk > <madewokherd+8cd9(a)gmail.com> wrote: >> On closer inspection, you didn't add a call to your static function, >> so that was meaningless. >> >> On Tue, Nov 17, 2009 at 1:59 PM, Vincent Povirk >> <madewokherd+8cd9(a)gmail.com> wrote: >>> This passes on my Windows XP vm and on Wine here. >>> >>> On Tue, Nov 17, 2009 at 12:44 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>>> Hi, >>>> >>>> I have a test that I wrote from scratch for bug 4543. It tests the >>>> operation of BitBlt to a metafile, first from the screen then pure >>>> whiteness. Unfortunately, I have no Windows boxes to test on, so I need >>>> people to run my test on Windows. After all, I need to verify that this >>>> test is an accurate representation of Windows' behavior! >>>> >>>> Also, testing under Wine would be appreciated. As a Mac user, I don't >>>> think my system is representative of the vast majority of Wine users >>>> (who probably run Linux). >>>> >>>> I've attached the patch so you can build a gdi32_test.exe that contains >>>> my tests. >>>> >>>> Thanks in advance. >>>> >>>> Chip >>>> >>>> From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001 >>>> From: Charles Davis <cdavis(a)mymail.mines.edu> >>>> Date: Tue, 17 Nov 2009 11:10:50 -0700 >>>> Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. >>>> To: wine-patches <wine-patches(a)winehq.org> >>>> Reply-To: wine-devel <wine-devel(a)winehq.org> >>>> >>>> --- >>>> dlls/gdi32/tests/metafile.c | 68 +++++++++++++++++++++++++++++++++++++++++++ >>>> 1 files changed, 68 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c >>>> index b559901..6bf25e4 100644 >>>> --- a/dlls/gdi32/tests/metafile.c >>>> +++ b/dlls/gdi32/tests/metafile.c >>>> @@ -665,6 +665,74 @@ static void test_SaveDC(void) >>>> DestroyWindow(hwnd); >>>> } >>>> >>>> +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) >>>> +{ >>>> + UINT *pi = (UINT *)data; >>>> + EMRBITBLT *emrbb; >>>> + >>>> + if(emfr->iType != EMR_BITBLT) return 1; >>>> + emrbb = (EMRBITBLT *)emfr; >>>> + >>>> + *pi++; >>>> + if(*pi > 2) return 1; >>>> + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); >>>> + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); >>>> + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); >>>> + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); >>>> + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); >>>> + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); >>>> + if(*pi == 1) /* First BitBlt */ >>>> + { >>>> + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); >>>> + } >>>> + else >>>> + { >>>> + ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); >>>> + } >>>> + return 1; >>>> +} >>>> + >>>> +static void test_emf_BitBlt(void) >>>> +{ >>>> + HDC hdcDisplay, hdcMetafile; >>>> + HENHMETAFILE hMetafile; >>>> + ENHMETAHEADER emh; >>>> + BYTE *bits; >>>> + BOOL ret; >>>> + UINT i; >>>> + >>>> + hdcDisplay = CreateDCA(NULL, "DISPLAY", NULL, NULL); >>>> + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); >>>> + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); >>>> + ok( hdcMetafile != 0, "CreateEnhMetaFileA error %d\n", GetLastError() ); >>>> + >>>> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcDisplay, 0, 0, SRCCOPY); >>>> + ok( ret, "BitBlt error %d\n", GetLastError() ); >>>> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); >>>> + ok( ret, "BitBlt error %d\n", GetLastError() ); >>>> + >>>> + hMetafile = CloseEnhMetaFile(hdcMetafile); >>>> + ok( hMetafile != 0, "CloseEnhMetaFile error %d\n", GetLastError() ); >>>> + >>>> + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); >>>> + ok( ret != 0, "GetEnhMetaFileHeader error %d\n", GetLastError() ); >>>> + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); >>>> + >>>> + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); >>>> + if(!bits) >>>> + { >>>> + skip( "not enough memory for EMF bits\n" ); >>>> + return; >>>> + } >>>> + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); >>>> + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); >>>> + for(i = 0; i < emh.nBytes; i++) >>>> + ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); >>>> + >>>> + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, (LPARAM)&i, NULL); >>>> + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); >>>> +} >>>> + >>>> static void test_mf_SaveDC(void) >>>> { >>>> HDC hdcMetafile; >>>> -- >>>> 1.6.5.2 >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Vincent Povirk >>> >> >> >> -- >> Vincent Povirk >> > > > Thanks. Chip

Nov. 17, 2009

Re: To error out or to skip tests?

by Greg Geldorp

Hi Jörg > > The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, > > 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! > > They all have no sound configured. Mostly useless. > > A lot of those VMware boxes are mine. They come in two flavors. Some of > them (starting with esx-) are ESX VMs, ESX is VMware's data center product, > which simply doesn't support sound. The others (starting with gvg-) are > Server VMs, which do support sound. The reason I didn't configure sound > on them is because I'm simply not interested in sound. I'll consider > enabling sound, but to be honest I'm a bit put off by your aggressive tone. > > Anyway, the end result is that there will always be ESX VMs that can't > run sound tests. After a bit of mucking around I got sound to work on the Linux host where those VMware Server VMs run, and enabled sound in the VMs where possible. I could not find correct sound drivers for some of the old stuff (NT4 and below), so those still don't have sound, neither do the ESX VMs. Best regards, Ge.

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Vincent Povirk

On windows, I get: metafile.c:705: Test failed: CreateDCA error 1801 metafile.c:710: Test failed: BitBlt error 1801 metafile.c:730: Test failed: unexpected EMF bits: got 01, expected 0xff metafile.c:730: Test failed: unexpected EMF bits: got 00, expected 0xff metafile.c:730: Test failed: unexpected EMF bits: got 00, expected 0xff ... On Wine, I get: metafile.c:710: Test failed: BitBlt error 0 wine: Unhandled page fault on read access to 0x00000000 at address 0x686476e5 (thread 0009), starting debugger... (same crash that's on bug 4543) On Tue, Nov 17, 2009 at 2:04 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > On closer inspection, you didn't add a call to your static function, > so that was meaningless. > > On Tue, Nov 17, 2009 at 1:59 PM, Vincent Povirk > <madewokherd+8cd9(a)gmail.com> wrote: >> This passes on my Windows XP vm and on Wine here. >> >> On Tue, Nov 17, 2009 at 12:44 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> Hi, >>> >>> I have a test that I wrote from scratch for bug 4543. It tests the >>> operation of BitBlt to a metafile, first from the screen then pure >>> whiteness. Unfortunately, I have no Windows boxes to test on, so I need >>> people to run my test on Windows. After all, I need to verify that this >>> test is an accurate representation of Windows' behavior! >>> >>> Also, testing under Wine would be appreciated. As a Mac user, I don't >>> think my system is representative of the vast majority of Wine users >>> (who probably run Linux). >>> >>> I've attached the patch so you can build a gdi32_test.exe that contains >>> my tests. >>> >>> Thanks in advance. >>> >>> Chip >>> >>> From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001 >>> From: Charles Davis <cdavis(a)mymail.mines.edu> >>> Date: Tue, 17 Nov 2009 11:10:50 -0700 >>> Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. >>> To: wine-patches <wine-patches(a)winehq.org> >>> Reply-To: wine-devel <wine-devel(a)winehq.org> >>> >>> --- >>> dlls/gdi32/tests/metafile.c | 68 +++++++++++++++++++++++++++++++++++++++++++ >>> 1 files changed, 68 insertions(+), 0 deletions(-) >>> >>> diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c >>> index b559901..6bf25e4 100644 >>> --- a/dlls/gdi32/tests/metafile.c >>> +++ b/dlls/gdi32/tests/metafile.c >>> @@ -665,6 +665,74 @@ static void test_SaveDC(void) >>> DestroyWindow(hwnd); >>> } >>> >>> +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) >>> +{ >>> + UINT *pi = (UINT *)data; >>> + EMRBITBLT *emrbb; >>> + >>> + if(emfr->iType != EMR_BITBLT) return 1; >>> + emrbb = (EMRBITBLT *)emfr; >>> + >>> + *pi++; >>> + if(*pi > 2) return 1; >>> + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); >>> + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); >>> + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); >>> + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); >>> + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); >>> + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); >>> + if(*pi == 1) /* First BitBlt */ >>> + { >>> + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); >>> + } >>> + else >>> + { >>> + ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); >>> + } >>> + return 1; >>> +} >>> + >>> +static void test_emf_BitBlt(void) >>> +{ >>> + HDC hdcDisplay, hdcMetafile; >>> + HENHMETAFILE hMetafile; >>> + ENHMETAHEADER emh; >>> + BYTE *bits; >>> + BOOL ret; >>> + UINT i; >>> + >>> + hdcDisplay = CreateDCA(NULL, "DISPLAY", NULL, NULL); >>> + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); >>> + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); >>> + ok( hdcMetafile != 0, "CreateEnhMetaFileA error %d\n", GetLastError() ); >>> + >>> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcDisplay, 0, 0, SRCCOPY); >>> + ok( ret, "BitBlt error %d\n", GetLastError() ); >>> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); >>> + ok( ret, "BitBlt error %d\n", GetLastError() ); >>> + >>> + hMetafile = CloseEnhMetaFile(hdcMetafile); >>> + ok( hMetafile != 0, "CloseEnhMetaFile error %d\n", GetLastError() ); >>> + >>> + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); >>> + ok( ret != 0, "GetEnhMetaFileHeader error %d\n", GetLastError() ); >>> + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); >>> + >>> + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); >>> + if(!bits) >>> + { >>> + skip( "not enough memory for EMF bits\n" ); >>> + return; >>> + } >>> + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); >>> + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); >>> + for(i = 0; i < emh.nBytes; i++) >>> + ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); >>> + >>> + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, (LPARAM)&i, NULL); >>> + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); >>> +} >>> + >>> static void test_mf_SaveDC(void) >>> { >>> HDC hdcMetafile; >>> -- >>> 1.6.5.2 >>> >>> >>> >>> >>> >> >> >> >> -- >> Vincent Povirk >> > > > > -- > Vincent Povirk > -- Vincent Povirk

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Vincent Povirk

On closer inspection, you didn't add a call to your static function, so that was meaningless. On Tue, Nov 17, 2009 at 1:59 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > This passes on my Windows XP vm and on Wine here. > > On Tue, Nov 17, 2009 at 12:44 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> Hi, >> >> I have a test that I wrote from scratch for bug 4543. It tests the >> operation of BitBlt to a metafile, first from the screen then pure >> whiteness. Unfortunately, I have no Windows boxes to test on, so I need >> people to run my test on Windows. After all, I need to verify that this >> test is an accurate representation of Windows' behavior! >> >> Also, testing under Wine would be appreciated. As a Mac user, I don't >> think my system is representative of the vast majority of Wine users >> (who probably run Linux). >> >> I've attached the patch so you can build a gdi32_test.exe that contains >> my tests. >> >> Thanks in advance. >> >> Chip >> >> From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001 >> From: Charles Davis <cdavis(a)mymail.mines.edu> >> Date: Tue, 17 Nov 2009 11:10:50 -0700 >> Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. >> To: wine-patches <wine-patches(a)winehq.org> >> Reply-To: wine-devel <wine-devel(a)winehq.org> >> >> --- >> dlls/gdi32/tests/metafile.c | 68 +++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 68 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c >> index b559901..6bf25e4 100644 >> --- a/dlls/gdi32/tests/metafile.c >> +++ b/dlls/gdi32/tests/metafile.c >> @@ -665,6 +665,74 @@ static void test_SaveDC(void) >> DestroyWindow(hwnd); >> } >> >> +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) >> +{ >> + UINT *pi = (UINT *)data; >> + EMRBITBLT *emrbb; >> + >> + if(emfr->iType != EMR_BITBLT) return 1; >> + emrbb = (EMRBITBLT *)emfr; >> + >> + *pi++; >> + if(*pi > 2) return 1; >> + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); >> + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); >> + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); >> + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); >> + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); >> + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); >> + if(*pi == 1) /* First BitBlt */ >> + { >> + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); >> + } >> + else >> + { >> + ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); >> + } >> + return 1; >> +} >> + >> +static void test_emf_BitBlt(void) >> +{ >> + HDC hdcDisplay, hdcMetafile; >> + HENHMETAFILE hMetafile; >> + ENHMETAHEADER emh; >> + BYTE *bits; >> + BOOL ret; >> + UINT i; >> + >> + hdcDisplay = CreateDCA(NULL, "DISPLAY", NULL, NULL); >> + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); >> + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); >> + ok( hdcMetafile != 0, "CreateEnhMetaFileA error %d\n", GetLastError() ); >> + >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcDisplay, 0, 0, SRCCOPY); >> + ok( ret, "BitBlt error %d\n", GetLastError() ); >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); >> + ok( ret, "BitBlt error %d\n", GetLastError() ); >> + >> + hMetafile = CloseEnhMetaFile(hdcMetafile); >> + ok( hMetafile != 0, "CloseEnhMetaFile error %d\n", GetLastError() ); >> + >> + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); >> + ok( ret != 0, "GetEnhMetaFileHeader error %d\n", GetLastError() ); >> + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); >> + >> + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); >> + if(!bits) >> + { >> + skip( "not enough memory for EMF bits\n" ); >> + return; >> + } >> + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); >> + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); >> + for(i = 0; i < emh.nBytes; i++) >> + ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); >> + >> + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, (LPARAM)&i, NULL); >> + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); >> +} >> + >> static void test_mf_SaveDC(void) >> { >> HDC hdcMetafile; >> -- >> 1.6.5.2 >> >> >> >> >> > > > > -- > Vincent Povirk > -- Vincent Povirk

Nov. 17, 2009

Re: Test for Bug 4543: Testers needed

by Vincent Povirk

This passes on my Windows XP vm and on Wine here. On Tue, Nov 17, 2009 at 12:44 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > Hi, > > I have a test that I wrote from scratch for bug 4543. It tests the > operation of BitBlt to a metafile, first from the screen then pure > whiteness. Unfortunately, I have no Windows boxes to test on, so I need > people to run my test on Windows. After all, I need to verify that this > test is an accurate representation of Windows' behavior! > > Also, testing under Wine would be appreciated. As a Mac user, I don't > think my system is representative of the vast majority of Wine users > (who probably run Linux). > > I've attached the patch so you can build a gdi32_test.exe that contains > my tests. > > Thanks in advance. > > Chip > > From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001 > From: Charles Davis <cdavis(a)mymail.mines.edu> > Date: Tue, 17 Nov 2009 11:10:50 -0700 > Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. > To: wine-patches <wine-patches(a)winehq.org> > Reply-To: wine-devel <wine-devel(a)winehq.org> > > --- > dlls/gdi32/tests/metafile.c | 68 +++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 68 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c > index b559901..6bf25e4 100644 > --- a/dlls/gdi32/tests/metafile.c > +++ b/dlls/gdi32/tests/metafile.c > @@ -665,6 +665,74 @@ static void test_SaveDC(void) > DestroyWindow(hwnd); > } > > +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) > +{ > + UINT *pi = (UINT *)data; > + EMRBITBLT *emrbb; > + > + if(emfr->iType != EMR_BITBLT) return 1; > + emrbb = (EMRBITBLT *)emfr; > + > + *pi++; > + if(*pi > 2) return 1; > + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); > + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); > + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); > + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); > + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); > + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); > + if(*pi == 1) /* First BitBlt */ > + { > + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); > + } > + else > + { > + ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); > + } > + return 1; > +} > + > +static void test_emf_BitBlt(void) > +{ > + HDC hdcDisplay, hdcMetafile; > + HENHMETAFILE hMetafile; > + ENHMETAHEADER emh; > + BYTE *bits; > + BOOL ret; > + UINT i; > + > + hdcDisplay = CreateDCA(NULL, "DISPLAY", NULL, NULL); > + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); > + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); > + ok( hdcMetafile != 0, "CreateEnhMetaFileA error %d\n", GetLastError() ); > + > + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcDisplay, 0, 0, SRCCOPY); > + ok( ret, "BitBlt error %d\n", GetLastError() ); > + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); > + ok( ret, "BitBlt error %d\n", GetLastError() ); > + > + hMetafile = CloseEnhMetaFile(hdcMetafile); > + ok( hMetafile != 0, "CloseEnhMetaFile error %d\n", GetLastError() ); > + > + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); > + ok( ret != 0, "GetEnhMetaFileHeader error %d\n", GetLastError() ); > + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); > + > + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); > + if(!bits) > + { > + skip( "not enough memory for EMF bits\n" ); > + return; > + } > + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); > + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); > + for(i = 0; i < emh.nBytes; i++) > + ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); > + > + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, (LPARAM)&i, NULL); > + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); > +} > + > static void test_mf_SaveDC(void) > { > HDC hdcMetafile; > -- > 1.6.5.2 > > > > > -- Vincent Povirk

Nov. 17, 2009

Re: ddraw/tests: Fix test failure for D3DFMT_A2R10G10B10 pixel format in GetDC tests

by Stefan Dösinger

Am 17.11.2009 um 12:16 schrieb Austin Lund: >>> <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt> >> Where did this test fail? On Wine or Windows? If it was on windows, which windows version and GPU did you use? >> > > WinXP SP2 running in Virtual box 3.0.8 with guest additions installed: > > http://test.winehq.org/data/d51b4e19fb99e30eadd6207d8dba7b0d36363c3d/xp_apl… VirtualBox uses Wine's ddraw/d3d infrastructure. It is likely that you tested the new test against an old Wine prior to when this test and fixes were committed. Your patch contradicts the behavior I saw on a Geforce 7400 Go on Windows Vista, and on a Radeon 9000 Mobility on Windows XP. As such I don't think we should enable GetDC on this format unless we find evidence on a real system that A2R10G10B10 allows GetDC calls. If we find such a system the test should be changed to accept both outcomes(ie, comment out the A2R10G10B10 test)

Nov. 17, 2009

Test for Bug 4543: Testers needed

by Charles Davis

Hi, I have a test that I wrote from scratch for bug 4543. It tests the operation of BitBlt to a metafile, first from the screen then pure whiteness. Unfortunately, I have no Windows boxes to test on, so I need people to run my test on Windows. After all, I need to verify that this test is an accurate representation of Windows' behavior! Also, testing under Wine would be appreciated. As a Mac user, I don't think my system is representative of the vast majority of Wine users (who probably run Linux). I've attached the patch so you can build a gdi32_test.exe that contains my tests. Thanks in advance. Chip >From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 68 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 68 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..6bf25e4 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,74 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + *pi++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile; + HENHMETAFILE hMetafile; + ENHMETAHEADER emh; + BYTE *bits; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA(NULL, "DISPLAY", NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA error %d\n", GetLastError() ); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcDisplay, 0, 0, SRCCOPY); + ok( ret, "BitBlt error %d\n", GetLastError() ); + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt error %d\n", GetLastError() ); + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile error %d\n", GetLastError() ); + + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); + ok( ret != 0, "GetEnhMetaFileHeader error %d\n", GetLastError() ); + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); + + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); + if(!bits) + { + skip( "not enough memory for EMF bits\n" ); + return; + } + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); + for(i = 0; i < emh.nBytes; i++) + ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); + + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, (LPARAM)&i, NULL); + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; -- 1.6.5.2

Nov. 17, 2009

Re: new crash in urlmon/misc test?

by Jacek Caban

Dan Kegel wrote: > http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/diff-urlmon_misc.txt > http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/vg-urlmon_misc.txt > show the new crash > > Unhandled exception: page fault on read access to 0xf0f0f0f0 in 32-bit > code (0x0c530e3b). > Register dump: > CS:0023 SS:002b DS:002b ES:0000 FS:000b GS:0013 > EIP:0c530e3b ESP:7f21fc48 EBP:7f21fc58 EFLAGS:00000084( - -- S - -P- ) > EAX:f0f0f0f0 EBX:0ce3cff4 ECX:0cf416a0 EDX:00000409 > ESI:7f21fe70 EDI:7bf00de0 > Stack dump: > 0x7f21fc48: 0cda560d 0cdfd62d 00000000 f0f0f0f0 > 0x7f21fc58: 7f21fc98 0cde15cd f0f0f0f0 7bf00de0 > 0x7f21fc68: 0cf0cebd 0cf34f5a 7f03f380 0cf41ff4 > 0x7f21fc78: 0cda560d 0cddff10 00000000 0cf36569 > 0x7f21fc88: 0cf3616c 00000409 0ce3cff4 0ce3cff4 > 0x7f21fc98: 7f21fcd8 0cde1b39 00000409 00000000 > Backtrace: > =>0 0x0c530e3b strlenW+0x15(str=0xf0f0f0f0) > [include/wine/unicode.h:216] in libwine.so.1 > 1 0x0cde15cd CompareStringW+0xc6(lcid=1033, style=0, > str1=0xf0f0f0f0, len1=-1, str2=0xcf365bc, len2=-1) > [dlls/kernel32/locale.c:2737] in kernel32 > 2 0x0cde1b39 lstrcmpW+0x7a(str1=0xf0f0f0f0, str2=0xcf365bc) > [dlls/kernel32/locale.c:2892] in kernel32 > 3 0x0cf0ef56 test_FindMimeFromData+0x119() > [dlls/urlmon/tests/misc.c:623] in urlmon_test > 4 0x0cf134b6 func_misc+0x44() [dlls/urlmon/tests/misc.c:1349] in urlmon_test > > - Dan > Hi Dan, I can't find how is it possible. If it's easy for you, could you please run these tests with urlmon debug channel? Thanks, Jacek

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Vincent Povirk wrote: > On Tue, Nov 17, 2009 at 11:08 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > >> I also don't see much point in winelib builds so I don't plan to work on it >> myself. It will make things harder to support. The only real point I can see >> is if we wanted to provide a package for architectures are not supported by >> PE. Anyway, once mingw builds will work good, it should be much easier to >> change. >> > > For me, the point would be that a lot of build dependencies could be > eliminated, once the other tools have generally-available fixes, and > then maybe more people could build gecko as part of the normal > process. > > Or is this not true? > It is true, but it will lead to a lot of different problems. We may rethink it when we'll get at least near to the point where it won't be a theoretical discussion. Jacek

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Vincent Povirk

On Tue, Nov 17, 2009 at 11:08 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > I also don't see much point in winelib builds so I don't plan to work on it > myself. It will make things harder to support. The only real point I can see > is if we wanted to provide a package for architectures are not supported by > PE. Anyway, once mingw builds will work good, it should be much easier to > change. For me, the point would be that a lot of build dependencies could be eliminated, once the other tools have generally-available fixes, and then maybe more people could build gecko as part of the normal process. Or is this not true? -- Vincent Povirk

Nov. 17, 2009

new valgrind results...

by Dan Kegel

Yesterday's valgrind results are at http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/ These were done with updated suppressions; see http://code.google.com/p/winezeug/source/list?path=/trunk/valgrind/valgrind… so don't get too excited about errors going away. (I really should include a histogram of used suppressions so we can know which ones still need fixing.) I now terminate hung tests (or those that just take too long) with SIGALARM, which shows up as "Command terminated by signal 14". For instance, see the bottom of http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/vg-ole32_marshal.txt With luck, my automated script will now need no babying, and results will show up 'promptly' five hours after Alexandre commits. (I used to run tests in parallel to reduce that lag; perhaps I'll try doing that again sometime, carefully.)

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Jacek Caban

Vincent Povirk wrote: > On Tue, Nov 17, 2009 at 9:54 AM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > >> There's a lot of talk about the new Gecko requirement. At the end of the >> day, adding the .cab file to a binary distribution was a trivial 10 minute >> exercise. It took another 20 minutes to test everything and figure out that >> the wiki page was wrong and the .cab file needs to go in >> $PREFIX/share/wine/gecko NOT in $PREFIX/share/gecko. The wiki page is now >> fixed, so it really should be trivial to add the gecko runtime to most >> binary distributions. >> > > While I am much less annoyed now that things are working, I'd still > like to see an option for specifying the .cab file path at run time, > and for disabling the dialog completely. Maybe I'll write some > patches. > I'm not fan of this idea, but we may talk about patches once they will exist. For your (unusual IMO) case of multiple installations it might be worth to consider a special target for 'make install' that would check if gecko is available in $build_dir/../gecko and copy it if it does. > And apparently the difficult build process is being worked on but is a > hard problem to solve, so I'm satisfied with that. It's good to know > there aren't any real closed-source components needed to build, just > unusual versions / changes to open-source components. > > It sounds like the the unusual version requirements and hacks are > mostly the result of bugs in other projects that are tracked in their > bug trackers, and of the need to build a PE gecko on Linux rather than > a winelib gecko (which is itself needed because of the difficult build > process, which is because of bugs in other projects). Is this > accurate? > Yes, it's true except for mingw. I've filled one bug for them and there was no interest. I also can't send them patches because they don't agree with the way Wine includes are created. I've chosen to provide our own includes for these problems that are fixed mingw headers or just Wine replacements. I also don't see much point in winelib builds so I don't plan to work on it myself. It will make things harder to support. The only real point I can see is if we wanted to provide a package for architectures are not supported by PE. Anyway, once mingw builds will work good, it should be much easier to change. Jacek

Nov. 17, 2009

new crash in urlmon/misc test?

by Dan Kegel

http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/diff-urlmon_misc.txt http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/vg-urlmon_misc.txt show the new crash Unhandled exception: page fault on read access to 0xf0f0f0f0 in 32-bit code (0x0c530e3b). Register dump: CS:0023 SS:002b DS:002b ES:0000 FS:000b GS:0013 EIP:0c530e3b ESP:7f21fc48 EBP:7f21fc58 EFLAGS:00000084( - -- S - -P- ) EAX:f0f0f0f0 EBX:0ce3cff4 ECX:0cf416a0 EDX:00000409 ESI:7f21fe70 EDI:7bf00de0 Stack dump: 0x7f21fc48: 0cda560d 0cdfd62d 00000000 f0f0f0f0 0x7f21fc58: 7f21fc98 0cde15cd f0f0f0f0 7bf00de0 0x7f21fc68: 0cf0cebd 0cf34f5a 7f03f380 0cf41ff4 0x7f21fc78: 0cda560d 0cddff10 00000000 0cf36569 0x7f21fc88: 0cf3616c 00000409 0ce3cff4 0ce3cff4 0x7f21fc98: 7f21fcd8 0cde1b39 00000409 00000000 Backtrace: =>0 0x0c530e3b strlenW+0x15(str=0xf0f0f0f0) [include/wine/unicode.h:216] in libwine.so.1 1 0x0cde15cd CompareStringW+0xc6(lcid=1033, style=0, str1=0xf0f0f0f0, len1=-1, str2=0xcf365bc, len2=-1) [dlls/kernel32/locale.c:2737] in kernel32 2 0x0cde1b39 lstrcmpW+0x7a(str1=0xf0f0f0f0, str2=0xcf365bc) [dlls/kernel32/locale.c:2892] in kernel32 3 0x0cf0ef56 test_FindMimeFromData+0x119() [dlls/urlmon/tests/misc.c:623] in urlmon_test 4 0x0cf134b6 func_misc+0x44() [dlls/urlmon/tests/misc.c:1349] in urlmon_test - Dan

Nov. 17, 2009

Re: wineserver: Preserve existing UNIX permission bits unless a matching ACCESS_ALLOWED is specified in an ACL, always preserve directory bit

by Paul Vriens

On 11/17/2009 04:48 PM, Paul Chitescu wrote: > > --- ./file.c.orig 2009-08-19 14:25:58.000000000 +0300 > +++ ./file.c 2009-11-17 17:26:31.000000000 +0200 Patches should be relative to the root. -- Cheers, Paul.

Nov. 17, 2009

Re: gdi32/tests: simplify testcase

by André Hentschel

Paul Vriens schrieb: > On 11/17/2009 05:14 PM, André Hentschel wrote: >> + for(i=0;i<sizeof(TestName)/sizeof(TestName[0]);i++) >> + { >> + lstrcpyA(lf.lfFaceName, TestName[i]); > > Hi André, > > Even though it would slightly change the size of the patch, I wouldn't > mind some indentation here (and it would be more in line with the style > of the file). > > You should also try to keep with the current style in that file (meaning > a space after the semi-colon) with respect to the for() statement. > Of course you are right! Thanks -- Best Regards, André Hentschel

Nov. 17, 2009

Re: today's git broke winetricks gecko :-(

by Vincent Povirk

On Tue, Nov 17, 2009 at 9:54 AM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > There's a lot of talk about the new Gecko requirement. At the end of the > day, adding the .cab file to a binary distribution was a trivial 10 minute > exercise. It took another 20 minutes to test everything and figure out that > the wiki page was wrong and the .cab file needs to go in > $PREFIX/share/wine/gecko NOT in $PREFIX/share/gecko. The wiki page is now > fixed, so it really should be trivial to add the gecko runtime to most > binary distributions. While I am much less annoyed now that things are working, I'd still like to see an option for specifying the .cab file path at run time, and for disabling the dialog completely. Maybe I'll write some patches. And apparently the difficult build process is being worked on but is a hard problem to solve, so I'm satisfied with that. It's good to know there aren't any real closed-source components needed to build, just unusual versions / changes to open-source components. It sounds like the the unusual version requirements and hacks are mostly the result of bugs in other projects that are tracked in their bug trackers, and of the need to build a PE gecko on Linux rather than a winelib gecko (which is itself needed because of the difficult build process, which is because of bugs in other projects). Is this accurate? -- Vincent Povirk

Nov. 17, 2009