December 2002 - Wine-Devel - list.winehq.org

Re: RtlUnicodeStringToInteger prototype (resending)

by Duane Clark

Dan Kegel wrote: > I sent this to wine-patches on the 25th, but it never appeared in the archive; > is that list moderated? Only for unsubscribed email adresses, or postings over a 200KB size limit. And I did not see your patches among those being held.

Dec. 27, 2002

Re: Standard way of printing RECT in trace statements?

by Dan Kegel

Dimitrie O. Paun wrote: > On December 26, 2002 12:14 am, Dan Kegel wrote: > >>Example use: >> TRACE("Combo client " _RECT_FMT ", setting Edit to " _RECT_FMT "\n", >> _RECT_ARG(rect), x, y, x + w, y + h); > > > Oh no! It's not too pretty, isn't it? :) No, it's pretty ugly :-) >>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. > > > I'll bet you a dollar in small change you can not measure a 1% speed > difference. This code executes in trace mode only, where you don't > care about the speed anyhow. Also, the since difference must be minute > anyhow since the macro approach actually enlarges the strings where > it's used. I thought everyone always left NO_TRACE_MSGS undefined, so the rect2a function you favor gets called unconditionally, and its output filtered out. The macro doesn't enlarge the strings over current practice; it merely codifies existing usage. There would be no net change in string size or code size with the macro approach. Alternately, we could skip the macros, and just standardize the format strings. Would that be more acceptable? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 27, 2002

RtlUnicodeStringToInteger prototype (resending)

by Dan Kegel

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)

Dec. 27, 2002

Re: Wine: several warnings in dlls/ntdll/tests/rtlstr.c

by Dan Kegel

Gerald Pfeifer wrote: > 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: I brought those up recently; Francois Gouget suggests fixing the wcscmp warning by switching to strcmpW http://www.winehq.com/hypermail/wine-devel/2002/12/0892.html I fixed the decimal constant warnings in a patch I sent a couple days ago... but my mail system seems to have dropped it, so I'll resend it. The format warnings are worrisome. > > 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 -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 27, 2002

Wine Contrib 0.6

by Dimitrie O. Paun

Folks, A new version of Wine-Contrib is available at: http://www.dssd.ca/wine/Wine-Contrib-0.6.html courtesy of Tom & Tony. -- Dimi.

Dec. 27, 2002

Re: Standard way of printing RECT in trace statements?

by Dimitrie O. Paun

On December 26, 2002 12:14 am, Dan Kegel wrote: > Example use: > TRACE("Combo client " _RECT_FMT ", setting Edit to " _RECT_FMT "\n", > _RECT_ARG(rect), x, y, x + w, y + h); Oh no! It's not too pretty, isn't it? :) > 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. I'll bet you a dollar in small change you can not measure a 1% speed difference. This code executes in trace mode only, where you don't care about the speed anyhow. Also, the since difference must be minute anyhow since the macro approach actually enlarges the strings where it's used. Not to speak of the aesthetic side of things... :) -- Dimi.

Dec. 27, 2002

Re: Listview scroll patch

by Dimitrie O. Paun

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.

Dec. 27, 2002

Re: Do not free the header while unmapping the xxxx_UNPREPARE messages

by Eric Pouech

