March 2008 - Wine-Devel - list.winehq.org

Tests marked as todo are not displayed on the web results.
by Reece Dunn March 26, 2008

March 26, 2008

Hi, If you look at the output for a set of test results (e.g. http://test.winehq.org/data/200803181000/) it indicates whether particular tests need work on Wine. This is a great addition and works very well... however, if you navigate to the information about that test (e.g. http://test.winehq.org/data/200803181000/wine_xp_0.9.57-274-g5e463ac/gdiplu…) you don't see what tests are marked as todo. For example, using the above, it results in: gdiplus:graphicspath start dlls/gdiplus/tests/graphicspath.c 1.13 graphicspath: 198 tests executed (5 marked as todo, 0 failures), 0 skipped. gdiplus:graphicspath done (0) ...so does not tell me which of the 5 tests are todo and which are ok. I haven't checked to see if this is also an issue with the `make test` output. - Reece

2 1

Re: gdi32: PlgBlt implementation
by Michael Stefaniuc March 26, 2008

March 26, 2008

Hello Nikolay, thanks for the patch. Nikolay Sivov wrote: > Changelog: > gdi32: initial implementation using coord transformation and MaskBlt > patch is made in Windows using TortoiseCVS functionality (all that > I can use at this moment, shouldn't be a problem I hope) No that's not a problem as long as you do the cvs diff from the top level wine directory. Please do not use C++ style comments but the traditional /* */. bye michael > > Index: bitblt.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi32/bitblt.c,v > retrieving revision 1.4 > diff -u -r1.4 bitblt.c > --- bitblt.c 18 Sep 2007 10:32:56 -0000 1.4 > +++ bitblt.c 26 Mar 2008 21:19:31 -0000 > @@ -26,6 +26,9 @@ > #include "gdi_private.h" > #include "wine/debug.h" > > +#include <math.h> > +#include <float.h> > + > WINE_DEFAULT_DEBUG_CHANNEL(bitblt); > > > @@ -522,9 +525,72 @@ > * > */ > BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint, > - HDC hdcSrc, INT nXDest, INT nYDest, INT nWidth, > + HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth, > INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask) > { > - FIXME("PlgBlt, stub\n"); > - return 1; > + //save actual mode, set GM_ADVANCED > + int oldgMode = SetGraphicsMode(hdcDest,GM_ADVANCED); > + if (oldgMode == 0) > + return FALSE; > + > + //parallelogram coords > + POINT plg[3]; > + memcpy(plg,lpPoint,sizeof(POINT)*3); > + //rect coords > + POINT rect[3]; > + rect[0].x = nXSrc; > + rect[0].y = nYSrc; > + rect[1].x = nXSrc + nWidth; > + rect[1].y = nYSrc; > + rect[2].x = nXSrc; > + rect[2].y = nYSrc + nHeight; > + //calc XFORM matrix to transform hdcDest -> hdcSrc (parallelogram > to rectangle) > + XFORM xf; > + //determinant > + FLOAT det = (FLOAT)(rect[1].x*(rect[2].y - rect[0].y) - > rect[2].x*(rect[1].y - rect[0].y) - rect[0].x*(rect[2].y - rect[1].y)); > + > + if (fabs(det) < FLT_EPSILON) > + { > + SetGraphicsMode(hdcDest,oldgMode); > + return FALSE; > + } > + > + TRACE("hdcSrc=%p %d,%d,%dx%d -> hdcDest=%p %d,%d,%d,%d,%d,%d\n", > + hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hdcDest, plg[0].x, > plg[0].y, plg[1].x, plg[1].y, plg[2].x, plg[2].y); > + > + //X components > + xf.eM11 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - > rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; > + xf.eM21 = (rect[1].x*(plg[2].x - plg[0].x) - rect[2].x*(plg[1].x - > plg[0].x) - rect[0].x*(plg[2].x - plg[1].x)) / det; > + xf.eDx = (rect[0].x*(rect[1].y*plg[2].x - rect[2].y*plg[1].x) - > + rect[1].x*(rect[0].y*plg[2].x - rect[2].y*plg[0].x) + > + rect[2].x*(rect[0].y*plg[1].x - rect[1].y*plg[0].x) > + ) / det; > + > + //Y components > + xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y - > rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det; > + xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - > rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det; > + xf.eDy = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) - > + rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) + > + rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y) > + ) / det; > + > + XFORM SrcXf; > + GetWorldTransform(hdcSrc,&SrcXf); > + CombineTransform(&xf,&xf,&SrcXf); > + > + //save actual dest transform > + XFORM oldDestXf; > + GetWorldTransform(hdcDest,&oldDestXf); > + // > + SetWorldTransform(hdcDest,&xf); > + //now destination and source DCs use same coords > + MaskBlt(hdcDest,nXSrc,nYSrc,nWidth,nHeight, > + hdcSrc, nXSrc,nYSrc, > + hbmMask,xMask,yMask, > + SRCCOPY); > + //restore dest DC > + SetWorldTransform(hdcDest,&oldDestXf); > + SetGraphicsMode(hdcDest,oldgMode); > + > + return TRUE; > } > > >

2 1

dlls/user32/tests/cursoricon.c - test succeeded inside todo block
by Lei Zhang March 26, 2008

March 26, 2008

Anyone else seeing this? ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so cursoricon.c && touch cursoricon.ok cursoricon.c:656: Test succeeded inside todo block: No hbmColor! make: *** [cursoricon.ok] Error 1

2 1

Trouble in compiling Wine 0.9.57 and 0.9.58 on Solaris 10 08/07
by Новиков Роман Константи нович March 26, 2008

March 26, 2008

Hi guys! I've got some trouble with compiling Wine 0.9.57 & 0.9.58 on Solaris 10 08/07 After 40 minutes of the compilation the process halted with messages: wined3d_private.h: In function `float_32_to_16': wined3d_private.h:159: warning: implicit declaration of function `isinf' wined3d_main.c: At top level: wined3d_main.c:271: warning: visibility attribute not supported in this configuration; ignored (the last string repeated for many times) I suppose the situation is connected with Solaris 'isinf' but I am too far from programming under UNIX... My version of gcc is 3.4.3 (Solaris native): bash-3.00# gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) My configure string is: ./configure --enable-win64 --with-x --x-includes=/usr --x-libraries=/usr I built successfully Wine 0.9.56 and earlier.. What can I do with this? Thanks in advance. Rome

2 1

Can't determine disk space, install fails
by Pavel Troller March 26, 2008

March 26, 2008

Hi! We have a long-persisting problem there. It persists for many wine versions and prevents some programs from installing. As an example, today my son complained about impossibility to install WoW. The installer was not able to determine the free space on the disk (there was a dash instead of a number in the box) and the Continue button was greyed out, so it was not possible to proceed. There are other cases, in which the installers say that there is not enough space on the disk and fail. Of course there is enough space, but the installer is not able to find it. Especially WoW has Gold rating and these problems are not mentioned, so I don't think that this is a common wine problem, thus I'm not going to open a bug for it. I'm begging for a hint instead, what to try to find the cause of the problem. Wine is always manually compiled and it runs on a "generic Linux system", not on any particular, publicly known distro. With regards, Pavel Troller

3 3

Re: [PATCH 1 of 2] explorer: add /startfile switch for starting files from file managers
by Alexandre Julliard March 26, 2008

March 26, 2008

"Vincent Povirk" <madewokherd+d41d(a)gmail.com> writes: > My last attempt created a new winelib program; apparently this > functionality fits in explorer. start.exe is probably more appropriate. Either way you are trying to make it too smart; it should take a straight Unix path, and not try to guess anything. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [2/2] comctl32: tab.c The Item Interior should use HotTracking color not Hilight color (resend).
by Alexandre Julliard March 26, 2008

March 26, 2008

Anatoly Lyutin <vostok(a)etersoft.ru> writes: > @@ -1633,7 +1633,7 @@ TAB_DrawItemInterior(const TAB_INFO *inf > SetTextColor(hdc, (((lStyle & TCS_HOTTRACK) && (iItem == infoPtr->iHotTracked) > && !(lStyle & TCS_FLATBUTTONS)) > | (TAB_GetItem(infoPtr, iItem)->dwState & TCIS_HIGHLIGHTED)) ? > - comctl32_color.clrHighlight : comctl32_color.clrBtnText); > + comctl32_color.clrHotTrackingColor : comctl32_color.clrBtnText); Shouldn't you distinguish between TCS_HOTTRACK and TCIS_HIGHLIGHTED here? -- Alexandre Julliard julliard(a)winehq.org

2 1

Google Summer of Code - Case Insensitive Filenames
by Cesar Izurieta March 26, 2008

March 26, 2008

Hello everyone, I would like to participate in this year's google summer of code doing some work on case insensitive filenames ( http://wiki.winehq.org/CaseInsensitiveFilenames ) I have some experience working with FUSE ( see http://code.google.com/p/dejumble/ ). Is there any formal process I must go through to enter google summer of code for wine? Thanks. Cesar Izurieta

6 14

Re: kernel32: WideCharToMultiByte: return error on negative dest len (take 2)
by Alexandre Julliard March 26, 2008

March 26, 2008

"Dan Kegel" <dank(a)kegel.com> writes: > While investigating a crash in gs-auftrag in bug 9039, noticed > WideCharToMultiByte wasn't quite conformant for negative destlen. > Fixed, with tests. Passes for me in Wine and Win XP. This would require reviewing all uses of WideCharToMultiByte in Wine, many places get this wrong. Unless you have an app that requires this fix I'd suggest to leave the test as todo_wine for now. -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: wininet: Implement chunked reads.
by Robert Shearman March 26, 2008

March 26, 2008

Hans Leidekker wrote: > static DWORD HTTPREQ_ReadFile(WININETHANDLEHEADER *hdr, void *buffer, DWORD size, DWORD *read) > { > WININETHTTPREQW *req = (WININETHTTPREQW*)hdr; > + static WCHAR encoding[20]; > + DWORD buflen = sizeof(encoding); > + static const WCHAR szChunked[] = {'c','h','u','n','k','e','d',0}; > encoding shouldn't be static. -- Rob Shearman

1 0