- Wine-devel - list.winehq.org

Wine: several warnings in dlls/ntdll/tests/rtlstr.c
by Gerald Pfeifer 27 Dec '02

27 Dec '02

Using GCC 2.95.3 on FreeBSD 4.7 (which has a couple of tests not usually supported by GCC 2.95) I get a couple of warnings due to recent changes/additions in Wine; these warnings seem to indicate real problems: rtlstr.c: In function `test_RtlInitUnicodeString': rtlstr.c:110: warning: implicit declaration of function `wcscmp' rtlstr.c: In function `test_RtlUnicodeStringToInteger': rtlstr.c:147: warning: decimal constant is so large that it is unsigned rtlstr.c:148: warning: decimal constant is so large that it is unsigned rtlstr.c:170: warning: int format, different type arg (arg 3) rtlstr.c:175: warning: int format, different type arg (arg 3) rtlstr.c:176: warning: int format, different type arg (arg 3) rtlstr.c:178: warning: int format, different type arg (arg 3) rtlstr.c:179: warning: int format, different type arg (arg 3) rtlstr.c:181: warning: int format, different type arg (arg 3) rtlstr.c:182: warning: int format, different type arg (arg 3) rtlstr.c:184: warning: int format, different type arg (arg 3) rtlstr.c:185: warning: int format, different type arg (arg 3) Robert, perhaps you could have a look at these? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

3 2

d3d three more renderstates for n2002
by Christoph Frick 27 Dec '02

27 Dec '02

Hi! with one of the last patches from the cvs the game Nascar 2002 now recognizes the d3d rasterizer in the config tool. The patch below adds three more handlers for the D3DRENDERSTATE. As d3d seems to me pretty undocumented i can only try to find things out using goolgle and see the example code there - a link to doku would be really appreciated. Only the D3DRENDERSTATE_CLIPPING stuff seems pretty obvious. I dont have a clue what the EXTEND stuff does and can also only guess what the EDGEANTIALIAS does. I also was not able to test it in the game - the d3d stuff seem to lack a lot of functions this game relies on - i will try to add further functions step by step. The d3d7 code looks pretty bound to mesa - i dont use mesa, so i can not say if this works or not with mesa - only with the opengl provided by nvidia and what the manpages say. RFC and CU! Index: dlls/ddraw/mesa.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/mesa.c,v retrieving revision 1.20 diff -u -r1.20 mesa.c --- dlls/ddraw/mesa.c 24 Dec 2002 01:03:04 -0000 1.20 +++ dlls/ddraw/mesa.c 27 Dec 2002 11:43:32 -0000 @@ -345,6 +345,39 @@ glDisable(GL_LIGHTING); break; + case D3DRENDERSTATE_CLIPPING: + /* enables/disables clipping; get the maximal amount of + * possible clippling planes in this opengl implementation and + * enable/disable em all */ + { + GLint i, maxclipplanes; + glGetIntegerv(GL_MAX_CLIP_PLANES,&maxclipplanes); + for (i=0; i<maxclipplanes; i++) { + if (dwRenderState) { + glEnable(GL_CLIP_PLANE0+i); + } else { + glDisable(GL_CLIP_PLANE0+i); + } + } + } + break; + + case D3DRENDERSTATE_EXTENTS: + /* boolean + * dont have a clue what this does */ + FIXME("What is D3DRENDERSTATE_EXTENTS supposed to do?\n"); + break; + + case D3DRENDERSTATE_EDGEANTIALIAS: + /* in opengl the antialiasing of points, lines and polygons can + * be set separate - assuming this only actives it for polygons */ + if (dwRenderState) { + glEnable(GL_POLYGON_SMOOTH); + } else { + glDisable(GL_POLYGON_SMOOTH); + } + break; + default: ERR("Unhandled dwRenderStateType %s (%08x) !\n", _get_renderstate(dwRenderStateType), dwRender StateType); }

3 2

Re: Standard way of printing RECT in trace statements?
by Dan Kegel 27 Dec '02

27 Dec '02

Francois Gouget wrote: > On Fri, 27 Dec 2002, Dan Kegel wrote: > [...] > >>I thought everyone always left NO_TRACE_MSGS undefined, >>so the rect2a function you favor gets called unconditionally, >>and its output filtered out. > > > No. Look at the TRACE macro again (include/wine/debug.h). The function > will only be called if __WINE_GET_DEBUGGING(dbcl,(dbch)) I stand corrected. Sweet. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

1 0

Standard way of printing RECT in trace statements?
by Dan Kegel 27 Dec '02

27 Dec '02