> It seems to me that it's an unnecessary complexity to introduce extra parameter > for unmapping function exclusively for xxxx_UNPREPARE messages. Could you please > show what you have in mind for the single mapping/unmapping function pair? yes, we need to add the result of the call to the unmapping function something like this would do A+ -- Eric Pouech cvs diff: Diffing . Index: lolvldrv.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/lolvldrv.c,v retrieving revision 1.41 diff -u -r1.41 lolvldrv.c --- lolvldrv.c 23 Dec 2002 02:05:30 -0000 1.41 +++ lolvldrv.c 27 Dec 2002 15:53:41 -0000 @@ -39,9 +39,9 @@ LPSTR typestr; /* name (for debugging) */ BOOL bSupportMapper; /* if type is allowed to support mapper */ MMDRV_MAPFUNC Map16To32A; /* those are function pointers to handle */ - MMDRV_MAPFUNC UnMap16To32A; /* the parameter conversion (16 vs 32 bit) */ + MMDRV_UNMAPFUNC UnMap16To32A; /* the parameter conversion (16 vs 32 bit) */ MMDRV_MAPFUNC Map32ATo16; /* when hi-func (in mmsystem or winmm) and */ - MMDRV_MAPFUNC UnMap32ATo16; /* low-func (in .drv) do not match */ + MMDRV_UNMAPFUNC UnMap32ATo16; /* low-func (in .drv) do not match */ LPDRVCALLBACK Callback; /* handles callback for a specified type */ /* those attributes reflect the loaded/current situation for the type */ UINT wMaxId; /* number of loaded devices (sum across all loaded drivers */ @@ -74,8 +74,8 @@ * */ void MMDRV_InstallMap(unsigned int drv, - MMDRV_MAPFUNC mp1632, MMDRV_MAPFUNC um1632, - MMDRV_MAPFUNC mp3216, MMDRV_MAPFUNC um3216, + MMDRV_MAPFUNC mp1632, MMDRV_UNMAPFUNC um1632, + MMDRV_MAPFUNC mp3216, MMDRV_UNMAPFUNC um3216, LPDRVCALLBACK cb) { assert(drv < MMDRV_MAX); @@ -234,7 +234,7 @@ dwParam1, dwParam2); TRACE("=> %lu\n", ret); if (map == WINMM_MAP_OKMEM) - llType->UnMap16To32A(wMsg, &mld->dwDriverInstance, &dwParam1, &dwParam2); + llType->UnMap16To32A(wMsg, &mld->dwDriverInstance, &dwParam1, &dwParam2, ret); break; default: FIXME("NIY\n"); @@ -264,7 +264,7 @@ dwParam1, dwParam2); TRACE("=> %lu\n", ret); if (map == WINMM_MAP_OKMEM) - llType->UnMap32ATo16(wMsg, &mld->dwDriverInstance, &dwParam1, &dwParam2); + llType->UnMap32ATo16(wMsg, &mld->dwDriverInstance, &dwParam1, &dwParam2, ret); break; default: FIXME("NIY\n"); Index: message16.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/message16.c,v retrieving revision 1.6 diff -u -r1.6 message16.c --- message16.c 23 Dec 2002 02:05:30 -0000 1.6 +++ message16.c 27 Dec 2002 15:57:26 -0000 @@ -70,7 +70,7 @@ /************************************************************************** * MMDRV_Aux_UnMap16To32A [internal] */ -static WINMM_MapType MMDRV_Aux_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_Aux_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { return WINMM_MAP_MSGERROR; } @@ -86,7 +86,7 @@ /************************************************************************** * MMDRV_Aux_UnMap32ATo16 [internal] */ -static WINMM_MapType MMDRV_Aux_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_Aux_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { #if 0 case AUXDM_GETDEVCAPS: @@ -126,7 +126,7 @@ /************************************************************************** * MMDRV_Mixer_UnMap16To32A [internal] */ -static WINMM_MapType MMDRV_Mixer_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_Mixer_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { #if 0 MIXERCAPSA micA; @@ -156,7 +156,7 @@ /************************************************************************** * MMDRV_Mixer_UnMap32ATo16 [internal] */ -static WINMM_MapType MMDRV_Mixer_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_Mixer_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { return WINMM_MAP_MSGERROR; } @@ -187,7 +187,7 @@ /************************************************************************** * MMDRV_MidiIn_UnMap16To32A [internal] */ -static WINMM_MapType MMDRV_MidiIn_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_MidiIn_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { return WINMM_MAP_MSGERROR; } @@ -203,7 +203,7 @@ /************************************************************************** * MMDRV_MidiIn_UnMap32ATo16 [internal] */ -static WINMM_MapType MMDRV_MidiIn_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_MidiIn_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { return WINMM_MAP_MSGERROR; } @@ -360,7 +360,7 @@ /************************************************************************** * MMDRV_MidiOut_UnMap16To32A [internal] */ -static WINMM_MapType MMDRV_MidiOut_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_MidiOut_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { WINMM_MapType ret = WINMM_MAP_MSGERROR; @@ -411,7 +411,7 @@ if (mh16->reserved >= sizeof(MIDIHDR)) mh16->dwOffset = mh32->dwOffset; - if (wMsg == MODM_UNPREPARE) { + if (wMsg == MODM_UNPREPARE && fn_ret == MMSYSERR_NOERROR) { HeapFree(GetProcessHeap(), 0, (LPSTR)mh32 - sizeof(LPMIDIHDR)); mh16->lpNext = 0; } @@ -571,7 +571,7 @@ /************************************************************************** * MMDRV_MidiOut_UnMap32ATo16 [internal] */ -static WINMM_MapType MMDRV_MidiOut_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_MidiOut_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { WINMM_MapType ret = WINMM_MAP_MSGERROR; @@ -617,7 +617,7 @@ mh32->dwUser = mh16->dwUser; mh32->dwFlags = mh16->dwFlags; - if (wMsg == MODM_UNPREPARE) { + if (wMsg == MODM_UNPREPARE && fn_ret == MMSYSERR_NOERROR) { HeapFree( GetProcessHeap(), 0, ptr ); mh32->lpNext = 0; } @@ -805,7 +805,7 @@ /************************************************************************** * MMDRV_WaveIn_UnMap16To32A [internal] */ -static WINMM_MapType MMDRV_WaveIn_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_WaveIn_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { WINMM_MapType ret = WINMM_MAP_MSGERROR; @@ -860,7 +860,7 @@ wh16->dwFlags = wh32->dwFlags; wh16->dwLoops = wh32->dwLoops; - if (wMsg == WIDM_UNPREPARE) { + if (wMsg == WIDM_UNPREPARE && fn_ret == MMSYSERR_NOERROR) { HeapFree(GetProcessHeap(), 0, (LPSTR)wh32 - sizeof(LPWAVEHDR)); wh16->lpNext = 0; } @@ -1047,7 +1047,7 @@ /************************************************************************** * MMDRV_WaveIn_UnMap32ATo16 [internal] */ -static WINMM_MapType MMDRV_WaveIn_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_WaveIn_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { WINMM_MapType ret = WINMM_MAP_MSGERROR; @@ -1089,7 +1089,7 @@ wh32->dwLoops = wh16->dwLoops; UnMapLS( *lpParam1 ); - if (wMsg == WIDM_UNPREPARE) { + if (wMsg == WIDM_UNPREPARE && fn_ret == MMSYSERR_NOERROR) { HeapFree( GetProcessHeap(), 0, ptr ); wh32->lpNext = 0; } @@ -1303,7 +1303,7 @@ /************************************************************************** * MMDRV_WaveOut_UnMap16To32A [internal] */ -static WINMM_MapType MMDRV_WaveOut_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_WaveOut_UnMap16To32A(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { WINMM_MapType ret = WINMM_MAP_MSGERROR; @@ -1369,7 +1369,7 @@ wh16->dwFlags = wh32->dwFlags; wh16->dwLoops = wh32->dwLoops; - if (wMsg == WODM_UNPREPARE) { + if (wMsg == WODM_UNPREPARE && fn_ret == MMSYSERR_NOERROR) { HeapFree(GetProcessHeap(), 0, (LPSTR)wh32 - sizeof(LPWAVEHDR)); wh16->lpNext = 0; } @@ -1575,7 +1575,7 @@ /************************************************************************** * MMDRV_WaveOut_UnMap32ATo16 [internal] */ -static WINMM_MapType MMDRV_WaveOut_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2) +static WINMM_MapType MMDRV_WaveOut_UnMap32ATo16(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT fn_ret) { WINMM_MapType ret; @@ -1659,7 +1659,7 @@ wh32->dwLoops = wh16->dwLoops; UnMapLS( *lpParam1 ); - if (wMsg == WODM_UNPREPARE) { + if (wMsg == WODM_UNPREPARE && fn_ret == MMSYSERR_NOERROR) { HeapFree( GetProcessHeap(), 0, ptr ); wh32->lpNext = 0; } Index: winemm.h =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/winemm.h,v retrieving revision 1.42 diff -u -r1.42 winemm.h --- winemm.h 11 Nov 2002 19:53:01 -0000 1.42 +++ winemm.h 27 Dec 2002 15:57:36 -0000 @@ -225,6 +225,7 @@ typedef LONG (*MCIPROC16)(DWORD, HDRVR16, WORD, DWORD, DWORD); typedef LONG (*MCIPROC)(DWORD, HDRVR, DWORD, DWORD, DWORD); typedef WINMM_MapType (*MMDRV_MAPFUNC)(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2); +typedef WINMM_MapType (*MMDRV_UNMAPFUNC)(UINT wMsg, LPDWORD lpdwUser, LPDWORD lpParam1, LPDWORD lpParam2, MMRESULT ret); LPWINE_DRIVER DRIVER_FindFromHDrvr(HDRVR hDrvr); BOOL DRIVER_GetLibName(LPCSTR keyName, LPCSTR sectName, LPSTR buf, int sz); @@ -244,8 +245,8 @@ DWORD MMDRV_Message(LPWINE_MLD mld, WORD wMsg, DWORD dwParam1, DWORD dwParam2, BOOL bFrom32); UINT MMDRV_PhysicalFeatures(LPWINE_MLD mld, UINT uMsg, DWORD dwParam1, DWORD dwParam2); BOOL MMDRV_Is32(unsigned int); -void MMDRV_InstallMap(unsigned int, MMDRV_MAPFUNC, MMDRV_MAPFUNC, - MMDRV_MAPFUNC, MMDRV_MAPFUNC, LPDRVCALLBACK); +void MMDRV_InstallMap(unsigned int, MMDRV_MAPFUNC, MMDRV_UNMAPFUNC, + MMDRV_MAPFUNC, MMDRV_UNMAPFUNC, LPDRVCALLBACK); BOOL MCI_Init(void); WINE_MCIDRIVER* MCI_GetDriver(UINT16 uDevID);

