wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

i would like to do some translation work where do i need to start ?
by Ezequiel Perez 28 Dec '02

28 Dec '02

Hi, I'm Ezequiel Perez i would like to do some translation work where do i need to start? I can translate it to the spanish language I live in Buenos Aires, Argentina, my ICQ is 126918474, my MSN Messenger is eazel7(a)msn.com

2 1

make uninstall trying to remove aclocal??
by Mark Knecht 28 Dec '02

28 Dec '02

Hi, I note that at the end of make uninstall the scripts seem to be attempting to remove a shared directory. I really am not sure this is a good idea, or at the least the desired action is not taking place... In my case the directory is actually a link, but I think you should not be removing it anyway. Thanks, Mark rm -f /usr/local/share/aclocal/wine.m4 rmdir /usr/local/share/aclocal rmdir: `/usr/local/share/aclocal': Not a directory make: [uninstall] Error 1 (ignored) [root@Godzilla share]# ls -al aclocal lrwxrwxrwx 1 root root 18 Dec 6 18:00 aclocal -> /usr/share/aclocal [root@Godzilla share]#

1 0

Couldn't find a decent font, aborting
by Mark Knecht 27 Dec '02

27 Dec '02

Hi, On many installations, and even when running just wcmd, I'm getting this error message: [mark@Godzilla mark]$ wcmd err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting [mark@Godzilla mark]$ wine --version Wine 20021219 [mark@Godzilla mark]$ I've quickly searched through the Devel and User archives, and searched using Google, but found just about nothing on the subject. The only suggestion was to run in 640x480 desktop mode, which I tried but it didn't help at all. Tony has been very helpful at Wine-User but we haven't discovered the solution. Wine is running Quicken, Winzip and WS_FTP just fine. I've tried WinAmp3 which comes up but does not generate sound at all. I'm using the new Jack drivers for Wine, so I wasn't expecting perfection in that area just yet, but hope to work with Chris Morgan to make that more solid. I have lots of Windows audio apps to try out. My machine is RH 7.3, running Alsa and Jack for sound and doing high-end audio stuff. It's up to date with new RPMs, but is a sort of minimalistic machine in terms of non-audio apps. Wine is from CVS yesterday. I'm running a no Windows installation. I'm currently running KDE 3.0.X. Can you folks recommend how I go about fixing this? What fonts are required to be installed to make Wine happy? How do I give you good feedback if I can't run the debugger? This morning I've done: make uninstall make clean make but chose to not overwrite my current registry file. Let me know if you need more information. I appreciate your help in advance. Merry Christmas and Happy Holidays! Cheers, Mark

2 2

RE: PATCH: dlls/cabinet/cabextract.c and off_t
by Patrik Stridvall 27 Dec '02

27 Dec '02

> On Fri, 27 Dec 2002, Greg Turner wrote: > >>>> If we really want to use off_t in this file (instead of > cab_off_t) > >>>> we need to #include sys/types.h, or we'll break > non-Linux systems. > >> Short to medium term, do you agree with my fix (#include > >> <sys/types.h>) so that Wine also builds on non-Linux systems? > > Maybe. I don't object, since it should be harmless to add > this, but I > > seem to be missing the point of why sys/types.h is needed at all. > > cab_off_t is just typedef'ed to UINT32, which should > compile just fine > > with only winnt.h, I think. Is there a particular scenario you are > > encountering that fails? If so, what is the compile error? > > The following line is the problem: > > fol->offset[0] = base_offset + (off_t) > EndGetI32(buf+cffold_DataOffset); > ^^^^^ > > Here we use off_t (which requires sys/types.h), that's why I wrote "If > we really want to use off_t in this file. Should this simply become > cab_off_t? Since the type of fol->offset is cab_off_t presumably... That is how I fixed it in my tree.

1 0

RtlUnicodeStringToInteger prototype (resending)
by Dan Kegel 27 Dec '02

27 Dec '02

I sent this to wine-patches on the 25th, but it never appeared in the archive; is that list moderated? - Dan Changelog: * dlls/ntdll/{,tests/}rtlstr.c - fix prototype for RtlUnicodeToInteger Dan Kegel License: LGPL Index: dlls/ntdll/rtlstr.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/rtlstr.c,v retrieving revision 1.25 diff -u -r1.25 rtlstr.c --- dlls/ntdll/rtlstr.c 12 Nov 2002 02:17:34 -0000 1.25 +++ dlls/ntdll/rtlstr.c 25 Dec 2002 18:52:54 -0000 @@ -843,17 +843,17 @@ */ NTSTATUS WINAPI RtlUnicodeStringToInteger( const UNICODE_STRING *str, - int base, - int * pdest) + ULONG base, + PULONG pdest) { LPWSTR lpwstr = str->Buffer; WCHAR wchCurrent = 0; int CharsParsed = 0; - int RunningTotal = 0; + ULONG RunningTotal = 0; char bMinus = 0; /* no checking done on UNICODE_STRING and int* in native DLL either */ - TRACE("(%p, %d, %p)", str, base, pdest); + TRACE("(%p, %lu, %p)", str, base, pdest); switch (base) { @@ -895,8 +895,7 @@ wchCurrent = '0' + 10 + wchCurrent - 'A'; if ((wchCurrent - '0') >= base || wchCurrent < '0') { - *pdest = bMinus ? -RunningTotal: RunningTotal; - return STATUS_SUCCESS; + break; } /* * increase significance of previous digits each time @@ -905,6 +904,6 @@ RunningTotal = wchCurrent - '0' + RunningTotal * base; } - *pdest = bMinus ? -RunningTotal : RunningTotal; + *pdest = bMinus ? ((~RunningTotal)+1UL) : RunningTotal; return STATUS_SUCCESS; } Index: dlls/ntdll/tests/rtlstr.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/tests/rtlstr.c,v retrieving revision 1.2 diff -u -r1.2 rtlstr.c --- dlls/ntdll/tests/rtlstr.c 19 Dec 2002 21:15:41 -0000 1.2 +++ dlls/ntdll/tests/rtlstr.c 25 Dec 2002 18:52:54 -0000 @@ -66,7 +66,7 @@ /* more function pointers here */ /*static DWORD (WINAPI *pRtlIsTextUnicode)(LPVOID, DWORD, DWORD *);*/ -static NTSTATUS (WINAPI *pRtlUnicodeStringToInteger)(const UNICODE_STRING *, int, int *); +static NTSTATUS (WINAPI *pRtlUnicodeStringToInteger)(const UNICODE_STRING *, ULONG, PULONG); static void InitFunctionPtrs() { @@ -123,7 +123,7 @@ static void test_RtlUnicodeStringToInteger(void) { - int dest = 0; + ULONG dest = 0; int i; DWORD result; @@ -131,6 +131,7 @@ static const WCHAR stringwithint[][12] = { {'1','0','1','1','1','0','1','1','0','0',0}, {'1','2','3','4','5','6','7',0}, + {'-','2','1','4','7','4','8','3','6','4','7',0}, {'2','1','4','7','4','8','3','6','4','8',0}, {'-','2','1','4','7','4','8','3','6','4','8',0}, {'-','2','1','4',0}, @@ -141,11 +142,12 @@ {'0','x','1','2','3','4','5',0}, {'1','x','3','4',0} }; - static const int expectedresults[] = { + static const ULONG expectedresults[] = { 1011101100, 1234567, - 2147483648, - 2147483648, + -2147483647, + 2147483648UL, + 2147483648UL, /* 2 ^ 31 === - (2 ^ 31) */ -214, 214, 214, @@ -155,34 +157,37 @@ 1 }; /* these are for stringwithint[0]: */ - static const int expectedresultsbase[] = { + static const ULONG expectedresultsbase[] = { 748, /* base 2 */ 136610368, /* base 8 */ 1011101100, /* base 10 */ 286265600, /* base 16 */ }; - - for (i = 0; i < sizeof(expectedresults) / sizeof(int); i++) + + /* check assumption made in -0 test case */ + ok((2147483648UL == ((~2147483648UL) + 1UL)), "LONG is not 32 bits?"); + + for (i = 0; i < sizeof(expectedresults) / sizeof(expectedresults[0]); i++) { dest = 0xdeadbeef; pRtlInitUnicodeString(&uni, stringwithint[i]); result = pRtlUnicodeStringToInteger(&uni, 0, &dest); ok(result == 0, "call failed: RtlUnicodeStringToInteger(\"%S\", %d, [out])", uni.Buffer, 0); - ok(dest == expectedresults[i], "didn't return expected value (test %d): expected: %d, got: %d}", i, expectedresults[i], dest); + ok(dest == expectedresults[i], "didn't return expected value (test %d): expected: %lu, got: %lu}", i, expectedresults[i], dest); } pRtlInitUnicodeString(&uni, stringwithint[0]); result = pRtlUnicodeStringToInteger(&uni, 2, &dest); ok(result == 0, "call failed: RtlUnicodeStringToInteger(\"%S\", %d, [out])", uni.Buffer, 2); - ok(dest == expectedresultsbase[0], "didn't return expected value: \"%S\"; expected: %d, got: %d}", uni.Buffer, expectedresultsbase[0], dest); + ok(dest == expectedresultsbase[0], "didn't return expected value: \"%S\"; expected: %lu, got: %ld}", uni.Buffer, expectedresultsbase[0], dest); result = pRtlUnicodeStringToInteger(&uni, 8, &dest); ok(result == 0, "call failed: RtlUnicodeStringToInteger(\"%S\", %d, [out])", uni.Buffer, 8); - ok(dest == expectedresultsbase[1], "didn't return expected value: \"%S\"; expected: %d, got: %d}", uni.Buffer, expectedresultsbase[1], dest); + ok(dest == expectedresultsbase[1], "didn't return expected value: \"%S\"; expected: %lu, got: %ld}", uni.Buffer, expectedresultsbase[1], dest); result = pRtlUnicodeStringToInteger(&uni, 10, &dest); ok(result == 0, "call failed: RtlUnicodeStringToInteger(\"%S\", %d, [out])", uni.Buffer, 10); - ok(dest == expectedresultsbase[2], "didn't return expected value: \"%S\"; expected: %d, got: %d}", uni.Buffer, expectedresultsbase[2], dest); + ok(dest == expectedresultsbase[2], "didn't return expected value: \"%S\"; expected: %lu, got: %ld}", uni.Buffer, expectedresultsbase[2], dest); result = pRtlUnicodeStringToInteger(&uni, 16, &dest); ok(result == 0, "call failed: RtlUnicodeStringToInteger(\"%S\", %d, [out])", uni.Buffer, 16); - ok(dest == expectedresultsbase[3], "didn't return expected value: \"%S\"; expected: %d, got: %d}", uni.Buffer, expectedresultsbase[3], dest); + ok(dest == expectedresultsbase[3], "didn't return expected value: \"%S\"; expected: %lu, got: %ld}", uni.Buffer, expectedresultsbase[3], dest); } START_TEST(rtlstr)

2 2

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

D3D status - bis
by Lionel Ulmer 26 Dec '02

26 Dec '02

Hi all, I created a small web page with the list of the demos / games I am using to test Direct3D and their various status. If anyone of you has a demo that is almost running (ie it starts in D3D mode and does not crash to reason not linked to D3D) and you want me to look at it, send me a private mail and we will see what I can do (once I come home to my ADSL line :-) ). I would also be glad of people testing the same demos than me with other OpenGL libraries to see if they have the same texturing problem that I have. The status page is here : http://www.bbrox.org/d3d_status.html Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 6

Re: Patch for Spanish keyboard layout
by Jeff Smith 26 Dec '02

26 Dec '02

Daniel, What version of wine sources are you diffing against? If it is any older than 20021219, you really need to get up to date. Development is fairly rapid on this project, and *many* problems are fixed from one release to the next. I submitted a patch for your problem on October 29th: http://www.winehq.com/hypermail/wine-patches/2002/10/0503.html It was committed to CVS the same day: http://www.winehq.com/hypermail/wine-cvs/2002/10/0481.html So this should have been in the last two or three tagged versions. >Hi! > >This is a correction for the "Spanish keyboard layout". I think the >original layout had a typo. The original layout had two keys for the >character "'". This new layout fixes this problem and works perfect on my >machine with my "Spanish keyboard". > >Thanks ... > >-- >Daniel Mario Vega >dv5a(a)dc.uba.ar _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

Re: Re: D3D status - bis
by fenix＠club-internet.fr 26 Dec '02

26 Dec '02

----Message d'origine---- >De: "Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> >A: "wine devel" <wine-devel(a)winehq.com> >Sujet: Re: D3D status - bis >Date: Wed, 25 Dec 2002 23:36:47 -0000 > >>> very Good idea, but it will be better if we can separate D3D[1-7] to >D3D[8-9] demos >>> as the two development in wine ;) > >I would be interested in locations of any d3d8 demos/samples which I can >download via a url, especially if they get as far as starting - d3d8 support >is still early stages. To avoid clutter to the list, feel free to drop me an >email. Hi, Personnaly i use for simple samples: - dx8.1 sdk samples - some gamedev.net d3d8 samples/tutorials (a gamedeveloper site) - some tutorials from a french game magazine (i can send you this if you want) and for games (for hards tests): - splinter cell demo (with vertex/pixel shaders) - warcraft 3 demo (only simple d3d) >>Well, as I only work (for now) on D3D[1-7] and this page is more done for me >>to know where I stand on all the games, I did not want to add too much stuff >>(ie as long as I do not work on D3D8, I won't add any of these games on this >>list). >>Otherwise, it's a bigger project (like some sort if 'developper only' application database). > If anyone fancies maintaining a similar page for d3d8 it would probably help, as I am not the only one looking at this code, and a status would be a good idea. > I suspect though at the moment they are all in about the same(failing) state! ;) i'll send you a simple draft for my samples and games tests for beginning. >Jason > Raphael

1 0

Re: D3D status - bis
by Ann and Jason Edmeades 25 Dec '02

25 Dec '02

>> very Good idea, but it will be better if we can separate D3D[1-7] to D3D[8-9] demos >> as the two development in wine ;) I would be interested in locations of any d3d8 demos/samples which I can download via a url, especially if they get as far as starting - d3d8 support is still early stages. To avoid clutter to the list, feel free to drop me an email. >Well, as I only work (for now) on D3D[1-7] and this page is more done for me >to know where I stand on all the games, I did not want to add too much stuff >(ie as long as I do not work on D3D8, I won't add any of these games on this >list). >Otherwise, it's a bigger project (like some sort of 'developper only' >application database). If anyone fancies maintaining a similar page for d3d8 it would probably help, as I am not the only one looking at this code, and a status would be a good idea. I suspect though at the moment they are all in about the same (failing) state! Jason

1 0

Re: Wine Contrib v0.4
by Jeff Smith 25 Dec '02

25 Dec '02

There are several unmatched and interleaved tags on this page, which causes all kinds of funniness on various browsers. The unmatched anchor tags are particularly troublesome. I can send a patch if that would be simplest. Perhaps whoever is maintaining these pages should validate (validator.w3.org) it periodically. Anyone maintaining a wine page that needs help understanding validator error messages and/or how to correct them, I am glad to help. -- Jeff S >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >Hi folks, > >Tom Wickline took over the Wine Contrib page, and >cleaned it up. He already went through 4 iterations, >and asked me to post it on my site for your reviewing >pleasure: > http://www.dssd.ca/wine/Wine-Contrib-0.4.html > >Please take a look at it, and let us know what you >think. The idea is to get it over with as soon as >possible so that work on other pages can commence. > >-- >Dimi. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: Validate imagelists
by Andreas Mohr 24 Dec '02

24 Dec '02

On Tue, Dec 24, 2002 at 11:27:57AM -0800, Duane Clark wrote: > Changelog: > Validate imagelists with christmas magic. Huh ? > Index: dlls/comctl32/imagelist.h > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/imagelist.h,v > retrieving revision 1.3 > diff -u -r1.3 imagelist.h > --- dlls/comctl32/imagelist.h 31 May 2002 23:25:44 -0000 1.3 > +++ dlls/comctl32/imagelist.h 24 Dec 2002 19:26:09 -0000 > @@ -53,6 +53,8 @@ > INT nOvlIdx[15]; > }; > > +#define IMAGELIST_MAGIC 0x4C4D4948 "HIML" ?? Wouldn't that be more like 0x53414D58 ??? Merry Christmas, BTW ! :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

Some D3D status updates...
by Lionel Ulmer 24 Dec '02

24 Dec '02

Hi all, As it was one of my objectives when Christian's work prodded me into restarting working on D3D, I am happy to show here the first screen shot of SystemShock2 working (alas texture-less) with Wine : http://www.bbrox.org/system_shock2.png Merry Christmas to everybody :-) Lionel (with one week and a half of almost full-time hack vacation left :-) ) -- Lionel Ulmer - http://www.bbrox.org/

3 2

[JOY] wxWindows
by Dimitrie O. Paun 24 Dec '02

24 Dec '02

Folks, Last night I managed to compile, link, and successfully run all(1) samples that come with wxWindows. In all honesty I am overjoyed! Let me explain why: -- wxWindows is a large piece of software that touches on most (if not all) Wine aspects. It does put our headers through their paces. -- The porting effort has been simple, and it took me a just a few days to do it. -- I have not used _any_ of the previous efforts to port wxWindows to Wine. I rather started with their MinGW port. -- Most of the changes have been trivial fixes for Wine which I have sent to wine-patches in the last few days. -- The hacks to wxWindows have been trivial and few in number. I have touched only a few files, and the changes are real simple. They'll need some cleaning up, and I'll submit them to the wxWindows folks for inclusion. -- The wine{gcc,wrap} combo is a great success. All I had to do was to touch only *one* file (makeg95.env), and modify only a few lines to get *everything* to compile and link. What does Wine get out of it: -- A good test for our headers -- Proof that wine{gcc,wrap} are a good idea (at least for me) -- A large number of sample that show quite a few problems in Wine. If anyone is interested in more details please let me know, and I'll be glad to provide them. Once we decide on the __WINE__ vs. __WINESRC__ thing, I'll cleanup the wxWindows changes and submit them for inclusion in their tree, so hopefully you'll be able to play with it using the official version not before long. Notes 1. All but a few: - 'dialup' did not compile because I had to disable dialup support in wxWindows since wine does not have a wininet.h - 'proplist' did not compile because I forgot to enable property lists in the configuration when I compiled wxWindows - 'tab' sample did not compile because it's recommended to not enable this deprecated option, so I did not. - the samples 'listbox', 'memcheck', and 'opengl/*' are not supported by wxWindows under MinGW, so I did not bother. -- Dimi.

2 2

'make test' failure on sysparams.c
by Dan Kegel 24 Dec '02

24 Dec '02

On fresh cvs: ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so sysparams.c && touch sysparams.ok X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 15 (X_QueryTree) Resource id in failed request: 0x2600003 Serial number of failed request: 45 Current serial number in output stream: 45 make[3]: *** [sysparams.ok] Error 1 This happens if I run 'make test' with a remote X window between two Red Hat 8.0 systems. (I haven't run the test locally on the screen that causes trouble, but I bet it'd be ok.) Can someone suggest the best way of tackling this? Thanks, Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

1 1

Re: Validate imagelists
by Dimitrie O. Paun 24 Dec '02

24 Dec '02

On December 24, 2002 02:27 pm, Duane Clark wrote: > + if (himl == NULL || himl->magic!=IMAGELIST_MAGIC) What about a: static inline BOOL is_valid(HIMAGELIST himl) { return himl && himl->magic == IMAGELIST_MAGIC; } -- Dimi.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel