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

Re: wine is passing make test again :-)

by Juan Lang

> Frankly, I'm a bit surprised and disappointed to see that people are not > taking responsibility for fixing failures they introduced in tests. I don't > expect to have time to clean up after them for the next month or so. Hopefully, if we can get the tests passing as a more normal occurrence, we can make not introducing new failures a stronger requirement than it already is. --Juan

Feb. 14, 2011

Re: wine is passing make test again :-)

by Greg Geldorp

> From: Andre Hentschel > and now without the 9x stuff the result page looks better again, someone > just need to fix his user32 test :) Frankly, I'm a bit surprised and disappointed to see that people are not taking responsibility for fixing failures they introduced in tests. I don't expect to have time to clean up after them for the next month or so. Greg.

Feb. 14, 2011

Re: kernel32/process: Add stderr redirection for native linux programs started from windows program

by Stefan Leichter

Am Montag 14 Februar 2011, 07:13:21 schrieb Igor Egorov: > A week ago I submitted a patch for stderr redirection > (http://www.winehq.org/pipermail/wine-patches/2011-February/098578.html) > is there still something wrong with it? Will it be accepted? If you look at http://source.winehq.org/patches/ you will notice that the patch is still in status NEW. That means that AJ did not have a closer look on the patch. Bye Stefan

Feb. 14, 2011

Re: Austin English : shell32/tests: Don't check return values inside of if(0) ( LLVM/Clang).

by Michael Stefaniuc

Charles, Charles Davis wrote: > Austin, > > Static analyzer checks for unreachable assignments (like the ones that > were removed in this patch) were turned off in Clang trunk recently (as > of r125415). Looks like Clang was wrong ;). the ones that Austin removed are still pointless. The code is there to document the crashing function call. And a crashing function call has no return value ;) bye michael

Feb. 14, 2011

Re: Austin English : shell32/tests: Don't check return values inside of if(0) ( LLVM/Clang).

by Charles Davis

Austin, Static analyzer checks for unreachable assignments (like the ones that were removed in this patch) were turned off in Clang trunk recently (as of r125415). Looks like Clang was wrong ;). Chip

Feb. 14, 2011

[PATCH] Implement software DXT1 compression

by alberto＠mattea.info

This patch adds conversion functions from WINED3DFMT_B8G8R8_UNORM, WINED3DFMT_B5G5R5A1_UNORM and WINED3DFMT_B5G5R5X1_UNORM to WINED3DFMT_DXT1. It uses code slighty modified from libtxc_dxtn. It fixes at least LEGO Stunt Rally, probably other games too. I didn't implement dxt3 and dxt5 since I haven't got any apps to test, but if someone has similar problems (black textures) with them and wants to test, let me know, and I will add them as well. I would also like some feedback about the patent situation, e.g. if the patch can be mainlined as it is or if it would be better to load libtxc_dxtn directly at runtime. Alberto

Feb. 14, 2011

Re: winex11.drv: Add PS_USERSTYLE support to pens

by Vitaliy Margolen