Dec. 27, 2002

Re: d3d three more renderstates for n2002

by Lionel Ulmer

> 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. For the documentation, do a Google search on the .CHM files from the various DirectX SDKs (as the relevant documentations are not to be found anymore on MSDN's site, only DX8 / 9 is still there). I have them all but think it's not very legal to redistribute them. I could though give you the file names so you can Google them :-) > 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. Well, I really wonder what 'the lot of functions' are that is lacking... Do you have a tree with all the patches recently sent applied to or a plain CVS tree ? From my experience, the only stuff missing is the SetTextureStageState stuff. I doubt that other 'important' features are still missing. > 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. Well, the Mesa name in the Wine source tree is historic (at the time these files were created, the only OpenGL code for Linux was Mesa and it was using the OSMesa extension to run). And as it's a pain to rename files in CVS, it was never done. The day we will move the files around to a d3dgl.dll library to ease packaging, the files will be renamed. > + 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; Well, did you add also the code creating these clipping planes ? Otherwise, it's not such a good idea to enable them :-) I will have to reboot in Windows (or pester Endy to give me his CHM file viewer :-) ) to tell exactly what that should do and how these clipping planes are created. > + > + case D3DRENDERSTATE_EXTENTS: > + /* boolean > + * dont have a clue what this does */ > + FIXME("What is D3DRENDERSTATE_EXTENTS supposed to do?\n"); > + break; Why not keep the standard 'not supported' instead of adding a case ? > + > + 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; > + This looks fine... Except that I have no real idea after reading the OpenGL man page exactly what GL_POLYGON_SMOOTH does :-) And I think you could enable it for lines too (but well, I do not know any game using lines though). Anyway, welcome on board :-) Lionel PS: I updated the d3d_status.html page. -- Lionel Ulmer - http://www.bbrox.org/

Dec. 27, 2002

d3d three more renderstates for n2002

by Christoph Frick

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); }

Dec. 27, 2002

Re: PATCH: dlls/cabinet/cabextract.c and off_t

by Gerald Pfeifer

On Thu, 26 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. > actually I don't think we really want to use off_t. [...] > The easy version of the right fix is probably just to rename "cab_off_t" > to something less confusing (i.e., cab_file_offset). The fancy fix > would be to support huge files, which might be a bit of a project. Ah, I see. Short to medium term, do you agree with my fix (#include <sys/types.h>) so that Wine also builds on non-Linux systems? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

Dec. 27, 2002

Wine: several warnings in dlls/ntdll/tests/rtlstr.c

by Gerald Pfeifer

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/

Dec. 27, 2002

Re: Listview scroll patch

by Chris Morgan