Dimitrie O. Paun wrote: > Most of the case can be transformed to debugrect(), but that requires > some infrastructure work, so it belongs in a separate patch. I assume you're referring to the routine in listview.c: static inline char* debugrect(const RECT *rect) While that works, it also seems worth considering a macro-based approach. For instance: #define _RECT_FMT "(%ld,%ld)-(%ld,%ld)" #define _RECT_ARG(r) (r).left, (r).top, (r).right, (r).bottom ... Example use: TRACE("Combo client " _RECT_FMT ", setting Edit to " _RECT_FMT "\n", _RECT_ARG(rect), x, y, x + w, y + h); (FWIW, the Linux kernel uses a similar macro, NIPQUAD, to display IP addresses.) Although this doesn't hide things as well as the inline function, it might have some advantage in size and runtime, since it does more of its work at compile time. Either way, having a standard way of inserting values of Windows structures into TRACE statements would probably be nice to have. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

2 2

Re: Listview scroll patch
by Dimitrie O. Paun 27 Dec '02

27 Dec '02

On December 27, 2002 01:18 am, Chris Morgan wrote: > +/* Return the corresponding text for a given scroll value */ > +static inline LPSTR debugscrollcode(int nScrollCode) > +{ > + switch(nScrollCode) > + { > + case SB_LINELEFT: return "SB_LINELEFT"; > + case SB_LINERIGHT: return "SB_LINERIGHT"; > + case SB_PAGELEFT: return "SB_PAGELEFT"; > + case SB_PAGERIGHT: return "SB_PAGERIGHT"; > + case SB_THUMBPOSITION: return "SB_THUMBPOSITION"; > + case SB_THUMBTRACK: return "SB_THUMBTRACK"; > + case SB_ENDSCROLL: return "SB_ENDSCROLL"; > + case SB_INTERNAL: return "SB_INTERNAL"; > + default: return "unknown"; > + } > +} Sorry to be a nag, but please use 4-space indents, like most of the code in there. 2-space indented code is old, and it's a mark for me to look over it, all new code should be 4-space indented. -- Dimi.

1 0

Re: Listview scroll patch
by Dimitrie O. Paun 27 Dec '02

27 Dec '02

On December 26, 2002 04:06 pm, Chris Morgan wrote: > +/* Replace the scroll value with text */ > +#define SCROLL_CODE_TEXT(nScrollCode) \ > + (nScrollCode == SB_LINELEFT) ? "SB_LINELEFT" : (nScrollCode == > SB_LINERIGHT) \ + ? "SB_LINERIGHT" : (nScrollCode == > SB_INTERNAL) ? "SB_INTERNAL" : \ + (nScrollCode == > SB_PAGELEFT) ? "SB_PAGELEFT" : (nScrollCode == \ > + SB_PAGERIGHT) ? "SB_PAGERIGHT" : (nScrollCode == > SB_THUMBPOSITION) ? \ + "SB_THUMBPOSITION" : (nScrollCode == > SB_THUMBTRACK) ? \ + "SB_THUMBTRACK" : \ > + (nScrollCode == SB_ENDSCROLL) ? "SB_ENDSCROLL" \ > + : "unknown" Please do not introduce such macros. I don't really think it's necessary to transform the code to text (it clutters the output), but if you insist on doing it, just do it through a function: static inline LPCSTR debugscrollcode(INT nScrollCode) { ... } This is the pattern used throughout listview.c. But in general speaking, if you can do it without macros, then macros are not the answer. -- Dimi.

2 1

Old scrolling bug
by Duane Clark 27 Dec '02

27 Dec '02