On 02/14/2011 03:55 AM, Daniel wrote: > Hello all. This only covers the screen. Support still needs to be added > to printers. > + case PS_USERSTYLE: { > + for(i = 0; i < physDev->pen.dash_len ; i++) { Please follow file style - curly braces on separate line. No braces for single line blocks. > + /* Should be limited to 16 or less */ > + char x11_user_style[16]; > + physDev->pen.dash_len = user_style_size > 16 ? 16 : user_style_size; Should use MAX_DASHLEN instead of magic numbers. Could use "min()" for simplicity. > + x11_user_style[i] = (char)(user_style[i] > 255 ? 255 : user_style[i]); Why not copy directly into physDev->pen.dashes? No need for typecast - it's done automatically. Vitaliy.

Feb. 14, 2011

Re: kernel32: Implement and test GetVolumePathNamesForVolumeName.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > BOOL WINAPI GetVolumePathNamesForVolumeNameW(LPCWSTR volumename, LPWSTR volumepathname, DWORD buflen, PDWORD returnlen) > { > - FIXME("(%s, %p, %d, %p), stub!\n", debugstr_w(volumename), volumepathname, buflen, returnlen); > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return FALSE; > + static const WCHAR prefixW[] = > + {'\\','\\','?','\\','V','o','l','u','m','e','{','0','0','0','0','0','0','0','0','-','0','0','0','0','-', > + '0','0','0','0','-','0','0','0','0','-','0','0','0','0','0','0','0','0','0','0'}; > + static const WCHAR fmtW[] = {'%','c',':','\\',0}; > + > + TRACE("%s, %p, %u, %p\n", debugstr_w(volumename), volumepathname, buflen, returnlen); > + > + if (!volumename || strlenW( volumename ) != 49 || > + volumename[47] != '}' || memcmp( volumename, prefixW, sizeof(prefixW) )) > + { > + SetLastError( ERROR_INVALID_NAME ); > + return FALSE; > + } > + if (returnlen) > + { > + *returnlen = 5; > + } > + if (buflen < 5 || !volumepathname) > + { > + SetLastError( ERROR_MORE_DATA ); > + return FALSE; > + } > + sprintfW( volumepathname, fmtW, strtolW( volumename + 45, NULL, 16 ) ); > + volumepathname[4] = 0; > + return TRUE; Please don't make assumption about volume guids. This should be implemented by retrieving the correct data from mountmgr. -- Alexandre Julliard julliard(a)winehq.org

Feb. 14, 2011

Re: [1/4] mshtml: Ignore IActiveScript interface for IXMLHTTPRequest (resend)

by Jacek Caban

On 2/14/11 10:03 AM, Alistair Leslie-Hughes wrote: > Changelog: > mshtml: Ignore IActiveScript interface for IXMLHTTPRequest mshtml? + else if ( IsEqualGUID( riid,&IID_IActiveScript)) + { + TRACE("(%p)->(IID_IActiveScript %p) returning NULL\n", This, ppvObject); + *ppvObject = NULL; + return E_NOINTERFACE; + } else { FIXME("Unsupported interface %s\n", debugstr_guid(riid)); As discussed on wine-devel, please just change the later FIXME to TRACE instead. Jacek

Feb. 14, 2011

Re: [4/4] mshtml: Add IDispatchEx support to IXMLHTTPRequest

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=9250 Your paranoid android. === W2KPROSP4 (32 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002 === WXPPROSP3 (32 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002 === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002 === WVISTAADM (32 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002 === W2K8SE (32 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002 === W7PRO (32 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002 === W7PROX64 (32 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002 === W7PROX64 (64 bit domdoc) === domdoc.c:3449: Test failed: ret 80004002

Feb. 14, 2011

kernel32/process: Add stderr redirection for native linux programs started from windows program

by Igor Egorov

A week ago I submitted a patch for stderr redirection (http://www.winehq.org/pipermail/wine-patches/2011-February/098578.html) is there still something wrong with it? Will it be accepted?

Feb. 14, 2011

Re: D3DXCreateTorus patch... thoughts?

by David Adam

Here is cool link to show what D3DXCreateTorus does: http://www.xmission.com/~legalize/book/snippets/rt_D3DXSphere.zip A+ David

Feb. 13, 2011

Re: wine is passing make test again :-)

by Austin English

2011/2/13 André Hentschel <nerv(a)dawncrow.de>: > Am 08.02.2011 08:14, schrieb Austin English: >> Looks like Jacek and Gentoo have the magic combination. It's passed 4 >> days in a row: >> http://test.winehq.org/data/ae3e768a2e1f9c21b355798c8fbf473db3d83434/wine_j… >> http://test.winehq.org/data/bf640445c748b0588616da201e8ff8f3b1c778e9/wine_j… >> http://test.winehq.org/data/780f9b3b4fe8ff17784860a2a65b4ecab268436a/wine_j… >> http://test.winehq.org/data/745a50c9dbb03d37db58ff53136e93f00943bc0d/wine_j… >> >> now let's see if we can spread the love to someone else :-). >> > > fg-deb64-win32 once passed reliably, so we should start here. > and now without the 9x stuff the result page looks better again, someone just need to fix his user32 test :) Yeah, a few machines have passed reliably before. My ubuntu machine used to pass as well, and is close aside from two bugs: http://bugs.winehq.org/show_bug.cgi?id=20604 http://bugs.winehq.org/show_bug.cgi?id=25284 -- -Austin

Feb. 13, 2011

D3DXCreateTorus patch... thoughts?

by Misha Koshelev

This is for http://bugs.winehq.org/show_bug.cgi?id=23930 Based on my prior mesh patches. Test bot reports success: https://testbot.winehq.org/JobDetails.pl?Key=9240 Thank you Misha

Feb. 13, 2011

Re: gdi32/dib.c: Write true bitmap height into info and copy scanlines in the correct order.

by Jack Edmonds

Sorry about that. I added the newlines in my latest patch. Thanks for telling me. On Feb 8, 2011 4:22 AM, "Nicolas Le Cam" <niko.lecam(a)gmail.com> wrote: > 2011/2/8 Jack Edmonds <jack(a)jack-desktop.> > >> Fixes bug 25698 and addresses one of the test cases in bug 24278 (possibly >> resolves bug 24278 but more testing is required to be sure). >> >> dib.c: Fills BITMAPINFOHEADER with correct width and height when bits == >> NULL and copying from a top-to-bottom bitmap. >> For top-to-bottom bitmaps, reverses the source pointer rather than the >> destination pointer. >> Ignoring the case when both source and destination are top-to-bottom >> bitmaps and treating this as if the destination is only a top-to-bottom >> bitmap. >> --- >> dlls/gdi32/dib.c | 113 >> ++++++++++++++++++++++++--------------------- >> dlls/gdi32/tests/bitmap.c | 112 >> ++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 173 insertions(+), 52 deletions(-) >> >> diff --git a/dlls/gdi32/dib.c b/dlls/gdi32/dib.c >> index 5067e49..bf7a525 100644 >> --- a/dlls/gdi32/dib.c >> +++ b/dlls/gdi32/dib.c >> @@ -636,54 +636,6 @@ INT WINAPI GetDIBits( >> >> switch (bpp) >> { >> - case 0: /* query bitmap info only */ >> - if (core_header) >> - { >> - BITMAPCOREHEADER* coreheader = (BITMAPCOREHEADER*) info; >> - coreheader->bcWidth = bmp->bitmap.bmWidth; >> - coreheader->bcHeight = bmp->bitmap.bmHeight; >> - coreheader->bcPlanes = 1; >> - coreheader->bcBitCount = bmp->bitmap.bmBitsPixel; >> - } >> - else >> - { >> - info->bmiHeader.biWidth = bmp->bitmap.bmWidth; >> - info->bmiHeader.biHeight = bmp->bitmap.bmHeight; >> - info->bmiHeader.biPlanes = 1; >> - info->bmiHeader.biSizeImage = >> - DIB_GetDIBImageBytes( bmp->bitmap.bmWidth, >> - bmp->bitmap.bmHeight, >> - bmp->bitmap.bmBitsPixel ); >> - if (bmp->dib) >> - { >> - info->bmiHeader.biBitCount = bmp->dib->dsBm.bmBitsPixel; >> - switch (bmp->dib->dsBm.bmBitsPixel) >> - { >> - case 16: >> - case 32: >> - info->bmiHeader.biCompression = BI_BITFIELDS; >> - break; >> - default: >> - info->bmiHeader.biCompression = BI_RGB; >> - break; >> - } >> - } >> - else >> - { >> - info->bmiHeader.biCompression = (bmp->bitmap.bmBitsPixel > >> 8) ? BI_BITFIELDS : BI_RGB; >> - info->bmiHeader.biBitCount = bmp->bitmap.bmBitsPixel; >> - } >> - info->bmiHeader.biXPelsPerMeter = 0; >> - info->bmiHeader.biYPelsPerMeter = 0; >> - info->bmiHeader.biClrUsed = 0; >> - info->bmiHeader.biClrImportant = 0; >> - >> - /* Windows 2000 doesn't touch the additional struct members if >> - it's a BITMAPV4HEADER or a BITMAPV5HEADER */ >> - } >> - lines = abs(bmp->bitmap.bmHeight); >> - goto done; >> - >> case 1: >> case 4: >> case 8: >> @@ -877,10 +829,10 @@ INT WINAPI GetDIBits( >> LPBYTE dbits = bits, sbits = (LPBYTE) bmp->dib->dsBm.bmBits + >> (startscan * srcwidthb); >> unsigned int x, y, width, widthb; >> >> - if ((height < 0) ^ (bmp->dib->dsBmih.biHeight < 0)) >> + if (bmp->dib->dsBmih.biHeight < 0) >> { >> - dbits = (LPBYTE)bits + (dstwidthb * (lines-1)); >> - dstwidthb = -dstwidthb; >> + sbits += (srcwidthb * (abs(bmp->dib->dsBmih.biHeight) - >> startscan - 1)); >> + srcwidthb = -srcwidthb; >> } >> >> switch( bpp ) { >> @@ -1086,7 +1038,64 @@ INT WINAPI GetDIBits( >> } >> } >> } >> - else lines = abs(height); >> + else /* query bitmap info only */ >> + { >> + if (core_header) >> + { >> + BITMAPCOREHEADER* coreheader = (BITMAPCOREHEADER*) info; >> + if (bmp->dib) >> + { >> + coreheader->bcWidth = bmp->dib->dsBmih.biWidth; >> + coreheader->bcHeight = bmp->dib->dsBmih.biHeight; >> + } >> + else >> + { >> + coreheader->bcWidth = bmp->bitmap.bmWidth; >> + coreheader->bcHeight = bmp->bitmap.bmHeight; >> + } >> + coreheader->bcPlanes = 1; >> + coreheader->bcBitCount = bmp->bitmap.bmBitsPixel; >> + } >> + else >> + { >> + if (bmp->dib) >> + { >> + info->bmiHeader.biHeight = bmp->dib->dsBmih.biHeight; >> + info->bmiHeader.biWidth = bmp->dib->dsBmih.biWidth; >> + info->bmiHeader.biBitCount = bmp->dib->dsBm.bmBitsPixel; >> + switch (bmp->dib->dsBm.bmBitsPixel) >> + { >> + case 16: >> + case 32: >> + info->bmiHeader.biCompression = BI_BITFIELDS; >> + break; >> + default: >> + info->bmiHeader.biCompression = BI_RGB; >> + break; >> + } >> + } >> + else >> + { >> + info->bmiHeader.biWidth = bmp->bitmap.bmWidth; >> + info->bmiHeader.biHeight = bmp->bitmap.bmHeight; >> + info->bmiHeader.biCompression = (bmp->bitmap.bmBitsPixel > >> 8) ? BI_BITFIELDS : BI_RGB; >> + info->bmiHeader.biBitCount = bmp->bitmap.bmBitsPixel; >> + } >> + info->bmiHeader.biPlanes = 1; >> + info->bmiHeader.biSizeImage = >> + DIB_GetDIBImageBytes( bmp->bitmap.bmWidth, >> + bmp->bitmap.bmHeight, >> + bmp->bitmap.bmBitsPixel ); >> + info->bmiHeader.biXPelsPerMeter = 0; >> + info->bmiHeader.biYPelsPerMeter = 0; >> + info->bmiHeader.biClrUsed = 0; >> + info->bmiHeader.biClrImportant = 0; >> + >> + /* Windows 2000 doesn't touch the additional struct members if >> + it's a BITMAPV4HEADER or a BITMAPV5HEADER */ >> + } >> + lines = abs(bmp->bitmap.bmHeight); >> + } >> >> /* The knowledge base article Q81498 ("DIBs and Their Uses") states >> that >> if bits == NULL and bpp != 0, only biSizeImage and the color table >> are >> diff --git a/dlls/gdi32/tests/bitmap.c b/dlls/gdi32/tests/bitmap.c >> index d0d7a9c..a76d437 100644 >> --- a/dlls/gdi32/tests/bitmap.c >> +++ b/dlls/gdi32/tests/bitmap.c >> @@ -3050,6 +3050,116 @@ static void test_32bit_bitmap_blt(void) >> DeleteDC(hdcScreen); >> } >> >> +static void test_GetDIBits_info_query(void) >> +{ >> + BITMAPINFO bi; >> + HBITMAP bmp; >> + HDC hdc; >> + int *picture; >> + >> + hdc = GetDC(NULL); >> + >> + bi.bmiHeader.biSize=sizeof(bi.bmiHeader); >> + bi.bmiHeader.biWidth=2; >> + bi.bmiHeader.biHeight=2; >> + bi.bmiHeader.biPlanes=1; >> + bi.bmiHeader.biBitCount=32; >> + bi.bmiHeader.biCompression=BI_RGB; >> + bmp = CreateDIBSection(hdc, &bi, DIB_RGB_COLORS, (void**)&picture, >> NULL, 0); >> + /*Clear the structure to make sure that we really are testing that the >> structure is being written to.*/ >> + memset(&bi, 0, sizeof(bi)); >> + /*Test with a BITMAPINFOHEADER.*/ >> + bi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); >> + GetDIBits(hdc, bmp, 0, 0, NULL, &bi, DIB_RGB_COLORS); >> + ok(bi.bmiHeader.biHeight == 2, "Height should be 2."); >> + ok(bi.bmiHeader.biWidth == 2, "Width should be 2."); >> + /*Clear the structure to make sure that we really are testing that the >> structure is being written to.*/ >> + memset(&bi, 0, sizeof(bi)); >> + /*Now test with a BITMAPCOREHEADER.*/ >> + bi.bmiHeader.biSize=sizeof(BITMAPCOREHEADER); >> + GetDIBits(hdc, bmp, 0, 0, NULL, &bi, DIB_RGB_COLORS); >> + ok(((BITMAPCOREHEADER*)&bi)->bcHeight == 2, "Height should be 2."); >> + ok(((BITMAPCOREHEADER*)&bi)->bcWidth == 2, "Width should be 2."); >> + /*Clean up.*/ >> + DeleteObject(bmp); >> + >> + /*Test top to bottom bitmap.*/ >> + bi.bmiHeader.biSize=sizeof(bi.bmiHeader); >> + bi.bmiHeader.biWidth=2; >> + bi.bmiHeader.biHeight=-2; >> + bi.bmiHeader.biPlanes=1; >> + bi.bmiHeader.biBitCount=32; >> + bi.bmiHeader.biCompression=BI_RGB; >> + bmp = CreateDIBSection(hdc, &bi, DIB_RGB_COLORS, (void**)&picture, >> NULL, 0); >> + /*Clear the structure to make sure that we really are testing that the >> structure is being written to.*/ >> + memset(&bi, 0, sizeof(bi)); >> + /*Test with a BITMAPINFOHEADER.*/ >> + bi.bmiHeader.biSize=sizeof(BITMAPINFOHEADER); >> + GetDIBits(hdc, bmp, 0, 0, NULL, &bi, DIB_RGB_COLORS); >> + ok(bi.bmiHeader.biHeight == -2, "Height should be -2."); >> + ok(bi.bmiHeader.biWidth == 2, "Width should be 2."); >> + /*Clear the structure to make sure that we really are testing that the >> structure is being written to.*/ >> + memset(&bi, 0, sizeof(bi)); >> + /*Now test with a BITMAPCOREHEADER.*/ >> + bi.bmiHeader.biSize=sizeof(BITMAPCOREHEADER); >> + GetDIBits(hdc, bmp, 0, 0, NULL, &bi, DIB_RGB_COLORS); >> + ok(((BITMAPCOREHEADER*)&bi)->bcHeight == (WORD)-2, "Height should be >> -2."); >> + ok(((BITMAPCOREHEADER*)&bi)->bcWidth == (WORD)2, "Width should be >> 2."); >> + /*Clean up.*/ >> + DeleteObject(bmp); >> +} >> + >> +static void test_GetDIBits_single_pixel_destination(void) >> +{ >> + BITMAPINFO bi; >> + HBITMAP bmptb, bmpbt; >> + HDC hdc; >> + int pixelOut; >> + int *picture; >> + bi.bmiHeader.biSize=sizeof(bi.bmiHeader); >> + bi.bmiHeader.biWidth=2; >> + bi.bmiHeader.biHeight=2; >> + bi.bmiHeader.biPlanes=1; >> + bi.bmiHeader.biBitCount=32; >> + bi.bmiHeader.biCompression=BI_RGB; >> + >> + /*Get the device context for the screen.*/ >> + hdc=GetDC(NULL); >> + >> + /*Create the bottom to top image (image's bottom scan line is at the >> top in memory).*/ >> + bmpbt=CreateDIBSection(hdc, &bi, DIB_RGB_COLORS, (void**)&picture, >> NULL, 0); >> + /*Now that we have a pointer to the pixels, we write to them.*/ >> + picture[0]=1; >> + picture[1]=2; >> + picture[2]=3; >> + picture[3]=4; >> + /*Create the top to bottom image (images' bottom scan line is at the >> bottom in memory).*/ >> + bi.bmiHeader.biHeight=-2; /*We specify that we want a top to bottom >> image by specifying a negative height.*/ >> + bmptb=CreateDIBSection(hdc, &bi, DIB_RGB_COLORS, (void**)&picture, >> NULL, 0); >> + /*Write to this top to bottom bitmap.*/ >> + picture[0]=1; >> + picture[1]=2; >> + picture[2]=3; >> + picture[3]=4; >> + >> + bi.bmiHeader.biWidth=1; >> + >> + bi.bmiHeader.biHeight=2; >> + GetDIBits(hdc, bmpbt, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS); >> + ok(pixelOut==1, "Bottom-up -> bottom-up should have first scanline."); >> + GetDIBits(hdc, bmptb, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS); >> + ok(pixelOut==3, "Top-down -> bottom-up should have last scanline."); >> + >> + bi.bmiHeader.biHeight=-2; >> + GetDIBits(hdc, bmpbt, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS); >> + ok(pixelOut==1, "Bottom-up -> top-down should have first scanline."); >> + GetDIBits(hdc, bmptb, 0, 1, &pixelOut, &bi, DIB_RGB_COLORS); >> + ok(pixelOut==3, "Top-down -> top-down should have last scanline."); >> + >> + DeleteObject(bmpbt); >> + DeleteObject(bmptb); >> +} >> + >> START_TEST(bitmap) >> { >> HMODULE hdll; >> @@ -3080,4 +3190,6 @@ START_TEST(bitmap) >> test_bitmapinfoheadersize(); >> test_get16dibits(); >> test_clipping(); >> + test_GetDIBits_single_pixel_destination(); >> + test_GetDIBits_info_query(); >> } >> -- >> 1.7.1 >> >> >> >> > Hi Jack, > > You forgot trailing \n in the ok() calls. > > -- > Nicolas Le Cam

Feb. 13, 2011

Re: comctl32/tests: Add two casts to avoid comparisons of differentint types.

by Janne Hakonen

> Hmm, looking at this my patch changes > > ok(*(ULONG_PTR*)g_drawitem.itemData == lparam, > "got %lx, expected %lx\n", gdrawitem.itemData, lparam); > > to > > ok(*(ULONG_PTR*)g_drawitem.itemData == (ULONG)lparam, > "got %lx, expected %lx\n", g_drawitem.itemData, lparam); > > That is, the only difference is the (ULONG) cast. Given the output above, > my patch did not trigger this failure since based on the printing of the > two values they are different. Actually, now with your change you are comparing ULONG_PTR to ULONG. With 64 bit binary the left side of comparison is a 64 bit pointer and right side is 32 bit value. Best Regards, Janne Hakonen

Feb. 13, 2011

Re: Wine and Summer of Code 2011

by Jacek Caban

On 2/8/11 7:04 PM, Dan Kegel wrote: > And can y'all think of any fresh ideas for the suggested projects list How about implementing wscript builtin script API? > or ideas that should be retired? - Wine IE GUI Its easy parts are mostly already implemented in hacky way. Further work requires improving underlying libraries, which probably is not something for GSoC. - Improving HTML Help viewer Its GUI is mostly implemented. APIs to control it are mostly stub, but I don't think it's a good GSoC project. It requires at least rewriting description. - Implementing CHM compiler It looks like time would be better spent improving chmc. Jacek

Feb. 13, 2011

Re: vblank timestamps and page flipping in DRI2

by Stefan Dösinger

Am Sonntag 13 Februar 2011, 18:33:48 schrieb Saulius Krasuckas: > There are some news on the $Subject: [1]. > (have a look at the chapter "Fine tuned") > > I thought it could help Wine fixing such bugs as 6086, 13085, 17260, 22362 The last 3 should be fixed by now, on any driver that implements GLX_EXT_swap_control. Beyond that it isn't wine's job to read those DRM timestamps. Wine uses a standardized interface, and the drivers are supposed to implement it. I don't believe 6086 is related to vsync.

Feb. 13, 2011

vblank timestamps and page flipping in DRI2

by Saulius Krasuckas

There are some news on the $Subject: [1]. (have a look at the chapter "Fine tuned") I thought it could help Wine fixing such bugs as 6086, 13085, 17260, 22362 [2]. I'll paste the text in just for archiving purposes: --- quote --- Fine tuned The kernel hackers have extended the DRM infrastructure to include "precision vblank timestamps", which are explained in detail in the commit comment and are relevant to OpenML (Open Media Library) conformity. This feature enables the kernel to provide timestamps with an accuracy of a few microseconds, allowing applications to detect when the rendering of a new image has started ("double-buffer swap"). This can, for instance, be relevant for applications where it is important to precisely co-ordinate the audio output, or the control of other devices, with the rendering of the image. The technology was first implemented for experimental psychology and neuroscience applications, but it can also be applied to provide (more) jerk-free video playback, animations or desktop effects. Such timestamps can also be utilised by the new page flipping feature available via DRI2. This feature improves the way the kernel synchronises the release of an updated image with the moment the graphics hardware starts rendering the new image (Vsync). Synchronising the release avoids such distortions as flickering, tearing or incomplete rendering, as it prevents situations where one half of a displayed image is part of the old image while the other half is part of the new image . for instance with individual movie frames. In kernel version 38, the graphics driver support required for both features will be available via the AMD drivers (1, 2) and the Intel drivers (1, 2). The NVIDIA drivers currently only support page flipping (1, 2). --- quote --- S. [1] http://www.h-online.com/open/features/Kernel-Log-Coming-in-2-6-38-Part-1-Gr… [2] http://bugs.winehq.org/show_bug.cgi?id=6086 http://bugs.winehq.org/show_bug.cgi?id=13085 http://bugs.winehq.org/show_bug.cgi?id=17260 http://bugs.winehq.org/show_bug.cgi?id=22362

Feb. 13, 2011

Re: wine is passing make test again :-)

by André Hentschel

Am 08.02.2011 08:14, schrieb Austin English: > Looks like Jacek and Gentoo have the magic combination. It's passed 4 > days in a row: > http://test.winehq.org/data/ae3e768a2e1f9c21b355798c8fbf473db3d83434/wine_j… > http://test.winehq.org/data/bf640445c748b0588616da201e8ff8f3b1c778e9/wine_j… > http://test.winehq.org/data/780f9b3b4fe8ff17784860a2a65b4ecab268436a/wine_j… > http://test.winehq.org/data/745a50c9dbb03d37db58ff53136e93f00943bc0d/wine_j… > > now let's see if we can spread the love to someone else :-). > fg-deb64-win32 once passed reliably, so we should start here. and now without the 9x stuff the result page looks better again, someone just need to fix his user32 test :) -- Best Regards, André Hentschel

Feb. 13, 2011

Re: Tiny imap message appender written in perl

by Krzysztof Nikiel

Yes, it works differently from git-imap-send, it takes separate files as input. 2011/2/13 GOUJON Alexandre <ale.goujon(a)gmail.com>: > On 02/13/2011 12:10 PM, Krzysztof Nikiel wrote: >> >> It's a kind of side effect of my Wine patching. >> Sending those patches traditional way was an epic fail. Mail client >> wrapped lines, git-imap-send provided by Debian don't support SSL. >> >> I have modified my tiny imap downloader to append new messages to >> specified box. It uses Net::SSLeay module. >> Maybe it will be useful to someone. > > Have you read > http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 > ? > If you have issues, your patch may be useful there. >

Feb. 13, 2011

Re: Tiny imap message appender written in perl

by GOUJON Alexandre

On 02/13/2011 12:10 PM, Krzysztof Nikiel wrote: > It's a kind of side effect of my Wine patching. > Sending those patches traditional way was an epic fail. Mail client > wrapped lines, git-imap-send provided by Debian don't support SSL. > > I have modified my tiny imap downloader to append new messages to > specified box. It uses Net::SSLeay module. > Maybe it will be useful to someone. Have you read http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 ? If you have issues, your patch may be useful there.

Feb. 13, 2011

Tiny imap message appender written in perl different attachment

by Krzysztof Nikiel

This attachment may be better: #!/usr/bin/perl # SSL IMAP message appender # Copyright (C) 2011 Krzysztof Nikiel use Socket; use Net::SSLeay qw(die_now die_if_ssl_error); Net::SSLeay::load_error_strings(); Net::SSLeay::SSLeay_add_ssl_algorithms(); Net::SSLeay::randomize(); $g_port=993; $g_tag=1; $g_ret=""; if ($#ARGV < 3) { print "usage: $0 server user box pass file1 ...\n", "\tAppends files to the specified IMAP box.\n\n"; exit; } $g_serv=shift @ARGV; $g_user=shift @ARGV; $g_box=shift @ARGV; $g_pass=shift @ARGV; sub imapclient { my $dest_serv, $port, $dest_ip, $dest_serv_params; my $ctx, $res; my $res; my @boxlist; my $boxok = 0; $port = $g_port; $port = getservbyname($port, 'tcp') unless $port =~ /^\d+$/; $dest_ip = gethostbyname($g_serv); $dest_serv_params = sockaddr_in($port, $dest_ip); socket(S, &AF_INET, &SOCK_STREAM, 0) or die "socket: $!"; connect(S, $dest_serv_params) or die "connect: $!"; select(S); $| = 1; select(STDOUT); # The network connection is now open, lets fire up SSL $ctx = Net::SSLeay::CTX_new() or die_now("Failed to create SSL_CTX $!"); $g_ssl = Net::SSLeay::new($ctx) or die_now("Failed to create SSL $!"); Net::SSLeay::set_fd($g_ssl, fileno(S)); # Must use fileno $res = Net::SSLeay::connect($g_ssl); print "Cipher '" . Net::SSLeay::get_cipher($g_ssl) . "'\n"; # IMAP client starts here print "\nconnecting to $g_serv\n"; imapread(); showresp(); unless ($g_ret =~ /^\* OK/) {return}; print "logging in as $g_user\n"; $res = imapcmd("LOGIN $g_user $g_pass"); imapread(); showresp(); print "reading mailbox list\n"; $res = imapcmd("LIST \"\" \*"); imapread(); unless (testresp($g_ret)) { print "LIST failed\n"; goto logout; } #print "list ret: '$g_ret'\n"; @boxlist=(); foreach (split /\n/,$g_ret) { if (/^* LIST [^"]*"[^"]*"[^"]*"([^"]*)"/) { push @boxlist,$1; } } foreach (@boxlist) { print "$_\n"; if ("$_" eq "$g_box") {$boxok = 1} } if (!$boxok) {print "Warning: can't find '$g_box' in mailbox names\n"} foreach (@ARGV) { imapappend("$g_box", $_); } logout: print "logging out\n"; $res = imapcmd("LOGOUT"); imapread(); showresp(); if ($g_ret =~ /^\* BYE/) {print "LOGOUT OK\n"}; do { imapread(); showresp(); } while ($g_ret ne ""); #end of IMAP code shutdown S, 1; # Half close --> No more output, sends EOF to server $res = Net::SSLeay::read($g_ssl); # Perl returns undef on failure print $res; Net::SSLeay::free($g_ssl); # Tear down connection Net::SSLeay::CTX_free($ctx); close S; } sub imapappend { my $res, $resp; my $box = @_[0]; my $file = @_[1]; my @msg = (); print "reading from '$file'..."; if (!open(MSG,"<",$file)) { print "Warning: can't open $file\n"; return; } $size = 0; while(<MSG>) { chomp; push @msg,$_; $size += length; $size += 2; } close MSG; print $#msg + 1, " lines; $size bytes\n"; print "appending to \"$box\"\n"; $res = imapcmd("APPEND \"$box\" {$size}"); imapread(); showresp(); unless ($g_ret =~ /^+/) {return}; foreach (@msg) { $res = sslwrite("$_"); } $res = sslwrite(""); imapread(); showresp(); } sub showresp { print $g_ret; } sub imapread { $g_ret = Net::SSLeay::read($g_ssl); $g_ret =~ s/\r//g; } sub imapcmd { my ($msg) = @_; my $res; $g_tag += 1; return sslwrite("TAG$g_tag $msg"); } sub sslwrite { my ($msg) = @_; my $res; $res = Net::SSLeay::ssl_write_all($g_ssl, "$msg\r\n"); return $res; } sub testresp { if (@_[0] =~ /TAG(\d+) OK/) { if ($1 == $g_tag) {return 1} } return 0; } imapclient();

Feb. 13, 2011

Tiny imap message appender written in perl

by Krzysztof Nikiel

It's a kind of side effect of my Wine patching. Sending those patches traditional way was an epic fail. Mail client wrapped lines, git-imap-send provided by Debian don't support SSL. I have modified my tiny imap downloader to append new messages to specified box. It uses Net::SSLeay module. Maybe it will be useful to someone.

Feb. 13, 2011

Re: winex11.drv: map_window should honor iconic state

by Alexander Lakhin

13.02.2011 00:06, Alexandre Julliard writes: > Alexander Lakhin<exclusion(a)gmail.com> writes: > >> I've checked XWMHints just before XMapWindow call and received the correct initial_state (IconicState) and flags (StateHint set) there. >> But the window still displayed not in a minimized state. To isolate the issue I tried the following code snippet: >> ... >> XWMHints *wm_hints = XAllocWMHints(); >> wm_hints->initial_state = IconicState; >> wm_hints->flags = StateHint; >> XSetWMHints( display, win, wm_hints ); >> >> XMapWindow( display, win ); >> ... >> And the window was not minimized again. After some research I found the following explanation to it: >> http://mail.gnome.org/archives/wm-spec-list/2001-December/msg00020.html > No, this has nothing to do with it. While IconicState can mean different > things for different window managers, it shouldn't make a difference > whether it's set as initial state or changed after the fact. If initial > state is set correctly then the bug is in your window manager. > Hello, Alexandre. Sorry, I was embarassed by the following sentence about the WM_STATE in the Inter-Client Communication Conventions Manual, section 4.1.3.1. "The state field describes the window manager’s idea of the state the window is in, which may not match the client’s idea as expressed in the initial_state field of the WM_HINTS property ..." I thought that "may not" here introduces some ambiguity and allows a window manager to distinct these two properties. But now I understand that it is indeed quirky to differentiate two and it's rather a defect of the window manager than Wine's. (For your information, I use compiz). Thanks for your feedback. Best regards, Alexander

Feb. 13, 2011