Hmm.... for some reason I was thinking it had to be done via a macro but I suppose I can return a pointer to a static string just as easily. I figured someone would balk at that cool macro ;-) hahah Chris On Thursday 26 December 2002 09:51 pm, Dimitrie O. Paun wrote: > 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.

Dec. 27, 2002

Re: PATCH: dlls/cabinet/cabextract.c and off_t

by Greg Turner

On Thursday 26 December 2002 02:48 pm, Gerald Pfeifer 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. > > Gerald > > > ChangeLog: > #include <sys/types.h> to obtain off_t. actually I don't think we really want to use off_t. The relationship to off_t is historical: cabextract (the unix executable, which I ported) used off_t because it used the fopen/fseek/fgetpos/etc family of functions. Wanting to depend only on kernel32, I ported these to use windowsy api's like CreateFile/SetFilePointer/etc, which take LONG arguments, IIRC. My memory on this is already a bit hazy, but I think I created cab_off_t to save myself keystrokes -- I basically was able to go through much of the code and just turn "off_t"'s into "cab_off_t"'s. Initially I tried to support huge (64 bit offset) files -- cab_off_t was going to be a struct with two LONGS -- but later I decided I was too lazy, since this would have required a substantial reworking of the logic, some of which I didn't even take the time to fully understand. There's a fair amount of math in there and in some places off_t's got passed around, converted to other types, etc.... so I decided I should bang out the port first and worry about the finer details later. The easy version of the right fix is probably just to rename "cab_off_t" to something less confusing (i.e., cab_file_offset). The fancy fix would be to support huge files, which might be a bit of a project. -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Dec. 27, 2002

Mac OS X Port of WineLib

by ATMRD＠aol.com

Hi, I dont recall how I stumbled upon Wine and its existance, however I am intersted in recent, if any, devlopments with the porting of Wine to OS X. I checked the Wine site and most of the articles are dated with the lastest date of Nov 2000. A lot has changed in OS X since that time and it appears that a leats a couple of the main issues have been addressed during this time. The main issues which seemed to be posted are as follows: Current list of possible issues: ================================ -> Endianness. Since we are using WineLib, could have resources written in native (big) endian format with wrc. Any external data files such as cursors, bitmaps, sound would have to be converted. The PUT_WORD/GET_WORD macros need byte swapping turned off. (Did I miss anything?) -> Exception handling, Signal handling code -> Memory alignment issues -> According to "Inside MacOS X: Kernel Environment" (<A HREF="http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf">http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf</A>) pg. 34, Darwin supports Pthreads, "many of the POSIX APIs" I haven't been able to find any lists of incompatibilities yet, but I am afraid of the word "many". -> According to the "MacOS X Kernel Environment" book, pg. 37, Mac OSX does not support memory mapped devices through the mmap API. This would affects at least streaming sound playback. -> WSControl / WSAIoctl need to be adapted to MacOS X. (ioctl() calls can be platform dependent, /proc/net/dev on linux is probably different on OSX) -> Sound Support. Currently done with WineOSS (ties into Linux OSS drivers) Doesn't seem to be a port of OSS to MacOSX. Maybe need to do another layer specific to the Mac(?) -> Must ensure that behaviour of lower level UNIX resources like sockets, threads, files are the way WINE expects it. -> Presence of Assembly language in code will have to be written in C or translated to PowerPC assembly. (assembly is generated in spec.c files, as well as other places like in the server) -> Debugger seems tied completely to Intel architecture. (Since we will be using WineLib, we probably don't need winedbg, can use gdb?) -> Need a X11 server or need to make a x11drv replacement that is Quartz specific. (There is a XFree86 port to MacOS X, but it only runs seperately from Quartz at this time. Making the X server a rootless client of Quartz is on the TODO list of Darwin but there is no mention of its current status. There is a commercial server, at: <A HREF="http://www.tenon.com/products/xtools/"> http://www.tenon.com/products/xtools/</A> which already implements this) -- the XFree86 port to MacOS X now includes a rootless clinet of Quartz so this should be a big jump having the window manager avialable. -> Need to be able to build Windows app using gcc (might be issues such as using MS specific keywords/language constructs, etc.) Does ATL build properly with gcc? in addition James Hatheway wrote on Nov 10 2000 "To test these concerns, I made four test apps and compiled and ran them on Mac OS X. I used the "Mac OS X Public Beta Developer Tools CD" which is downloadable from<A HREF="http://connect.apple.com"> http://connect.apple.com </A> The first test app used mmap and MAP_SHARED option, the second sent messages between two programs using sendto over a socket, the third used file I/O functions (like read,write) to send messages over a socket, the fourth sent an FD over a socket to another process using sendmsg/recvmsg. I have good news, each of these programs compiled without modification on MacOS X with the standard cc, and ran perfectly!! So, I don't think there are any show stoppers that would keep us from being able to port WineLib to MacOS X. Of course there would be work to do, but at least it is definitely possible. " I dont no what has happend to the WineLib port to MacOSX if anything. However, I am willing with what time I have to begin a port, since it does seem like it can be done now, hopefully with a group of people. In addition apple has posted some information regarding win32 porting that may be a little help at "http://developer.apple.com/macosx/win32porting/". Hope you had the best of holidays. Thanks ~Sanjay Connare

Dec. 27, 2002

Re: Old scrolling bug

by Duane Clark

Duane Clark wrote: > > 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). Well, that conclusion appears to not be quite correct. I stuck a XPending check at the end of X11DRV_EndGraphicsExposures to see whether there were any pending events, and there were apparently none. So I am not sure why the GraphicsExpose event is coming out before the regular expose event, since in real time, they occurred in the opposite order.

Dec. 27, 2002

Re: Listview scroll patch