Howdy, Another in my pattern of posting intermediate debugging results here, in case anyone can contribute some insight... Looking into the bug that Dimitrie reported here: http://www.winehq.com/hypermail/wine-devel/2002/09/0748.html Here is what is happening (testing on the Listview Control Spy) when sliding the obscuring window. I changed a bunch of TRACE messages to ERR, and added a few. The window of interest, that the artifacts are appearing in is 0x10039 (the "Control Notifications" window): err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 0,138 11x1 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 304,138 4x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,110 2x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,108 99x1 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,126 293x1 err:win:BeginPaint hwnd 0x10021 hdc = 0x9e8 box = (0,138 - 409,139) err:win:EndPaint Here err:win:BeginPaint hwnd 0x10039 hdc = 0x9e8 box = (0,108 - 99,109) err:win:EndPaint Here err:win:BeginPaint hwnd 0x10040 hdc = 0x9e8 box = (0,0 - 293,186) err:win:EndPaint Here err:win:BeginPaint hwnd 0x10047 hdc = 0x890 box = (0,109 - 277,110) err:win:EndPaint Here So an initial exposure occurred and was almost immediately painted. The obscuring window is now at y=109. The first expose of the pair is a validate, and the second is the invalidate. Then ScrollWindowEx is called, which eventually gets to X11DRV_ScrollDC, where the bitblt that scrolls the window is called. err:bitblt:BitBlt hdcSrc=0x9e8 0,14 24 bpp->hdcDest=0x9e8 0,0 126x154x24 rop=cc0020 After scrolling, X11DRV_EndGraphicsExposures is called, which checks pending exposure events as a result of the scroll. err:x11drv:X11DRV_EndGraphicsExposures got 0,96 99x14 count 0 Note that the exposed part is the rectangle with y coordinates from 96 to 110. That means that before the bitblt copy had occurred, the obscuring window had already moved down one pixel. The bitblt moved the previously obscured rectangle at (0,109 - 99,110) to (0,95 - 99,96), but that rectangle did not get into the update rectangle. This is because the only pending events checked are those that are a direct result of exposure due to the copy in bitblt, and does not include any additional areas that were exposed by sliding the obscuring region. err:scroll:X11DRV_ScrollWindowEx A hwnd 0x10039 rgn rect = (0,96,126,168) err:win:GetUpdateRgn hrgnUpdate 0 err:scroll:X11DRV_ScrollWindowEx B hwnd 0x10039 rgn rect = (0,96,126,168) It should be pointed out that X did not lose the exposure event due to sliding the obscuring window, because here it shows up in the next exposure event err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 0,139 11x1 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 304,139 4x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,111 2x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,109 99x1 ^^^ Unfortunately, we have already handled the offset due to scrolling, so this event is put into the update region unshifted. The remaining exposures are new, so no shifting is needed. err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,127 293x1 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 0,140 11x3 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 304,140 4x3 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,112 2x3 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,110 99x3 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,128 293x3 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 0,143 11x1 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 304,143 4x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,115 2x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,113 99x1 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,131 293x1 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 0,144 11x2 err:x11drv:X11DRV_Expose win 0x10021 (2e00003) 304,144 4x2 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,116 2x2 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,114 99x2 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,132 293x2 err:win:BeginPaint hwnd 0x10021 hdc = 0x890 box = (0,139 - 409,146) err:win:EndPaint Here And finally the update region is painted. This update region includes the region exposed by the scroll, plus all the additional exposure events that occurred due to sliding the obscuring window. err:win:BeginPaint hwnd 0x10039 hdc = 0x890 box = (0,96 - 126,168) err:win:EndPaint Here But there is a one pixel artifact at (0,95 - 99,96), because it is not in the update region. Fundamentally, the problem is that the X events are handled out of order, because X11DRV_EndGraphicsExposures stripped out particular events (due to copying) without accounting for other pending events that might be relevant (plain old exposure).

1 1

Re: glibc 2.3.1 patch
by Dan Kegel 27 Dec '02

27 Dec '02

Ove Kaaven wrote: > The newest glibc in debian unstable, 2.3.1-8, does not seem to want to > export h_errno anymore, which causes a link failure. (and netdb.h now > defines h_errno to *__h_errno_location() regardless of whether > _LIBC_REENTRANT is defined or not.) So I used this hack in WineX, not sure > if it would be anywhere close to the right approach, if the right approach > presumably wasn't to remove this file entirely. Hi Ove! Can you run this by the glibc mailing list? I'm sure Ulrich Drepper will be able to tell you whether it's the right fix. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

1 0

[Fwd: wine version]
by Tony Lambregts 26 Dec '02

26 Dec '02

-------- Original Message -------- Subject: wine version Date: Wed, 25 Dec 2002 22:54:50 +0100 From: "puoti(a)inwind.it" <puoti(a)inwind.it> Reply-To: wine-devel(a)winehq.com To: "bugs" <bugs(a)winehq.com> > We are at wine-20021219, but when you submit a new bug you can't select a > version more recent that wine-2002 We kind of need to get this automated if we could (yes?) any suggestions? -- Tony Lambregts

1 0

wcscmp header? %S format string in ok()?
by Dan Kegel 26 Dec '02

26 Dec '02

I get the following compiler warnings in dlls/ntdll/tests/rtlstr.c: gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DNONAMELESSUNION -DNONAMELESSSTRUCT -D_REENTRANT -o rtlstr.o rtlstr.c rtlstr.c: In function `test_RtlInitUnicodeString': rtlstr.c:110: warning: implicit declaration of function `wcscmp' rtlstr.c: In function `test_RtlUnicodeStringToInteger': rtlstr.c:175: warning: wchar_t format, different type arg (arg 3) rtlstr.c:180: warning: wchar_t format, different type arg (arg 3) rtlstr.c:181: warning: wchar_t format, different type arg (arg 3) rtlstr.c:183: warning: wchar_t format, different type arg (arg 3) rtlstr.c:184: warning: wchar_t format, different type arg (arg 3) rtlstr.c:186: warning: wchar_t format, different type arg (arg 3) rtlstr.c:187: warning: wchar_t format, different type arg (arg 3) rtlstr.c:189: warning: wchar_t format, different type arg (arg 3) rtlstr.c:190: warning: wchar_t format, different type arg (arg 3) (Actually, before the patch I just sent in, there were a couple more.) Two questions: 1. what .h file should tests/rtlstr.c include to get wcscmp? Posix says one thing, MSDN says a similar thing, but I want to get the path right. 2. The whcar_t format warnings might be serious -- isn't posix's wchar_t different from win32's wchar_t? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

2 1