by Dimitrie O. Paun

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.

Dec. 27, 2002

i would like to do some translation work where do i need to start ?

by Ezequiel Perez

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

Dec. 27, 2002

Re: Documentation work -task list -man pages

by Tom Wickline

> I think that we should keep the documentation tasks togetther. If its OK > with Dimi we can just use his page and give him diffs or we can split > off the documentation section and he can link to it. I ask Jeff Smith if he would be interested in helping with a task list page and he said he would be more than glad to. A broke down list of task would make things much more easier for would be newbie voilinteers to grasp.. And im sure Dimi would link it in. And this would not clutter his nice .9 page And since we are working on this it would make changing the task list a simple task in its self.. without having to ask dimi to make changes everytime somthing changes ... Comments ? > >> >> >> If our goal is to " Fix incomplete and/or out of date documentation." >> Then we should do the Merge as well so everything will be complete. > > > wine.texinfo is like a man page and it seems to be updated fairly well. > I don't agree with trying to get rid of it but I am not about to be the > one to maintain it either. We could do the merge and let the current maintainers maintain it correct ? Comments ? > > The wine How-to should be part of wine users. Once it is merged we > should get rid of it. OK.. But what about "The Perfect Enduser Wine Debugging Guide" are we going to do anything with this ? From the front page.. Needs improvement/contributors ! Gets merged into Developers Guide as soon as layout is rock-solid. I think we should go ahead and merge it now.. As it does not look as it will ever become rock solid. And get rid of it as well ... Comments ? > > I really dont know what to do about > installation-und-konfiguration.german. I am inclined to leave it for now Recrute a german speaking person to help with this ?? > Right now we could use someone "New To Wine" to go through the users > guide one chapter at a time and report to us *anything* they don't > understand. I will read over everything starting this monday. anyone else want to volinteer to read everything and give thoughs on how to improve our Documentation? Great for a newbie lurker who wants to help out :)) > > Anyone is welcome to point out errors and offer any suggestions to help > improve the documentation. Of course a patch is even better but if we do > not know about a problem we can not fix it. I agree Documentation is absolutly essential to the wine project. The better the documentation the more usefull the product is. And if we are seriouse about a future .9 or 1.0 release we should have the Documentation to back that release up. Wine is still not the easiest program to use.. And when 1.0 comes out and the word spreads im sure there will be a flood of downloads... And if the Documentation *SUCKS* for say!! it will only take wind out of our sail.. So now is the time to really start on this and get everything in order for 1.0 in 2003 !!! Intergetic Volinteers wanted .. please apply here........ lotsa fun guaranteed or your money back.... Tom

Dec. 27, 2002

Re: Do not free the header while unmapping the xxxx_UNPREPARE messages

by Dmitry Timoshkov

"Eric Pouech" <eric.pouech(a)wanadoo.fr> wrote: > > Freeing the header while unmapping the 16/32-bit message is an alien task > > for mapping functions IMO. > > since the buffer (the 16 bit segmented to be used instead of the 32bit > linear) has been allocated in the mapping function, I do think it's a > bad idea to free it outside of the unmapping function It seems to me that it's an unnecessary complexity to introduce extra parameter for unmapping function exclusively for xxxx_UNPREPARE messages. Could you please show what you have in mind for the single mapping/unmapping function pair? -- Dmitry.

Dec. 27, 2002

Re: glibc 2.3.1 patch

by Dan Kegel

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

Dec. 27, 2002

Re: Documentation work -task list -man pages

by Tony Lambregts

Tom Wickline wrote: We have decided to continue this discussion in public > I forgot to ask about sections 4-8 on Dimi's ToDo page. http://www.dssd.ca/wine/Wine-0.9-TODO.html > > > 4. Merge documentation/wine.texinfo into the Development Guide [TODO] > 5. Merge documentation/HOWTO-winelib into the Development Guide [TODO] > 6. Do something about > documentation/installation-und-konfiguration.german [TODO] > 7. Do something about documentation/shell32 [TODO] > 8. Do something about documentation/status [TODO] > > Are we going to be doing any work on these sections as well ? > Will your Task List take these sections into account ? I think that we should keep the documentation tasks togetther. If its OK with Dimi we can just use his page and give him diffs or we can split off the documentation section and he can link to it. > > > If our goal is to " Fix incomplete and/or out of date documentation." > Then we should do the Merge as well so everything will be complete. wine.texinfo is like a man page and it seems to be updated fairly well. I don't agree with trying to get rid of it but I am not about to be the one to maintain it either. The wine How-to should be part of wine users. Once it is merged we should get rid of it. I really dont know what to do about installation-und-konfiguration.german. I am inclined to leave it for now > > #7 and #8 I dont fully understand what needs to be done here. > Can you fill me in on what needs to be done with these two ?? From what I can tell these should be incorporated into the wine status page. This seems to be the logical place for them. Most of the files are a year or more old so I would tend to think that they are out of date. Whoever does this will probably need to ask some questions to the developers. In theory Each DLL should have a ToDo list inside the main .c file (or something like that (i can't fine the thread)) a little help here? Having these in documentation is doing neither the users or the developers any good. Again in "theory" someone could grep for "To Do" in wine and get a good idea of the status of that component. > > > Also are we going to be doing any work on man pages ? > If not does Dimi need to add them to this list ? I'm sure if > the web docs are out of date then the man pages need work > as well. > From what I can tell the man pages are the best of the lot. Right now we could use someone "New To Wine" to go through the users guide one chapter at a time and report to us *anything* they don't understand. Anyone is welcome to point out errors and offer any suggestions to help improve the documentation. Of course a patch is even better but if we do not know about a problem we can not fix it. -- Tony Lambregts

Dec. 26, 2002

Old scrolling bug

by Duane Clark

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).

Dec. 26, 2002

[Fwd: wine version]

by Tony Lambregts

-------- 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

Dec. 26, 2002

Re: Changing FS type reported by Wine

by Greg Turner

On Thursday 26 December 2002 10:35 am, Derek Broughton wrote: > Duane Clark wrote: > > Derek Broughton wrote: > >> Windows which _doesn't_ understand the concept of different file > >> systems under a single drive. > Surely from Windows p-o-v _no_ other return values should be > legitimate. Can windows natively read any other types? I don't think > so. Hmm, perhaps not out of the box, but surely, what with reparse-points, DFS, "offline files", hard-links, and other such features, it's not so simple as "fs(root)==fs(arbitrary_subdir(root)) && fs(root) in [fat, ntfs]" in all cases, is it? And then there is support for netware, appletalk, and even nfs.... Also, itsn't it totally possible, even limiting ones self to documented functionality in the DDK, to produce 3rd-party FS drivers and install them (note, that I didn't say easy :) )? The above just covers what you can get from Microsoft... For example, doesn't Oracle provide some FS driver (or perhaps they gave up on that plan...)? Regardless, I don't see anything wrong with the current approach, which could be extended to support NTFS, or some new driver. Getting the emulated FS type from the native FS type seems like a limitation more than a feature to me... or am I missing the idea of this? -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Dec. 26, 2002

Re: wcscmp header? %S format string in ok()?

by Francois Gouget

On Wed, 25 Dec 2002, Dan Kegel wrote: > 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) [...] > 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. It would be better to use strcmpW instead. AFAIK, wcslen will either be the glibc version, i.e. it takes 4 bytes chars, or it is the msvcrt implementation and thus requires that you link with msvcrt.dll. By using strcmpW you will avoid both problems (and many tests already use strlenW which comes from the same place, our wine/unicode.h). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Dec. 26, 2002

Re: Changing FS type reported by Wine

by Derek Broughton

Duane Clark wrote: > Derek Broughton wrote: > >> >> Is it a serious problem using the file system type of the root? This is >> a fairly obscure problem anyway, and if you encountered a problem with a >> specific application you could set up new drive letters for the specific >> file systems you needed. It's a little kludgey, but I don't see it as >> being incompatible with the intent of Wine - after all, while Wine _can_ >> access Unix file systems, and use the features of them, it's providing >> an interface to Windows which _doesn't_ understand the concept of >> different file systems under a single drive. > > > > According to MSDN, "FAT" and "NTFS" are both legitimate return values > for the filesystem name from GetVolumeInformation (though it does not > mention what other possibilities might also be valid). Wine hardcodes > this to always return FAT (or CDROM). Surely from Windows p-o-v _no_ other return values should be legitimate. Can windows natively read any other types? I don't think so. > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/bas… > > > Since it is hardcoded, I don't know how you would "set up new drive > letters for the specific file systems you needed." An option in > ~/.wine/config, on the otherhand, would make this easy. I understand that it _is_ hardcoded, but it seems to me that the simplest solution is to return the value specified in the config file for each drive. As Tony says, if you have drive X: pointing to a directory on one filesystem but whose subtree contains another filesystem, returning the value for the root drive may not always be right, but as I see it, that would be an impossible situation under Windows, so not one that Wine really needs to deal with.

Dec. 26, 2002

Re: Do not free the header while unmapping the xxxx_UNPREPARE messages

by Eric Pouech

> Freeing the header while unmapping the 16/32-bit message is an alien task > for mapping functions IMO. since the buffer (the 16 bit segmented to be used instead of the 32bit linear) has been allocated in the mapping function, I do think it's a bad idea to free it outside of the unmapping function A+ -- Eric Pouech

Dec. 26, 2002

Re: D3D status - bis

by Lionel Ulmer

> I took that as a hint > http://www.telusplanet.net/public/lambregt/wine/d3d_status.html <g> Thanks. Uploaded this new version with some additions... Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 26, 2002

Standard way of printing RECT in trace statements?

by Dan Kegel

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

Dec. 26, 2002

Re: Patch for Spanish keyboard layout

by Jeff Smith

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

Dec. 26, 2002

Re: Re: D3D status - bis

by fenix＠club-internet.fr

----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

Dec. 26, 2002

Re: Do not free the header while unmapping the xxxx_UNPREPARE messages

by Dmitry Timoshkov

"Eric Pouech" <eric.pouech(a)wanadoo.fr> wrote: > I'd rather see the fix being made completely in message16.c by adding > the return value to the unmapping functions This approach doesn't look clean to me. > IMO, it better encapsulates all the 32<=>16 message mappings, and it's > bad to spread this across several compilation unit Freeing the header while unmapping the 16/32-bit message is an alien task for mapping functions IMO. -- Dmitry.

Dec. 25, 2002

Re: D3D status - bis

by Ann and Jason Edmeades

>> 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

Dec. 25, 2002

Re: D3D status - bis

by Tony Lambregts

Lionel Ulmer wrote: >>If any of these are downloadable a url link would be appreciated. >> >> > >I downloaded all of them from GamesDomain.com (it has a nice alphabetical >list of all demos so it should not be that hard for anyone to get them :-) ). > >Note that I am on an 33.6 paid by the minute link here, so if anyone wants >to 're-work' my page to add a lot of links, he is free to do so, I certainly >can't. > > > I took that as a hint http://www.telusplanet.net/public/lambregt/wine/d3d_status.html <g> -- Tony Lambregts

Dec. 25, 2002

Re: D3D status - bis

by Lionel Ulmer

> 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 ;) 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). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 25, 2002

Re: D3D status - bis

by Lionel Ulmer

> If any of these are downloadable a url link would be appreciated. I downloaded all of them from GamesDomain.com (it has a nice alphabetical list of all demos so it should not be that hard for anyone to get them :-) ). Note that I am on an 33.6 paid by the minute link here, so if anyone wants to 're-work' my page to add a lot of links, he is free to do so, I certainly can't. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 25, 2002

Re: Changing FS type reported by Wine

by Tony Lambregts

Derek Broughton wrote: > Tony Lambregts wrote: > >>> >> Well thats a patch that shouldn't go into cvs. <g> If it does "fix" >> the application though then there should be some way for wine to do >> it the "right way". The way I see it there are two ways to do this. >> >> 1.) wine should try to set the fsname to NTFS if underlying file >> system can support files sizes > 4GB. >> >> 2.)There should be a conf file option for NTFS along with MSDOS, unix >> and win95. >> >> The difficulty with wine trying to do this automaticly is that it >> would need to find the file system type of the current directory and >> not the root. This is of course because of the way the unix file >> system works. The current directory could very well be an MSDOS drive >> while the root drive is an ext3 and this function is only aware of >> the root drive. >> >> AFAICS Having it as a config option is easier to implement and >> removes the problem from the developers hands.<g> >> >> For myself I (think I) could implement it as a config option but >> Iwould prefer that wine could deal with it automaticly. If anyone >> has any suggestions I would appreciate it. > > > Is it a serious problem using the file system type of the root? This is > a fairly obscure problem anyway, and if you encountered a problem with a > specific application you could set up new drive letters for the specific > file systems you needed. It's a little kludgey, but I don't see it as > being incompatible with the intent of Wine - after all, while Wine _can_ > access Unix file systems, and use the features of them, it's providing > an interface to Windows which _doesn't_ understand the concept of > different file systems under a single drive. > Right now I am working on a solution that leaves it in the hands of the user (the ~/.wine/confige option). If someone at a latter date wants to implement a dynamic solution that is up to them. After thinking about it I have come to the conclusion that the user should know if the directory that he is writing to is fat or not. The default config option should still be win95 and the documentation should be clear enough that the user will know when to use it. -- Tony Lambregts

Dec. 25, 2002

Re: Changing FS type reported by Wine

by Duane Clark

Derek Broughton wrote: > > Is it a serious problem using the file system type of the root? This is > a fairly obscure problem anyway, and if you encountered a problem with a > specific application you could set up new drive letters for the specific > file systems you needed. It's a little kludgey, but I don't see it as > being incompatible with the intent of Wine - after all, while Wine _can_ > access Unix file systems, and use the features of them, it's providing > an interface to Windows which _doesn't_ understand the concept of > different file systems under a single drive. According to MSDN, "FAT" and "NTFS" are both legitimate return values for the filesystem name from GetVolumeInformation (though it does not mention what other possibilities might also be valid). Wine hardcodes this to always return FAT (or CDROM). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/bas… Since it is hardcoded, I don't know how you would "set up new drive letters for the specific file systems you needed." An option in ~/.wine/config, on the otherhand, would make this easy.

Dec. 25, 2002

Re: D3D status - bis

by Tony Lambregts

Lionel Ulmer wrote: >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 > > > If any of these are downloadable a url link would be appreciated. -- Tony Lambregts

Dec. 25, 2002

Re: Changing FS type reported by Wine

by Derek Broughton

Tony Lambregts wrote: >> > Well thats a patch that shouldn't go into cvs. <g> If it does "fix" the > application though then there should be some way for wine to do it the > "right way". The way I see it there are two ways to do this. > > 1.) wine should try to set the fsname to NTFS if underlying file system > can support files sizes > 4GB. > > 2.)There should be a conf file option for NTFS along with MSDOS, unix > and win95. > > The difficulty with wine trying to do this automaticly is that it would > need to find the file system type of the current directory and not the > root. This is of course because of the way the unix file system works. > The current directory could very well be an MSDOS drive while the root > drive is an ext3 and this function is only aware of the root drive. > > AFAICS Having it as a config option is easier to implement and removes > the problem from the developers hands.<g> > > For myself I (think I) could implement it as a config option but Iwould > prefer that wine could deal with it automaticly. If anyone has any > suggestions I would appreciate it. Is it a serious problem using the file system type of the root? This is a fairly obscure problem anyway, and if you encountered a problem with a specific application you could set up new drive letters for the specific file systems you needed. It's a little kludgey, but I don't see it as being incompatible with the intent of Wine - after all, while Wine _can_ access Unix file systems, and use the features of them, it's providing an interface to Windows which _doesn't_ understand the concept of different file systems under a single drive. derek

Dec. 25, 2002

Re: D3D status - bis

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 25 December 2002 19:54, Lionel Ulmer wrote: > Hi all, Hi > 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 :-) ). 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 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. i will try to test but i have to find where are my old-games CD ;) > The status page is here : > > http://www.bbrox.org/d3d_status.html Raphael > Lionel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Cge8p7NA3AmQTU4RAg85AJ4tnmQDPUIOCVP0bZpaUATZWwWvcgCeLOqU +bBli2+q0MxvmkeHmEFEosM= =OpGc -----END PGP SIGNATURE-----

Dec. 25, 2002

wcscmp header? %S format string in ok()?

by Dan Kegel

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

Dec. 25, 2002

D3D status - bis

by Lionel Ulmer

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/

Dec. 25, 2002

Re: Do not free the header while unmapping the xxxx_UNPREPARE messages

by Eric Pouech

Dmitry Timoshkov wrote: > Hello, > > this patch is aimed to fix crashes in the old 16-bit game, which > calls waveOutUnprepareHeader16 for busy headers. MMDRV_Message > in that case returns WAVERR_STILLPLAYING, but it's not stopping > MMDRV_WaveOut_UnMap16To32A() from freeing the header. Slightly > later game calls waveOutReset16() which crashes. In that case > the duty of freeing the header should be moved to a higher level. > I have generalized this approach to all similar cases. I'd rather see the fix being made completely in message16.c by adding the return value to the unmapping functions IMO, it better encapsulates all the 32<=>16 message mappings, and it's bad to spread this across several compilation unit A+ -- Eric Pouech

Dec. 25, 2002

Re: Wine Contrib v0.4

by Dimitrie O. Paun

On December 25, 2002 03:36 am, Jeff Smith wrote: > I can send a patch if that would be simplest. That'd be good, yes. -- Dimi.

Dec. 25, 2002

Re: Wine Contrib v0.4

by Jeff Smith

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

Dec. 25, 2002

Re: RtlUnicodeStringToInteger prototype missing, and wrong?

by Francois Gouget

On Tue, 24 Dec 2002, Dan Kegel wrote: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/… > says > > "NTSTATUS > RtlUnicodeStringToInteger( > IN PUNICODE_STRING String, > IN ULONG Base OPTIONAL, > OUT PULONG Value > ); > Declared in wdm.h and ntddk.h. Include wdm.h or ntddk.h." > > Shouldn't this be declared in wine/include/winternl.h, like > the other Rtl functions? Microsoft does not declare it in winternl.h. We could create an ntddk.h or a wdm.h header but these are part of the Windows DDK, not the SDK. I'm not sure we have 'public' DDK headers in Wine. > And shouldn't wine/dlls/ntdll/rtlstr.c > declare it to use an unsigned long instead of an int as > its 2nd arg, and an unsigned long * instead of an int * as > its 3rd arg? Yes. Whatever we do for headers, this function's signature should match the one you give above. > If so, I can submit a patch to fix all that, but as I'm > a total wine newbie, I bet there's something I'm missing. Please, go ahead, at least to fix the signature. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Dec. 25, 2002

Re: Set/WindowLong problem in user/win test

by Francois Gouget

On Tue, 24 Dec 2002, Greg Turner wrote: > On Tuesday 24 December 2002 08:23 pm, Francois Gouget wrote: > > On Tue, 24 Dec 2002, Greg Turner wrote: > > > This type of scenario seems to come up a lot lately... perhaps > > > there should be a standard way to detect windows 95 (or another > > > platform) during a test and skip things as may be appropriate on > > > that platform? What do you think? > > > > Tests should *not* check whether they are running on Windows 95, 98 > > or other. Just like individual autoconf-like functionality tests are > > better than relying on __LINUX__ or other macros, tests should check > > for the existence of the functions they want to test. > > Why not, it seems reasonable enough to me? I'm talking about run-time > checks here -- I don't know the API's, but surely there is some > Microsoft-sanctioned way to determine the OS you are running on...? > And as the wine developers, surely we can decide if we are running > under wine... so why is this really so bad, assuming it's implemented > well, in an easy-to-re-use manner. Because it means that the test would have to know that API X is not available on Win95, Win98 and NT4 but that you do have it on Win98 SE, 2000, XP, Win XP 2005 and maybe even on NT4 with SP6. And for API Y it's completely different. And for API Z, it may very well depend on whether you installed IE 5 (and thus upgraded half of the system dlls), or maybe Office 2000 (which upgrades another half of the system dlls). Not to mention what would happen if you install Office 11. Etc, etc, etc. In other words, it would be unreliable and unmaintainable. [...] > Yes, the concept of what is being tested seems to have broadened a bit, > from "test the guts of wine" to "test the guts of wine in a > windows-compatible way," which seems like a good thing to me, btw. I think the intention did not really change from the beginning (at least not for me) but the tests old denomination 'regression tests' was clearly a bad name and may have caused some confusion. Not that the goal is not to test Wine in a 'windows-compatible' way. It's to make sure that Wine _is_ windows compatible, i.e. that its behavior conforms to that of at least one of the Windows platforms. Hence the current 'conformance tests' name. > It hasn't really been an issue, and perhaps it need never be, but, as > you point out, certainly one could imagine scenarios where it's not so > simple as just checking for ERROR_CALL_NOT_IMPLEMENTED: > perhaps there is no such API to call on some platform, or perhaps the > user needs permission to write to some resource that might depend on > the user's permission on the particular machine... who knows? Yes some things may not always be testable. Creating users in a domain for instance. Even something as simple as 'testing sounds' cannot be tested if there is no soundcard. However I doubt these will represent any significant portion of the conformance tests. And the current sound tests show how to deal with such cases: they enumerate the soundcards and if there's none, well then no further test is performed (note that the enumeration is still tested). Merry Christmas -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Dec. 25, 2002

RtlUnicodeStringToInteger prototype missing, and wrong?

by Dan Kegel

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/… says "NTSTATUS RtlUnicodeStringToInteger( IN PUNICODE_STRING String, IN ULONG Base OPTIONAL, OUT PULONG Value ); Declared in wdm.h and ntddk.h. Include wdm.h or ntddk.h." Shouldn't this be declared in wine/include/winternl.h, like the other Rtl functions? And shouldn't wine/dlls/ntdll/rtlstr.c declare it to use an unsigned long instead of an int as its 2nd arg, and an unsigned long * instead of an int * as its 3rd arg? If so, I can submit a patch to fix all that, but as I'm a total wine newbie, I bet there's something I'm missing. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 25, 2002