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. 26, 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. 26, 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. 26, 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. 26, 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. 26, 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. 26, 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. 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: > > 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. 26, 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. 26, 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. 25, 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. 25, 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. 25, 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

Re: Set/WindowLong problem in user/win test

by Greg Turner

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. > So the best way to handle A/W issues is to just call the function and > check for failure with the ERROR_CALL_NOT_IMPLEMENTED error. If that > happens then the check(s) should be skipped. Similarly, the way to > deal with APIs that only exist on some platforms is to use > LoadLibrary and GetProcAddress. If the resulting pointer is NULL, > then skip the test(s). It may even make sense to do so in cases where > the whole library may be missing (kind of depends on the impact of > missing libraries on automated runs: does it stop the batch file with > a messagebox?). > > The real issue is that up until now all tests have been written using > Wine and never tested in Windows. Or if they were actually tested in > Windows they were only tested with one version of Windows and one > quickly finds whether that was Win9x or an NT-something. 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. 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? Testing a big system like wine which goes pretty deep into the architectural roots, and all the way up to big honkin' "assemblies" (or what-have-you's) like the java virtual machine or directx... there could be a lot of circumstances where the outcome might not be reliable but we don't want to drop the test out of the default testrun... this is precisely why it seems that being able to rule out 90% of such cases with a simple "what environment do I run under?" test seems like a win... but perhaps you have thought this through more carefully than I? Am I missing something? Merry Christmas, and thanks for all the great code and hard work, -- 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. 24, 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 03:23 pm, Francois Gouget wrote: > > This test uses {Get,Set}WindowLongW which of course does not work on > > Win9x, thus causing the test to fail. > > 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. So the best way to handle A/W issues is to just call the function and check for failure with the ERROR_CALL_NOT_IMPLEMENTED error. If that happens then the check(s) should be skipped. Similarly, the way to deal with APIs that only exist on some platforms is to use LoadLibrary and GetProcAddress. If the resulting pointer is NULL, then skip the test(s). It may even make sense to do so in cases where the whole library may be missing (kind of depends on the impact of missing libraries on automated runs: does it stop the batch file with a messagebox?). The real issue is that up until now all tests have been written using Wine and never tested in Windows. Or if they were actually tested in Windows they were only tested with one version of Windows and one quickly finds whether that was Win9x or an NT-something. But now that it's easy to compile and run these tests on Windows this problem should pretty much disappear (or rather tests will be fixed as they come rather than accumulate). It has been some time since I last updated the zip file that contains the windows test executables as I tried to focus on actually fixing the tests. Now that some progress has been made I'll try to put something together in the comming days. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Dec. 24, 2002

Re: Validate imagelists

by Andreas Mohr

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

Dec. 24, 2002

Re: Some D3D status updates...

by Chris Thielen

Awesome work so far! Keep it up, I can't wait for a more complete D3D in Wine. On Tue, 2002-12-24 at 10:33, Lionel Ulmer wrote: > 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 :-) ) -- Chris Thielen <chris(a)luethy.net>

Dec. 24, 2002

Re: Set/WindowLong problem in user/win test

by Greg Turner

On Tuesday 24 December 2002 03:23 pm, Francois Gouget wrote: > This test uses {Get,Set}WindowLongW which of course does not work on > Win9x, thus causing the test to fail. 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? -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. 24, 2002

Re: [JOY] wxWindows

by David Fraser

Dimitrie O. Paun wrote: >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: > Excellent news! > -- 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. > I'd be very interested in this, as I use wxWindows alot in my work... This means we can try compile our app like this (it already kind of works using wxGTK, but this will be interesting too) Thanks a lot... David

Dec. 24, 2002

Re: [JOY] wxWindows

by Dimitrie O. Paun

On December 24, 2002 04:36 pm, David Fraser wrote: > I'd be very interested in this, as I use wxWindows alot in my work... OK, here are the _raw_ modifications that I had to make. All trivially fixable also (waiting on the __WINE__ decision). Look for example to the makeg95.env changes to see how few were needed! Here's the diff (against latest wxWindows CVS). Index: include/wx/filefn.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/filefn.h,v retrieving revision 1.63 diff -u -r1.63 filefn.h --- include/wx/filefn.h 2002/12/07 15:41:11 1.63 +++ include/wx/filefn.h 2002/12/24 22:17:25 @@ -74,9 +74,9 @@ // ---------------------------------------------------------------------------- // Microsoft compiler loves underscores, feed them to it -#if defined( __VISUALC__ ) \ +#if 0 && (defined( __VISUALC__ ) \ || ( defined(__MINGW32__) && wxCHECK_W32API_VERSION( 0, 5 ) ) \ - || ( defined(__MWERKS__) && defined(__WXMSW__) ) + || ( defined(__MWERKS__) && defined(__WXMSW__) )) // functions #define wxClose _close #define wxRead _read Index: include/wx/sckaddr.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/sckaddr.h,v retrieving revision 1.16 diff -u -r1.16 sckaddr.h --- include/wx/sckaddr.h 2002/08/31 11:29:11 1.16 +++ include/wx/sckaddr.h 2002/12/24 22:17:26 @@ -102,7 +102,7 @@ #endif #if defined(__UNIX__) && (!defined(__WXMAC__) || defined(__DARWIN__)) -#include <sys/socket.h> +//#include <sys/socket.h> #ifndef __VMS__ # include <sys/un.h> #endif Index: include/wx/wxchar.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/wxchar.h,v retrieving revision 1.102 diff -u -r1.102 wxchar.h --- include/wx/wxchar.h 2002/12/10 00:43:24 1.102 +++ include/wx/wxchar.h 2002/12/24 22:17:27 @@ -248,6 +248,7 @@ // it in Unicode build as well // ---------------------------------------------------------------------------- +#undef wxHAVE_TCHAR_SUPPORT #ifdef wxHAVE_TCHAR_SUPPORT #include <ctype.h> Index: include/wx/msw/gccpriv.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/msw/gccpriv.h,v retrieving revision 1.6 diff -u -r1.6 gccpriv.h --- include/wx/msw/gccpriv.h 2001/08/02 19:02:17 1.6 +++ include/wx/msw/gccpriv.h 2002/12/24 22:17:28 @@ -48,6 +48,7 @@ // Mingw runtime 1.0-20010604 has some missing _tXXXX functions, // so let's define them ourselves: +#include <tchar.h> #if defined(__GNUWIN32__) && wxCHECK_W32API_VERSION( 1, 0 ) #ifndef _tsetlocale #if wxUSE_UNICODE Index: include/wx/msw/gnuwin32/extra.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/msw/gnuwin32/extra.h,v retrieving revision 1.8 diff -u -r1.8 extra.h --- include/wx/msw/gnuwin32/extra.h 2001/06/08 15:03:59 1.8 +++ include/wx/msw/gnuwin32/extra.h 2002/12/24 22:17:29 @@ -3,7 +3,7 @@ * have (B18/B19). */ -#ifndef _WX_EXTRAH_ +#if 0 #define _WX_EXTRAH_ #ifndef __CYGWIN10__ Index: include/wx/msw/gnuwin32/winresrc.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/msw/gnuwin32/winresrc.h,v retrieving revision 1.2 diff -u -r1.2 winresrc.h --- include/wx/msw/gnuwin32/winresrc.h 1999/01/19 18:20:15 1.2 +++ include/wx/msw/gnuwin32/winresrc.h 2002/12/24 22:17:32 @@ -1409,12 +1409,12 @@ -#ifdef UNICODE -#define __TEXT(quote) L##quote -#else /* UNICODE */ -#define __TEXT(quote) quote -#endif /* UNICODE */ -#define TEXT(quote) __TEXT(quote) +#ifdef UNICODE +#define __TEXT(quote) L##quote +#else +#define __TEXT(quote) quote +#endif +#define TEXT(quote) __TEXT(quote) // // Language IDs. Index: samples/makefile.g95 =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/samples/makefile.g95,v retrieving revision 1.16 diff -u -r1.16 makefile.g95 --- samples/makefile.g95 2002/04/12 13:15:44 1.16 +++ samples/makefile.g95 2002/12/24 22:17:32 @@ -17,7 +17,7 @@ THISDIR=$(WXDIR)/samples MAKEFILE=makefile.g95 MAKEFLAGS=WXUSINGDLL=$(WXUSINGDLL) UNICODE=$(UNICODE) -CMDLINE=-f $(MAKEFILE) $(MAKEFLAGS) +CMDLINE=-s -f $(MAKEFILE) $(MAKEFLAGS) # Mingw make may not have a shell to use, so can't use a loop here. Sigh. # Please add new sample directories alphabetically to make it easier to Index: src/makeg95.env =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/makeg95.env,v retrieving revision 1.73 diff -u -r1.73 makeg95.env --- src/makeg95.env 2002/12/18 08:33:27 1.73 +++ src/makeg95.env 2002/12/24 22:17:37 @@ -22,7 +22,7 @@ # use forward slashes, we need to set this when # invoking the makefile from DOS, or the wrong separators # will be assumed. -#OSTYPE=msys +OSTYPE=msys # If building DLL, the version WXVERSION=250 @@ -81,6 +81,7 @@ else CC = gcc endif +CC=winegcc # C compiler for pure C programs CCC = $(CC) @@ -102,7 +103,7 @@ # Settings for Cyginw/Mingw32 # Some versions of windres cannot cope with the --preprocessor # option. Uncomment the RCPREPROCESSOR line below if yours can. -RESCOMP=windres +RESCOMP=wrc RCINPUTSWITCH=-i RCOUTPUTSWITCH=-o RCINCSWITCH=--include-dir @@ -125,7 +126,7 @@ # Miscellaneous compiler options # GRG: the __MINGW32__ option is not needed anymore # add "-DHAVE_W32API_H" if you have w32api >= 0.5 -OPTIONS = -DSTRICT # -D__MINGW32__ +OPTIONS = -DSTRICT -DwxSIZE_T_IS_UINT -DHAVE_W32API_H -D__MINGW32__ -D_FORCENAMELESSUNION # Add "-mthreads" if you want to have threads under mingw32 COMMON_THREADFLAGS = @@ -198,12 +199,12 @@ ########################## Directories ############################### -OLELIBS=-lole32 -loleaut32 -luuid +OLELIBS=-lole32 -loleaut32 /usr/local/lib/libwine_uuid.a BASELIBS=-lstdc++ -lgcc -lodbc32 -lwsock32 ifeq ($(wxUSE_GUI),1) WINLIBS= $(BASELIBS) \ -lwinspool -lwinmm -lshell32 \ - -lcomctl32 -lctl3d32 -lodbc32 -ladvapi32 \ + -lcomctl32 -lcomdlg32 -lodbc32 -ladvapi32 \ -lodbc32 -lwsock32 -lopengl32 -lglu32 $(OLELIBS) # -loldnames else WINLIBS=$(BASELIBS) @@ -238,7 +239,7 @@ # png, jpeg, etc are exported from wx dll, so skip and save on link time. LIBS = $(EXTRALIBS) $(WXLIB) $(WINLIBS) $(COMPLIBS) else - LIBS = $(EXTRALIBS) $(WXLIB) -lregex -lpng -ljpeg -lzlib -ltiff $(WINLIBS) $(COMPLIBS) + LIBS = $(EXTRALIBS) $(WXLIB) /home/dimi/dev/wine/wxWindows/lib/libregex.a /home/dimi/dev/wine/wxWindows/lib/libpng.a /home/dimi/dev/wine/wxWindows/lib/libjpeg.a /home/dimi/dev/wine/wxWindows/lib/libzlib.a /home/dimi/dev/wine/wxWindows/lib/libtiff.a $(WINLIBS) $(COMPLIBS) endif WINFLAGS=-D_X86_=1 -DWIN32 -D_WIN32 $(WINVERSION) Index: src/common/datetime.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/datetime.cpp,v retrieving revision 1.71 diff -u -r1.71 datetime.cpp --- src/common/datetime.cpp 2002/12/04 14:06:21 1.71 +++ src/common/datetime.cpp 2002/12/24 22:17:42 @@ -286,7 +286,8 @@ #ifdef WX_GMTOFF_IN_TM return (int)gmtoffset; #else - return (int)WX_TIMEZONE; + //return (int)WX_TIMEZONE; + return LONG_MAX; #endif } Index: src/common/dynarray.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/dynarray.cpp,v retrieving revision 1.28 diff -u -r1.28 dynarray.cpp --- src/common/dynarray.cpp 2002/12/04 14:06:27 1.28 +++ src/common/dynarray.cpp 2002/12/24 22:17:43 @@ -28,6 +28,7 @@ #include <stdlib.h> #include <string.h> // for memmove +#include <search.h> #ifndef max #define max(a, b) (((a) > (b)) ? (a) : (b)) Index: src/common/encconv.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/encconv.cpp,v retrieving revision 1.14 diff -u -r1.14 encconv.cpp --- src/common/encconv.cpp 2002/01/25 14:45:20 1.14 +++ src/common/encconv.cpp 2002/12/24 22:17:44 @@ -23,6 +23,7 @@ #include "wx/encconv.h" #include <stdlib.h> +#include <search.h> // conversion tables, generated by scripts in $(WXWIN)/misc/unictabl: #ifdef __BORLANDC__ Index: src/common/filefn.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/filefn.cpp,v retrieving revision 1.161 diff -u -r1.161 filefn.cpp --- src/common/filefn.cpp 2002/12/10 21:44:08 1.161 +++ src/common/filefn.cpp 2002/12/24 22:17:49 @@ -1258,7 +1258,7 @@ // assume mkdir() has 2 args on non Windows-OS/2 platforms and on Windows too // for the GNU compiler -#if (!(defined(__WXMSW__) || defined(__WXPM__) || defined(__DOS__))) || (defined(__GNUWIN32__) && !defined(__MINGW32__)) || defined(__WXWINE__) || defined(__WXMICROWIN__) +#if 1 || (!(defined(__WXMSW__) || defined(__WXPM__) || defined(__DOS__))) || (defined(__GNUWIN32__) && !defined(__MINGW32__)) || defined(__WXWINE__) || defined(__WXMICROWIN__) if ( mkdir(wxFNCONV(dirname), perm) != 0 ) #elif defined(__WXPM__) if (::DosCreateDir((PSZ)dirname, NULL) != 0) // enhance for EAB's?? Index: src/common/filename.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/filename.cpp,v retrieving revision 1.101 diff -u -r1.101 filename.cpp --- src/common/filename.cpp 2002/12/04 14:06:32 1.101 +++ src/common/filename.cpp 2002/12/24 22:17:51 @@ -99,7 +99,7 @@ #include <sys/types.h> #include <utime.h> #include <sys/stat.h> -#include <unistd.h> +//#include <unistd.h> #endif #ifdef __DJGPP__ Index: src/common/list.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/list.cpp,v retrieving revision 1.38 diff -u -r1.38 list.cpp --- src/common/list.cpp 2002/02/06 01:38:08 1.38 +++ src/common/list.cpp 2002/12/24 22:17:52 @@ -31,6 +31,7 @@ #include <stdarg.h> #include <stdlib.h> #include <string.h> +#include <search.h> #ifndef WX_PRECOMP #include "wx/defs.h" Index: src/common/mimecmn.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/mimecmn.cpp,v retrieving revision 1.23 diff -u -r1.23 mimecmn.cpp --- src/common/mimecmn.cpp 2002/12/04 14:06:45 1.23 +++ src/common/mimecmn.cpp 2002/12/24 22:17:53 @@ -486,7 +486,7 @@ bool wxMimeTypesManager::Unassociate(wxFileType *ft) { -#if defined(__UNIX__) && !defined(__WXPM__) && !defined(__CYGWIN__) && !defined(__WXWINE__) +#if 0 && defined(__UNIX__) && !defined(__WXPM__) && !defined(__CYGWIN__) && !defined(__WXWINE__) return m_impl->Unassociate(ft); #else return ft->Unassociate(); @@ -596,7 +596,7 @@ void wxMimeTypesManager::Initialize(int mcapStyle, const wxString& sExtraDir) { -#if defined(__UNIX__) && !defined(__WXPM__) && !defined(__CYGWIN__) && !defined(__WXWINE__) +#if 0 && defined(__UNIX__) && !defined(__WXPM__) && !defined(__CYGWIN__) && !defined(__WXWINE__) EnsureImpl(); m_impl->Initialize(mcapStyle, sExtraDir); @@ -609,7 +609,7 @@ // and this function clears all the data from the manager void wxMimeTypesManager::ClearData() { -#if defined(__UNIX__) && !defined(__WXPM__) && !defined(__CYGWIN__) && !defined(__WXWINE__) +#if 0 && defined(__UNIX__) && !defined(__WXPM__) && !defined(__CYGWIN__) && !defined(__WXWINE__) EnsureImpl(); m_impl->ClearData(); Index: src/common/string.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/string.cpp,v retrieving revision 1.166 diff -u -r1.166 string.cpp --- src/common/string.cpp 2002/12/10 12:13:23 1.166 +++ src/common/string.cpp 2002/12/24 22:17:55 @@ -41,6 +41,7 @@ #include <ctype.h> #include <string.h> #include <stdlib.h> +#include <search.h> #ifdef __SALFORDC__ #include <clib.h> Index: src/common/wxchar.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/common/wxchar.cpp,v retrieving revision 1.51 diff -u -r1.51 wxchar.cpp --- src/common/wxchar.cpp 2002/12/10 00:43:28 1.51 +++ src/common/wxchar.cpp 2002/12/24 22:17:57 @@ -105,7 +105,7 @@ bool WXDLLEXPORT wxOKlibc() { -#if wxUSE_WCHAR_T && defined(__UNIX__) && defined(__GLIBC__) +#if 0 && wxUSE_WCHAR_T && defined(__UNIX__) && defined(__GLIBC__) // glibc 2.0 uses UTF-8 even when it shouldn't wchar_t res = 0; if ((MB_CUR_MAX == 2) && Index: src/jpeg/jmorecfg.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/jpeg/jmorecfg.h,v retrieving revision 1.19 diff -u -r1.19 jmorecfg.h --- src/jpeg/jmorecfg.h 2002/05/26 11:49:37 1.19 +++ src/jpeg/jmorecfg.h 2002/12/24 22:17:58 @@ -130,6 +130,7 @@ */ /* UINT8 must hold at least the values 0..255. */ +#ifndef __WINE_BASETSD_H #ifdef HAVE_UNSIGNED_CHAR typedef unsigned char UINT8; @@ -154,6 +155,8 @@ #ifndef XMD_H /* X11/xmd.h correctly defines INT16 */ typedef short INT16; #endif + +#endif /* __WINE_BASETSD_H */ /* INT32 must hold at least signed 32-bit values. */ Index: src/msw/app.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/msw/app.cpp,v retrieving revision 1.174 diff -u -r1.174 app.cpp --- src/msw/app.cpp 2002/12/04 14:09:06 1.174 +++ src/msw/app.cpp 2002/12/24 22:18:01 @@ -1382,5 +1382,5 @@ // For some reason, with MSVC++ 1.5, WinMain isn't linked in properly // if in a separate file. So include it here to ensure it's linked. #if (defined(__VISUALC__) && !defined(__WIN32__)) || (defined(__GNUWIN32__) && !defined(__TWIN32__) && !defined(WXMAKINGDLL)) -#include "main.cpp" +//#include "main.cpp" #endif Index: src/msw/dialup.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/msw/dialup.cpp,v retrieving revision 1.34 diff -u -r1.34 dialup.cpp --- src/msw/dialup.cpp 2002/08/30 20:34:25 1.34 +++ src/msw/dialup.cpp 2002/12/24 22:18:02 @@ -50,7 +50,7 @@ // Doesn't yet compile under VC++ 4, BC++, Watcom C++, // Wine: no wininet.h -#if !defined(__BORLANDC__) && \ +#if 0 && !defined(__BORLANDC__) && \ (!defined(__GNUWIN32__) || wxCHECK_W32API_VERSION(0, 5)) && \ !defined(__GNUWIN32_OLD__) && \ !defined(__WATCOMC__) && \ Index: src/msw/gsocket.c =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/msw/gsocket.c,v retrieving revision 1.42 diff -u -r1.42 gsocket.c --- src/msw/gsocket.c 2002/12/06 16:57:30 1.42 +++ src/msw/gsocket.c 2002/12/24 22:18:04 @@ -11,6 +11,8 @@ * PLEASE don't put C++ comments here - this is a C source file. */ +#include <winsock.h> + #ifdef _MSC_VER /* RPCNOTIFICATION_ROUTINE in rasasync.h (included from winsock.h), * warning: conditional expression is constant. @@ -55,8 +57,6 @@ #include <stdlib.h> #include <stddef.h> #include <ctype.h> - -#include <winsock.h> /* if we use configure for MSW SOCKLEN_T will be already defined */ #ifndef SOCKLEN_T Index: src/msw/utils.cpp =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/msw/utils.cpp,v retrieving revision 1.102 diff -u -r1.102 utils.cpp --- src/msw/utils.cpp 2002/12/07 00:58:11 1.102 +++ src/msw/utils.cpp 2002/12/24 22:18:06 @@ -47,6 +47,7 @@ #endif #include "wx/timer.h" +#include <unistd.h> #if !defined(__GNUWIN32__) && !defined(__WXWINE__) && !defined(__SALFORDC__) && !defined(__WXMICROWIN__) #include <direct.h> Index: src/png/pngconf.h =================================================================== RCS file: /pack/cvsroots/wxwindows/wxWindows/src/png/pngconf.h,v retrieving revision 1.7 diff -u -r1.7 pngconf.h --- src/png/pngconf.h 2002/12/04 14:10:03 1.7 +++ src/png/pngconf.h 2002/12/24 22:18:08 @@ -1157,9 +1157,10 @@ # endif #endif -#if defined(__CYGWIN__) +#if 1 || defined(__CYGWIN__) # undef PNGAPI -# define PNGAPI __cdecl +//# define PNGAPI __cdecl +# define PNGAPI # undef PNG_IMPEXP # define PNG_IMPEXP #endif -- Dimi.

Dec. 24, 2002

Set/WindowLong problem in user/win test

by Francois Gouget

This test uses {Get,Set}WindowLongW which of course does not work on Win9x, thus causing the test to fail. I guess part of the goal is to check that mixing Ansi calls (CreatewindowExA) with Unicode calls works. So I wrote a function test_set_window_long function that calls SetWindowLongW and then SetWindowLongA and checks that their results match but that causes the test to fail (at least on NT4 and Wine). More precisely even if all this function does is the following, then the test fails: { LONG rc=SetWindowLongA(hwnd,nIndex,dwNewLong); SetWindowLongA(hwnd,nIndex,dwNewLong); return rc; } Comment out the second SetWindowLongA and it works. Why would calling SetWindowLong a second time make any difference? Here's the full patch, just change '#if 0' into '#if 1' to make the test fail. Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.5 diff -u -r1.5 win.c --- dlls/user/tests/win.c 15 Nov 2002 00:02:51 -0000 1.5 +++ dlls/user/tests/win.c 24 Dec 2002 03:16:36 -0000 @@ -45,6 +45,47 @@ static HWND hwndMain, hwndMain2; +static LONG test_set_window_long(HWND hwnd, int nIndex, LONG dwNewLong) +{ + LONG rc; + + SetLastError(0); + rc=SetWindowLongW(hwnd,nIndex,dwNewLong); + if (rc==0 && GetLastError()==ERROR_CALL_NOT_IMPLEMENTED) { + rc=SetWindowLongA(hwnd,nIndex,dwNewLong); + } +#if 0 + else { + LONG set,get; + get=GetWindowLongW(hwnd,nIndex); + set=SetWindowLongA(hwnd,nIndex,dwNewLong); + ok(set==get, + "SetWindowLongA/W(%ld) failed: got %ld, expected %ld\n", + dwNewLong,set,get); + } +#endif + return rc; +} + +static LONG test_get_window_long(HWND hwnd, int nIndex) +{ + LONG rc; + + SetLastError(0); + rc=GetWindowLongW(hwnd,nIndex); + if (rc==0 && GetLastError()==ERROR_CALL_NOT_IMPLEMENTED) { + rc=GetWindowLongA(hwnd,nIndex); + } else { + LONG rcA; + SetLastError(0); + rcA=GetWindowLongA(hwnd,nIndex); + ok(rc==rcA, + "GetWindowLongW failed: got %ld, expected %ld\n", + rc,rcA); + } + return rc; +} + /* check the values returned by the various parent/owner functions on a given window */ static void check_parents( HWND hwnd, HWND ga_parent, HWND gwl_parent, HWND get_parent, HWND gw_owner, HWND ga_root, HWND ga_root_owner ) @@ -56,7 +97,7 @@ res = pGetAncestor( hwnd, GA_PARENT ); ok( res == ga_parent, "Wrong result for GA_PARENT %p expected %p", res, ga_parent ); } - res = (HWND)GetWindowLongW( hwnd, GWL_HWNDPARENT ); + res = (HWND)test_get_window_long( hwnd, GWL_HWNDPARENT ); ok( res == gwl_parent, "Wrong result for GWL_HWNDPARENT %p expected %p", res, gwl_parent ); res = GetParent( hwnd ); ok( res == get_parent, "Wrong result for GetParent %p expected %p", res, get_parent ); @@ -97,31 +138,31 @@ /* desktop window */ check_parents( desktop, 0, 0, 0, 0, 0, 0 ); - style = GetWindowLongW( desktop, GWL_STYLE ); - ok( !SetWindowLongW( desktop, GWL_STYLE, WS_POPUP ), "Set GWL_STYLE on desktop succeeded" ); - ok( !SetWindowLongW( desktop, GWL_STYLE, 0 ), "Set GWL_STYLE on desktop succeeded" ); - ok( GetWindowLongW( desktop, GWL_STYLE ) == style, "Desktop style changed" ); + style = test_get_window_long( desktop, GWL_STYLE ); + ok( !SetWindowLongA( desktop, GWL_STYLE, WS_POPUP ), "Set GWL_STYLE on desktop succeeded" ); + ok( !SetWindowLongA( desktop, GWL_STYLE, 0 ), "Set GWL_STYLE on desktop succeeded" ); + ok( test_get_window_long( desktop, GWL_STYLE ) == style, "Desktop style changed" ); /* normal child window */ test = create_tool_window( WS_CHILD, hwndMain ); trace( "created child %p\n", test ); check_parents( test, hwndMain, hwndMain, hwndMain, 0, hwndMain, hwndMain ); - SetWindowLongW( test, GWL_STYLE, 0 ); + test_set_window_long( test, GWL_STYLE, 0 ); check_parents( test, hwndMain, hwndMain, 0, 0, hwndMain, test ); - SetWindowLongW( test, GWL_STYLE, WS_POPUP ); + test_set_window_long( test, GWL_STYLE, WS_POPUP ); check_parents( test, hwndMain, hwndMain, 0, 0, hwndMain, test ); - SetWindowLongW( test, GWL_STYLE, WS_POPUP|WS_CHILD ); + test_set_window_long( test, GWL_STYLE, WS_POPUP|WS_CHILD ); check_parents( test, hwndMain, hwndMain, 0, 0, hwndMain, test ); - SetWindowLongW( test, GWL_STYLE, WS_CHILD ); + test_set_window_long( test, GWL_STYLE, WS_CHILD ); DestroyWindow( test ); /* child of desktop */ test = create_tool_window( WS_CHILD, desktop ); trace( "created child of desktop %p\n", test ); check_parents( test, desktop, 0, desktop, 0, test, desktop ); - SetWindowLongW( test, GWL_STYLE, WS_POPUP ); + test_set_window_long( test, GWL_STYLE, WS_POPUP ); check_parents( test, desktop, 0, 0, 0, test, test ); - SetWindowLongW( test, GWL_STYLE, 0 ); + test_set_window_long( test, GWL_STYLE, 0 ); check_parents( test, desktop, 0, 0, 0, test, test ); DestroyWindow( test ); @@ -129,9 +170,9 @@ test = create_tool_window( WS_CHILD, child ); trace( "created child of child %p\n", test ); check_parents( test, child, child, child, 0, hwndMain, hwndMain ); - SetWindowLongW( test, GWL_STYLE, 0 ); + test_set_window_long( test, GWL_STYLE, 0 ); check_parents( test, child, child, 0, 0, hwndMain, test ); - SetWindowLongW( test, GWL_STYLE, WS_POPUP ); + test_set_window_long( test, GWL_STYLE, WS_POPUP ); check_parents( test, child, child, 0, 0, hwndMain, test ); DestroyWindow( test ); @@ -139,9 +180,9 @@ test = create_tool_window( 0, 0 ); trace( "created top-level %p\n", test ); check_parents( test, desktop, 0, 0, 0, test, test ); - SetWindowLongW( test, GWL_STYLE, WS_POPUP ); + test_set_window_long( test, GWL_STYLE, WS_POPUP ); check_parents( test, desktop, 0, 0, 0, test, test ); - SetWindowLongW( test, GWL_STYLE, WS_CHILD ); + test_set_window_long( test, GWL_STYLE, WS_CHILD ); check_parents( test, desktop, 0, desktop, 0, test, desktop ); DestroyWindow( test ); @@ -149,9 +190,9 @@ test = create_tool_window( 0, hwndMain ); trace( "created owned top-level %p\n", test ); check_parents( test, desktop, hwndMain, 0, hwndMain, test, test ); - SetWindowLongW( test, GWL_STYLE, WS_POPUP ); + test_set_window_long( test, GWL_STYLE, WS_POPUP ); check_parents( test, desktop, hwndMain, hwndMain, hwndMain, test, hwndMain ); - SetWindowLongW( test, GWL_STYLE, WS_CHILD ); + test_set_window_long( test, GWL_STYLE, WS_CHILD ); check_parents( test, desktop, hwndMain, desktop, hwndMain, test, desktop ); DestroyWindow( test ); @@ -159,9 +200,9 @@ test = create_tool_window( WS_POPUP, 0 ); trace( "created popup %p\n", test ); check_parents( test, desktop, 0, 0, 0, test, test ); - SetWindowLongW( test, GWL_STYLE, WS_CHILD ); + test_set_window_long( test, GWL_STYLE, WS_CHILD ); check_parents( test, desktop, 0, desktop, 0, test, desktop ); - SetWindowLongW( test, GWL_STYLE, 0 ); + test_set_window_long( test, GWL_STYLE, 0 ); check_parents( test, desktop, 0, 0, 0, test, test ); DestroyWindow( test ); @@ -169,9 +210,9 @@ test = create_tool_window( WS_POPUP, hwndMain ); trace( "created owned popup %p\n", test ); check_parents( test, desktop, hwndMain, hwndMain, hwndMain, test, hwndMain ); - SetWindowLongW( test, GWL_STYLE, WS_CHILD ); + test_set_window_long( test, GWL_STYLE, WS_CHILD ); check_parents( test, desktop, hwndMain, desktop, hwndMain, test, desktop ); - SetWindowLongW( test, GWL_STYLE, 0 ); + test_set_window_long( test, GWL_STYLE, 0 ); check_parents( test, desktop, hwndMain, 0, hwndMain, test, test ); DestroyWindow( test ); @@ -210,7 +251,7 @@ /* desktop window */ check_parents( desktop, 0, 0, 0, 0, 0, 0 ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); ok( !ret, "Set GWL_HWNDPARENT succeeded on desktop" ); check_parents( desktop, 0, 0, 0, 0, 0, 0 ); ok( !SetParent( desktop, hwndMain ), "SetParent succeeded on desktop" ); @@ -220,24 +261,24 @@ test = create_tool_window( WS_CHILD, hwndMain ); trace( "created child %p\n", test ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); ok( ret == hwndMain, "GWL_HWNDPARENT return value %p expected %p", ret, hwndMain ); check_parents( test, hwndMain2, hwndMain2, hwndMain2, 0, hwndMain2, hwndMain2 ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)child ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)child ); ok( ret == hwndMain2, "GWL_HWNDPARENT return value %p expected %p", ret, hwndMain2 ); check_parents( test, child, child, child, 0, hwndMain, hwndMain ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)desktop ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)desktop ); ok( ret == child, "GWL_HWNDPARENT return value %p expected %p", ret, child ); check_parents( test, desktop, 0, desktop, 0, test, desktop ); /* window is now child of desktop so GWL_HWNDPARENT changes owner from now on */ - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)child ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)child ); ok( ret == 0, "GWL_HWNDPARENT return value %p expected 0", ret ); check_parents( test, desktop, child, desktop, child, test, desktop ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, 0 ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, 0 ); ok( ret == child, "GWL_HWNDPARENT return value %p expected %p", ret, child ); check_parents( test, desktop, 0, desktop, 0, test, desktop ); DestroyWindow( test ); @@ -246,15 +287,15 @@ test = create_tool_window( 0, 0 ); trace( "created top-level %p\n", test ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); ok( ret == 0, "GWL_HWNDPARENT return value %p expected 0", ret ); check_parents( test, desktop, hwndMain2, 0, hwndMain2, test, test ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)child ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)child ); ok( ret == hwndMain2, "GWL_HWNDPARENT return value %p expected %p", ret, hwndMain2 ); check_parents( test, desktop, child, 0, child, test, test ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, 0 ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, 0 ); ok( ret == child, "GWL_HWNDPARENT return value %p expected %p", ret, child ); check_parents( test, desktop, 0, 0, 0, test, test ); DestroyWindow( test ); @@ -263,15 +304,15 @@ test = create_tool_window( WS_POPUP, 0 ); trace( "created popup %p\n", test ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)hwndMain2 ); ok( ret == 0, "GWL_HWNDPARENT return value %p expected 0", ret ); check_parents( test, desktop, hwndMain2, hwndMain2, hwndMain2, test, hwndMain2 ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (LONG_PTR)child ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (LONG_PTR)child ); ok( ret == hwndMain2, "GWL_HWNDPARENT return value %p expected %p", ret, hwndMain2 ); check_parents( test, desktop, child, child, child, test, hwndMain ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, 0 ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, 0 ); ok( ret == child, "GWL_HWNDPARENT return value %p expected %p", ret, child ); check_parents( test, desktop, 0, 0, 0, test, test ); DestroyWindow( test ); @@ -310,7 +351,7 @@ ok( ret == desktop, "SetParent return value %p expected %p", ret, desktop ); check_parents( test, child, child, hwndMain2, hwndMain2, hwndMain, hwndMain2 ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (ULONG_PTR)hwndMain ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (ULONG_PTR)hwndMain ); ok( ret == child, "GWL_HWNDPARENT return value %p expected %p", ret, child ); check_parents( test, hwndMain, hwndMain, hwndMain2, hwndMain2, hwndMain, hwndMain2 ); DestroyWindow( test ); @@ -343,7 +384,7 @@ owner = create_tool_window( WS_CHILD, hwndMain2 ); test = create_tool_window( WS_POPUP, 0 ); trace( "created owner %p and popup %p\n", owner, test ); - ret = (HWND)SetWindowLongW( test, GWL_HWNDPARENT, (ULONG_PTR)owner ); + ret = (HWND)test_set_window_long( test, GWL_HWNDPARENT, (ULONG_PTR)owner ); ok( ret == 0, "GWL_HWNDPARENT return value %p expected 0", ret ); check_parents( test, desktop, owner, owner, owner, test, hwndMain2 ); DestroyWindow( owner ); -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Dec. 24, 2002

Re: __WINE__ vs. __WINESRC__

by Dimitrie O. Paun

On December 22, 2002 03:04 pm, Francois Gouget wrote: > But I'm open to change, '__WINE__' looks more like the others. Maybe > '__WINELIB__' would do? (but I prefer '__WINE__') Alexandre, what do you think? I'd like to have winegcc define this by default, but we have to decide on a symbol name. Sorry to bug you with this now, but I'd like to get it out of the way so I can properly finish the wxWindows port. -- Dimi.

Dec. 24, 2002

Re: tchar fixes: _tcs{dup,icmp}

by Francois Gouget

On Tue, 24 Dec 2002, Dimitrie O. Paun wrote: > On December 23, 2002 10:52 pm, Francois Gouget wrote: > > Then the question is whether tchar.h should be considered to be a pure > > msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether > > we want to make is usable in Ansi mode with a regular C library. > > If using tchar.h forces you to link in msvcrt, it should be moved to > include/msvcrt. Thing is that MinGW supports tchar.h it seems, so we > can do one of two things: > 1. Add conditionals in tchar.h as you suggested to do things differently > depending on whether or not we link in msvcrt > 2. Move the current tchar.h to include/msvcrt, and create a new one > to support the MinGW/glibc case. Solution 2 seems likely to cause directory include order headaches... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

Dec. 24, 2002

Re: tchar fixes: _tcs{dup,icmp}

by Dimitrie O. Paun

On December 24, 2002 03:43 pm, Francois Gouget wrote: > Solution 2 seems likely to cause directory include order headaches... Not really. We should have another directory called include/cygwin, and you either use include/msvcrt or include/cygwin. They are mutually exclusive. Where is the problem? -- Dimi.

Dec. 24, 2002

Re: 'make test' failure on sysparams.c

by Dan Kegel

Dan Kegel wrote: > 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. Darn. It's nonrepeatable. I'll post again if I figure out how to repeat it. FWIW I was using ssh X forwarding. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 24, 2002

Some D3D status updates...

by Lionel Ulmer

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/

Dec. 24, 2002

Re: Validate imagelists

by Dimitrie O. Paun

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.

Dec. 24, 2002

Re: Some D3D status updates...

by Dimitrie O. Paun

On December 24, 2002 01:33 pm, Lionel Ulmer wrote: > 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 Way to go Lionel! Way, way cool :) Marry Christmas people! -- Dimi.

Dec. 24, 2002

Re: tchar fixes: _tcs{dup,icmp}

by Dimitrie O. Paun

On December 23, 2002 10:52 pm, Francois Gouget wrote: > Then the question is whether tchar.h should be considered to be a pure > msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether > we want to make is usable in Ansi mode with a regular C library. If using tchar.h forces you to link in msvcrt, it should be moved to include/msvcrt. Thing is that MinGW supports tchar.h it seems, so we can do one of two things: 1. Add conditionals in tchar.h as you suggested to do things differently depending on whether or not we link in msvcrt 2. Move the current tchar.h to include/msvcrt, and create a new one to support the MinGW/glibc case. Alexandre? -- Dimi.

Dec. 24, 2002

Re: Mozilla-Win32 Winelib build update..

by Dimitrie O. Paun

On December 24, 2002 11:07 am, Dustin Navea wrote: > Hi guys, just wanted to update you all that I am having some trouble > getting my hands on that DSL router I was planning on having last week. I > should have it shortly after the first and can begin the build process > then.. Hi Dustin, I think I might take over the Mozilla porting, I need a large test set for wine{gcc,wrap} anyway :) -- Dimi.

Dec. 24, 2002

[JOY] wxWindows

by Dimitrie O. Paun

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.

Dec. 24, 2002

Re: Couldn't find a decent font, aborting

by Eric Pouech

> I've quickly searched through the Devel and User archives, and searched > using Google, but found just about nothing on the subject. wineconsole looks for a fixed size font which will fit the 80x25 console on the screen. it doesn't seem to find one. a possible workaround is to install more fixed size TTF fonts A+ -- Eric Pouech

Dec. 24, 2002

Re: MSVC4, next two buttons on installer

by Eric Pouech

> Q4. Is winefile going to be installed in some standard place? winefile is installed in wine's normal installation process > Also, > is it a problem that winefile is a winelib application? Wouldn't > we rather it be a straight Windows application if we're going to > invoke it from inside wine? there shouldn't be any problem there A+ -- Eric Pouech

Dec. 24, 2002

Mozilla-Win32 Winelib build update..

by Dustin Navea

Hi guys, just wanted to update you all that I am having some trouble getting my hands on that DSL router I was planning on having last week. I should have it shortly after the first and can begin the build process then.. if all goes as planned. Sorry about the long wait and happy holidays to all. -Dustin

Dec. 24, 2002

Re: RECT (take 2)

by Dan Kegel

Dimitrie O. Paun wrote: > Fixing the RECT definition (how come it fell through the cracks, > it's such a fundamental definition in Win32?) in one go doesn't > seem like it's going to happen. A lot of places need fixing, so > unless a Perl wizard (hint, hint) comes up with a magic script, > it's going to be a while until this is fixed. I had a go at the perl approach, at least for a subset of the changes. Here's the script I used to generate the initial patch: #!/bin/sh rm -rf orig after #make > log 2>&1 || /bin/true grep "warning: int format, LONG arg" log | sed -e 's/:.*//' | sort -u | sed 's,\.\./,,g' > fils find . | fgrep -f fils > absfils tar -czvf orig.tgz `cat absfils` mkdir orig cd orig; tar -xzvf ../orig.tgz; cd .. mkdir after cd after; tar -xzvf ../orig.tgz; cd .. cd after find . -type f | xargs perl -p -i.bak -e 's/$%d,%d$/(%ld,%ld)/g' cd .. diff -aur orig after > longify.patch I then removed any part of the patch that was wrong (first by eye, then iteratively by looking at compiler logs). This gets rid of quite a few of the warnings. The resulting patch is attached. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com diff -aur orig/controls/menu.c after/controls/menu.c --- orig/controls/menu.c 2002-12-21 21:52:08.000000000 -0800 +++ after/controls/menu.c 2002-12-24 05:11:18.000000000 -0800 @@ -965,7 +965,7 @@ - arrow_bitmap_width; } } - TRACE("(%d,%d)-(%d,%d)\n", lpitem->rect.left, lpitem->rect.top, lpitem->rect.right, lpitem->rect.bottom); + TRACE("(%ld,%ld)-(%ld,%ld)\n", lpitem->rect.left, lpitem->rect.top, lpitem->rect.right, lpitem->rect.bottom); } @@ -2688,7 +2688,7 @@ mt.pt.x = x; mt.pt.y = y; - TRACE("hmenu=%p flags=0x%08x (%d,%d) hwnd=%p (%d,%d)-(%d,%d)\n", + TRACE("hmenu=%p flags=0x%08x (%d,%d) hwnd=%p (%ld,%ld)-(%ld,%ld)\n", hmenu, wFlags, x, y, hwnd, (lprect) ? lprect->left : 0, (lprect) ? lprect->top : 0, (lprect) ? lprect->right : 0, (lprect) ? lprect->bottom : 0); diff -aur orig/dlls/comctl32/comboex.c after/dlls/comctl32/comboex.c --- orig/dlls/comctl32/comboex.c 2002-12-21 21:52:08.000000000 -0800 +++ after/dlls/comctl32/comboex.c 2002-12-24 05:11:18.000000000 -0800 @@ -385,7 +385,7 @@ h = mysize.cy + 1; y = rect.bottom - h - 1; - TRACE("Combo client (%d,%d)-(%d,%d), setting Edit to (%d,%d)-(%d,%d)\n", + TRACE("Combo client (%ld,%ld)-(%ld,%ld), setting Edit to (%d,%d)-(%d,%d)\n", rect.left, rect.top, rect.right, rect.bottom, x, y, x + w, y + h); SetWindowPos(infoPtr->hwndEdit, HWND_TOP, x, y, w, h, SWP_SHOWWINDOW | SWP_NOACTIVATE | SWP_NOZORDER); @@ -891,10 +891,10 @@ height = cb_wrect.bottom-cb_wrect.top + cbx_wrect.bottom-cbx_wrect.top - (cbx_crect.bottom-cbx_crect.top); - TRACE("EX window=(%d,%d)-(%d,%d), client=(%d,%d)-(%d,%d)\n", + TRACE("EX window=(%ld,%ld)-(%ld,%ld), client=(%ld,%ld)-(%ld,%ld)\n", cbx_wrect.left, cbx_wrect.top, cbx_wrect.right, cbx_wrect.bottom, cbx_crect.left, cbx_crect.top, cbx_crect.right, cbx_crect.bottom); - TRACE("CB window=(%d,%d)-(%d,%d), EX setting=(0,0)-(%d,%d)\n", + TRACE("CB window=(%ld,%ld)-(%ld,%ld), EX setting=(0,0)-(%d,%d)\n", cb_wrect.left, cb_wrect.top, cb_wrect.right, cb_wrect.bottom, cbx_wrect.right-cbx_wrect.left, height); SetWindowPos (infoPtr->hwndSelf, HWND_TOP, 0, 0, @@ -942,7 +942,7 @@ /* create combo box */ GetWindowRect(hwnd, &wnrc1); GetClientRect(hwnd, &clrc1); - TRACE("EX window=(%d,%d)-(%d,%d) client=(%d,%d)-(%d,%d)\n", + TRACE("EX window=(%ld,%ld)-(%ld,%ld) client=(%ld,%ld)-(%ld,%ld)\n", wnrc1.left, wnrc1.top, wnrc1.right, wnrc1.bottom, clrc1.left, clrc1.top, clrc1.right, clrc1.bottom); @@ -1033,7 +1033,7 @@ GetWindowRect(hwnd, &wnrc1); GetClientRect(hwnd, &clrc1); GetWindowRect(infoPtr->hwndCombo, &cmbwrc); - TRACE("EX window=(%d,%d)-(%d,%d) client=(%d,%d)-(%d,%d) CB wnd=(%d,%d)-(%d,%d)\n", + TRACE("EX window=(%ld,%ld)-(%ld,%ld) client=(%ld,%ld)-(%ld,%ld) CB wnd=(%ld,%ld)-(%ld,%ld)\n", wnrc1.left, wnrc1.top, wnrc1.right, wnrc1.bottom, clrc1.left, clrc1.top, clrc1.right, clrc1.bottom, cmbwrc.left, cmbwrc.top, cmbwrc.right, cmbwrc.bottom); @@ -1042,7 +1042,7 @@ SWP_NOACTIVATE | SWP_NOREDRAW); GetWindowRect(infoPtr->hwndCombo, &cmbwrc); - TRACE("CB window=(%d,%d)-(%d,%d)\n", + TRACE("CB window=(%ld,%ld)-(%ld,%ld)\n", cmbwrc.left, cmbwrc.top, cmbwrc.right, cmbwrc.bottom); SetWindowPos(hwnd, HWND_TOP, 0, 0, cmbwrc.right-cmbwrc.left, cmbwrc.bottom-cmbwrc.top, @@ -1291,7 +1291,7 @@ dis->CtlType, dis->CtlID); TRACE("itemID=0x%08x itemAction=0x%08x itemState=0x%08x\n", dis->itemID, dis->itemAction, dis->itemState); - TRACE("hWnd=%p hDC=%p (%d,%d)-(%d,%d) itemData=0x%08lx\n", + TRACE("hWnd=%p hDC=%p (%ld,%ld)-(%ld,%ld) itemData=0x%08lx\n", dis->hwndItem, dis->hDC, dis->rcItem.left, dis->rcItem.top, dis->rcItem.right, dis->rcItem.bottom, dis->itemData); @@ -1311,7 +1311,7 @@ if ( ( (dis->itemAction & ODA_FOCUS) && (dis->itemState & ODS_SELECTED)) || ( (dis->itemAction & (ODA_SELECT | ODA_DRAWENTIRE)) && (dis->itemState & ODS_FOCUS) ) ) { - TRACE("drawing item -1 special focus, rect=(%d,%d)-(%d,%d)\n", + TRACE("drawing item -1 special focus, rect=(%ld,%ld)-(%ld,%ld)\n", dis->rcItem.left, dis->rcItem.top, dis->rcItem.right, dis->rcItem.bottom); } @@ -1327,14 +1327,14 @@ edrc.left=edrc.top=edrc.right=edrc.bottom=-1; if (infoPtr->hwndEdit) GetWindowRect (infoPtr->hwndEdit, &edrc); - TRACE("window rects ex=(%d,%d)-(%d,%d), cb=(%d,%d)-(%d,%d), ed=(%d,%d)-(%d,%d)\n", + TRACE("window rects ex=(%ld,%ld)-(%ld,%ld), cb=(%ld,%ld)-(%ld,%ld), ed=(%ld,%ld)-(%ld,%ld)\n", exrc.left, exrc.top, exrc.right, exrc.bottom, cbrc.left, cbrc.top, cbrc.right, cbrc.bottom, edrc.left, edrc.top, edrc.right, edrc.bottom); } } else { - ERR("NOT drawing item -1 special focus, rect=(%d,%d)-(%d,%d), action=%08x, state=%08x\n", + ERR("NOT drawing item -1 special focus, rect=(%ld,%ld)-(%ld,%ld), action=%08x, state=%08x\n", dis->rcItem.left, dis->rcItem.top, dis->rcItem.right, dis->rcItem.bottom, dis->itemAction, dis->itemState); @@ -1491,7 +1491,7 @@ rect.right = x + txtsize.cx; rect.top = dis->rcItem.top + 1; rect.bottom = dis->rcItem.bottom - 1; - TRACE("drawing item %d text, rect=(%d,%d)-(%d,%d)\n", + TRACE("drawing item %d text, rect=(%ld,%ld)-(%ld,%ld)\n", dis->itemID, rect.left, rect.top, rect.right, rect.bottom); ExtTextOutW (dis->hDC, x, y, ETO_OPAQUE | ETO_CLIPPED, &rect, str, len, 0); @@ -1617,10 +1617,10 @@ TRACE("winpos=(%d,%d %dx%d) flags=0x%08x\n", wp->x, wp->y, wp->cx, wp->cy, wp->flags); - TRACE("EX window=(%d,%d)-(%d,%d), client=(%d,%d)-(%d,%d)\n", + TRACE("EX window=(%ld,%ld)-(%ld,%ld), client=(%ld,%ld)-(%ld,%ld)\n", cbx_wrect.left, cbx_wrect.top, cbx_wrect.right, cbx_wrect.bottom, cbx_crect.left, cbx_crect.top, cbx_crect.right, cbx_crect.bottom); - TRACE("CB window=(%d,%d)-(%d,%d), EX setting=(0,0)-(%d,%d)\n", + TRACE("CB window=(%ld,%ld)-(%ld,%ld), EX setting=(0,0)-(%d,%d)\n", cb_wrect.left, cb_wrect.top, cb_wrect.right, cb_wrect.bottom, width, cb_wrect.bottom-cb_wrect.top); @@ -1702,7 +1702,7 @@ hDC = (HDC) wParam; obkc = SetBkColor (hDC, GetSysColor (COLOR_WINDOW)); GetClientRect (hwnd, &rect); - TRACE("erasing (%d,%d)-(%d,%d)\n", + TRACE("erasing (%ld,%ld)-(%ld,%ld)\n", rect.left, rect.top, rect.right, rect.bottom); ExtTextOutW (hDC, 0, 0, ETO_OPAQUE, &rect, 0, 0, 0); SetBkColor (hDC, obkc); @@ -1907,7 +1907,7 @@ hDC = (HDC) wParam; obkc = SetBkColor (hDC, GetSysColor (COLOR_WINDOW)); GetClientRect (hwnd, &rect); - TRACE("erasing (%d,%d)-(%d,%d)\n", + TRACE("erasing (%ld,%ld)-(%ld,%ld)\n", rect.left, rect.top, rect.right, rect.bottom); ExtTextOutW (hDC, 0, 0, ETO_OPAQUE, &rect, 0, 0, 0); SetBkColor (hDC, obkc); diff -aur orig/dlls/comctl32/listview.c after/dlls/comctl32/listview.c --- orig/dlls/comctl32/listview.c 2002-12-23 22:59:36.000000000 -0800 +++ after/dlls/comctl32/listview.c 2002-12-24 05:11:18.000000000 -0800 @@ -6462,7 +6462,7 @@ infoPtr->iconSpacing.cx = cx; infoPtr->iconSpacing.cy = cy; - TRACE("old=(%d,%d), new=(%d,%d), iconSize=(%ld,%ld), ntmH=%d\n", + TRACE("old=(%d,%d), new=(%d,%d), iconSize=(%ld,%ld), ntmH=%d\n", LOWORD(oldspacing), HIWORD(oldspacing), cx, cy, infoPtr->iconSize.cx, infoPtr->iconSize.cy, infoPtr->ntmHeight); diff -aur orig/dlls/comctl32/pager.c after/dlls/comctl32/pager.c --- orig/dlls/comctl32/pager.c 2002-12-21 21:52:09.000000000 -0800 +++ after/dlls/comctl32/pager.c 2002-12-24 05:11:18.000000000 -0800 @@ -897,7 +897,7 @@ DefWindowProcA (hwnd, WM_NCCALCSIZE, wParam, lParam); - TRACE("orig rect=(%d,%d)-(%d,%d)\n", + TRACE("orig rect=(%ld,%ld)-(%ld,%ld)\n", lpRect->left, lpRect->top, lpRect->right, lpRect->bottom); if (PAGER_IsHorizontal(hwnd)) @@ -912,7 +912,7 @@ /* Reset buttons and hide any grey ones */ scrollRange = infoPtr->nWidth - (rcmyw.right - rcmyw.left); - TRACE("nPos=%d, scrollrange=%d, nHeigth=%d, myw=(%d,%d)-(%d,%d), cursor=(%ld,%ld)\n", + TRACE("nPos=%d, scrollrange=%d, nHeigth=%d, myw=(%ld,%ld)-(%ld,%ld), cursor=(%ld,%ld)\n", infoPtr->nPos, scrollRange, infoPtr->nHeight, rcmyw.left, rcmyw.top, rcmyw.right, rcmyw.bottom, @@ -926,7 +926,7 @@ ltrc.right = ltrc.left + infoPtr->nButtonSize; rbrc = wnrc; rbrc.left = rbrc.right - infoPtr->nButtonSize; - TRACE("horz lt rect=(%d,%d)-(%d,%d), rb rect=(%d,%d)-(%d,%d)\n", + TRACE("horz lt rect=(%ld,%ld)-(%ld,%ld), rb rect=(%ld,%ld)-(%ld,%ld)\n", ltrc.left, ltrc.top, ltrc.right, ltrc.bottom, rbrc.left, rbrc.top, rbrc.right, rbrc.bottom); if (PtInRect (&ltrc, cursor) && infoPtr->TLbtnState) @@ -961,7 +961,7 @@ /* Reset buttons and hide any grey ones */ scrollRange = infoPtr->nHeight - (rcmyw.bottom - rcmyw.top); - TRACE("nPos=%d, scrollrange=%d, nHeigth=%d, myw=(%d,%d)-(%d,%d), cursor=(%ld,%ld)\n", + TRACE("nPos=%d, scrollrange=%d, nHeigth=%d, myw=(%ld,%ld)-(%ld,%ld), cursor=(%ld,%ld)\n", infoPtr->nPos, scrollRange, infoPtr->nHeight, rcmyw.left, rcmyw.top, rcmyw.right, rcmyw.bottom, @@ -986,7 +986,7 @@ ltrc.right = ltrc.left + infoPtr->nButtonSize; rbrc = wnrc; rbrc.left = rbrc.right - infoPtr->nButtonSize; - TRACE("vert lt rect=(%d,%d)-(%d,%d), rb rect=(%d,%d)-(%d,%d)\n", + TRACE("vert lt rect=(%ld,%ld)-(%ld,%ld), rb rect=(%ld,%ld)-(%ld,%ld)\n", ltrc.left, ltrc.top, ltrc.right, ltrc.bottom, rbrc.left, rbrc.top, rbrc.right, rbrc.bottom); if (PtInRect (&ltrc, cursor) && infoPtr->TLbtnState) @@ -1003,7 +1003,7 @@ lpRect->bottom = infoPtr->nHeight; } - TRACE("[%p] client rect set to %dx%d at (%d,%d) BtnState[%d,%d]\n", + TRACE("[%p] client rect set to %dx%d at (%ld,%ld) BtnState[%d,%d]\n", hwnd, lpRect->right-lpRect->left, lpRect->bottom-lpRect->top, lpRect->left, lpRect->top, infoPtr->TLbtnState, infoPtr->BRbtnState); @@ -1232,7 +1232,7 @@ /* If in one of the buttons the capture and draw buttons */ if (btnrect) { - TRACE("[%p] draw btn (%d,%d)-(%d,%d), Capture %s, style %08lx\n", + TRACE("[%p] draw btn (%ld,%ld)-(%ld,%ld), Capture %s, style %08lx\n", hwnd, btnrect->left, btnrect->top, btnrect->right, btnrect->bottom, (infoPtr->bCapture) ? "TRUE" : "FALSE", diff -aur orig/dlls/comctl32/propsheet.c after/dlls/comctl32/propsheet.c --- orig/dlls/comctl32/propsheet.c 2002-12-21 21:52:09.000000000 -0800 +++ after/dlls/comctl32/propsheet.c 2002-12-24 05:11:18.000000000 -0800 @@ -745,7 +745,7 @@ rc.right -= rc.left; rc.bottom -= rc.top; - TRACE("setting tab %08lx, rc (0,0)-(%d,%d)\n", + TRACE("setting tab %08lx, rc (0,0)-(%ld,%ld)\n", (DWORD)hwndTabCtrl, rc.right, rc.bottom); SetWindowPos(hwndTabCtrl, 0, 0, 0, rc.right, rc.bottom, SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE); @@ -761,7 +761,7 @@ /* * Resize the property sheet. */ - TRACE("setting dialog %08lx, rc (0,0)-(%d,%d)\n", + TRACE("setting dialog %08lx, rc (0,0)-(%ld,%ld)\n", (DWORD)hwndDlg, rc.right, rc.bottom); SetWindowPos(hwndDlg, 0, 0, 0, rc.right, rc.bottom, SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE); @@ -830,7 +830,7 @@ /* * Resize the property sheet. */ - TRACE("setting dialog %08lx, rc (0,0)-(%d,%d)\n", + TRACE("setting dialog %08lx, rc (0,0)-(%ld,%ld)\n", (DWORD)hwndDlg, rc.right, rc.bottom); SetWindowPos(hwndDlg, 0, 0, 0, rc.right, rc.bottom, SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE); @@ -1422,7 +1422,7 @@ pageHeight = rc.bottom - rc.top; padding = PROPSHEET_GetPaddingInfoWizard(hwndParent, psInfo); - TRACE("setting page %08lx, rc (%d,%d)-(%d,%d) w=%d, h=%d, padx=%d, pady=%d\n", + TRACE("setting page %08lx, rc (%ld,%ld)-(%ld,%ld) w=%d, h=%d, padx=%d, pady=%d\n", (DWORD)hwndPage, rc.left, rc.top, rc.right, rc.bottom, pageWidth, pageHeight, padding.x, padding.y); SetWindowPos(hwndPage, HWND_TOP, @@ -1438,7 +1438,7 @@ PROPSHEET_GetPageRect(psInfo, hwndParent, &rc); pageWidth = rc.right - rc.left; pageHeight = rc.bottom - rc.top; - TRACE("setting page %08lx, rc (%d,%d)-(%d,%d) w=%d, h=%d\n", + TRACE("setting page %08lx, rc (%ld,%ld)-(%ld,%ld) w=%d, h=%d\n", (DWORD)hwndPage, rc.left, rc.top, rc.right, rc.bottom, pageWidth, pageHeight); SetWindowPos(hwndPage, HWND_TOP, diff -aur orig/dlls/comctl32/rebar.c after/dlls/comctl32/rebar.c --- orig/dlls/comctl32/rebar.c 2002-12-21 21:52:09.000000000 -0800 +++ after/dlls/comctl32/rebar.c 2002-12-24 05:11:18.000000000 -0800 @@ -466,11 +466,11 @@ i, (pB->lpText) ? debugstr_w(pB->lpText) : "(null)"); TRACE("band # %u: lcx=%u, ccx=%u, hcx=%u, lcy=%u, ccy=%u, hcy=%u, offChild=%ld,%ld\n", i, pB->lcx, pB->ccx, pB->hcx, pB->lcy, pB->ccy, pB->hcy, pB->offChild.cx, pB->offChild.cy); - TRACE("band # %u: fStatus=%08x, fDraw=%08x, Band=(%d,%d)-(%d,%d), Grip=(%d,%d)-(%d,%d)\n", + TRACE("band # %u: fStatus=%08x, fDraw=%08x, Band=(%ld,%ld)-(%ld,%ld), Grip=(%ld,%ld)-(%ld,%ld)\n", i, pB->fStatus, pB->fDraw, pB->rcBand.left, pB->rcBand.top, pB->rcBand.right, pB->rcBand.bottom, pB->rcGripper.left, pB->rcGripper.top, pB->rcGripper.right, pB->rcGripper.bottom); - TRACE("band # %u: Img=(%d,%d)-(%d,%d), Txt=(%d,%d)-(%d,%d), Child=(%d,%d)-(%d,%d)\n", + TRACE("band # %u: Img=(%ld,%ld)-(%ld,%ld), Txt=(%ld,%ld)-(%ld,%ld), Child=(%ld,%ld)-(%ld,%ld)\n", i, pB->rcCapImage.left, pB->rcCapImage.top, pB->rcCapImage.right, pB->rcCapImage.bottom, pB->rcCapText.left, pB->rcCapText.top, pB->rcCapText.right, pB->rcCapText.bottom, @@ -679,7 +679,7 @@ (lpBand->rcoldBand.right !=lpBand->rcBand.right) || (lpBand->rcoldBand.bottom !=lpBand->rcBand.bottom)) { lpBand->fDraw |= NTF_INVALIDATE; - TRACE("band %d row=%d: changed to (%d,%d)-(%d,%d) from (%d,%d)-(%d,%d)\n", + TRACE("band %d row=%d: changed to (%ld,%ld)-(%ld,%ld) from (%ld,%ld)-(%ld,%ld)\n", i, lpBand->iRow, lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right, lpBand->rcBand.bottom, @@ -687,7 +687,7 @@ lpBand->rcoldBand.right, lpBand->rcoldBand.bottom); } else - TRACE("band %d row=%d: unchanged (%d,%d)-(%d,%d)\n", + TRACE("band %d row=%d: unchanged (%ld,%ld)-(%ld,%ld)\n", i, lpBand->iRow, lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right, lpBand->rcBand.bottom); @@ -763,7 +763,7 @@ lpBand->rcBand.bottom = lpBand->rcBand.top + curwidth; else lpBand->rcBand.right = lpBand->rcBand.left + curwidth; - TRACE("Phase 1 band %d, (%d,%d)-(%d,%d), orig x=%d, xsep=%d\n", + TRACE("Phase 1 band %d, (%ld,%ld)-(%ld,%ld), orig x=%d, xsep=%d\n", i, lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right, lpBand->rcBand.bottom, x, xsep); x = rcBrb(lpBand); @@ -833,7 +833,7 @@ lpBand->rcBand.bottom = lpBand->rcBand.top + curwidth; else lpBand->rcBand.right = lpBand->rcBand.left + curwidth; - TRACE("Phase 2 band %d, (%d,%d)-(%d,%d), orig x=%d, xsep=%d\n", + TRACE("Phase 2 band %d, (%ld,%ld)-(%ld,%ld), orig x=%d, xsep=%d\n", i, lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right, lpBand->rcBand.bottom, x, xsep); x = rcBrb(lpBand); @@ -961,14 +961,14 @@ ((oldChild.right-oldChild.left != lpBand->rcChild.right-lpBand->rcChild.left) || (oldChild.bottom-oldChild.top != lpBand->rcChild.bottom-lpBand->rcChild.top))) { TRACE("Child rectangle changed for band %u\n", i); - TRACE(" from (%d,%d)-(%d,%d) to (%d,%d)-(%d,%d)\n", + TRACE(" from (%ld,%ld)-(%ld,%ld) to (%ld,%ld)-(%ld,%ld)\n", oldChild.left, oldChild.top, oldChild.right, oldChild.bottom, lpBand->rcChild.left, lpBand->rcChild.top, lpBand->rcChild.right, lpBand->rcChild.bottom); } if (lpBand->fDraw & NTF_INVALIDATE) { - TRACE("invalidating (%d,%d)-(%d,%d)\n", + TRACE("invalidating (%ld,%ld)-(%ld,%ld)\n", lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right + ((lpBand->fDraw & DRAW_RIGHTSEP) ? SEP_WIDTH_SIZE : 0), @@ -1100,14 +1100,14 @@ ((oldChild.right-oldChild.left != lpBand->rcChild.right-lpBand->rcChild.left) || (oldChild.bottom-oldChild.top != lpBand->rcChild.bottom-lpBand->rcChild.top))) { TRACE("Child rectangle changed for band %u\n", i); - TRACE(" from (%d,%d)-(%d,%d) to (%d,%d)-(%d,%d)\n", + TRACE(" from (%ld,%ld)-(%ld,%ld) to (%ld,%ld)-(%ld,%ld)\n", oldChild.left, oldChild.top, oldChild.right, oldChild.bottom, lpBand->rcChild.left, lpBand->rcChild.top, lpBand->rcChild.right, lpBand->rcChild.bottom); } if (lpBand->fDraw & NTF_INVALIDATE) { - TRACE("invalidating (%d,%d)-(%d,%d)\n", + TRACE("invalidating (%ld,%ld)-(%ld,%ld)\n", lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right + ((lpBand->fDraw & DRAW_BOTTOMSEP) ? SEP_WIDTH_SIZE : 0), @@ -1264,7 +1264,7 @@ REBAR_Notify ((NMHDR *)&rbcz, infoPtr, RBN_CHILDSIZE); if (!EqualRect (&lpBand->rcChild, &rbcz.rcChild)) { TRACE("Child rect changed by NOTIFY for band %u\n", i); - TRACE(" from (%d,%d)-(%d,%d) to (%d,%d)-(%d,%d)\n", + TRACE(" from (%ld,%ld)-(%ld,%ld) to (%ld,%ld)-(%ld,%ld)\n", lpBand->rcChild.left, lpBand->rcChild.top, lpBand->rcChild.right, lpBand->rcChild.bottom, rbcz.rcChild.left, rbcz.rcChild.top, @@ -1310,7 +1310,7 @@ ERR("DeferWindowPos returned NULL\n"); } else { - TRACE("moving child (Other) %p to (%d,%d) for (%d,%d)\n", + TRACE("moving child (Other) %p to (%ld,%ld) for (%ld,%ld)\n", lpBand->hwndChild, lpBand->rcChild.left, lpBand->rcChild.top, lpBand->rcChild.right - lpBand->rcChild.left, @@ -1370,12 +1370,12 @@ if (!infoPtr->DoRedraw) infoPtr->fStatus |= BAND_NEEDS_REDRAW; GetClientRect (infoPtr->hwndSelf, &rcClient); - TRACE("Client is (%d,%d)-(%d,%d)\n", + TRACE("Client is (%ld,%ld)-(%ld,%ld)\n", rcClient.left, rcClient.top, rcClient.right, rcClient.bottom); if (lpRect) { rcAdj = *lpRect; - TRACE("adjustment rect is (%d,%d)-(%d,%d)\n", + TRACE("adjustment rect is (%ld,%ld)-(%ld,%ld)\n", rcAdj.left, rcAdj.top, rcAdj.right, rcAdj.bottom); } else { @@ -1531,7 +1531,7 @@ lpBand->uMinHeight = lpBand->lcy; x = rightx; } - TRACE("P1 band %u, row %d, (%d,%d)-(%d,%d)\n", + TRACE("P1 band %u, row %d, (%ld,%ld)-(%ld,%ld)\n", i, row, lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right, lpBand->rcBand.bottom); @@ -1672,11 +1672,11 @@ current->rcBand.bottom = current->rcBand.top + new_rh; y += adj_rh; } - TRACE("P2 moving band %d to own row at (%d,%d)-(%d,%d)\n", + TRACE("P2 moving band %d to own row at (%ld,%ld)-(%ld,%ld)\n", current_idx, current->rcBand.left, current->rcBand.top, current->rcBand.right, current->rcBand.bottom); - TRACE("P2 prev band %d at (%d,%d)-(%d,%d)\n", + TRACE("P2 prev band %d at (%ld,%ld)-(%ld,%ld)\n", prev_idx, prev->rcBand.left, prev->rcBand.top, prev->rcBand.right, prev->rcBand.bottom); @@ -1779,7 +1779,7 @@ lpBand->rcBand.right = lpBand->rcBand.left + j; else lpBand->rcBand.bottom = lpBand->rcBand.top + j; - TRACE("P2b band %d, row %d changed to (%d,%d)-(%d,%d)\n", + TRACE("P2b band %d, row %d changed to (%ld,%ld)-(%ld,%ld)\n", iband, lpBand->iRow, lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right, lpBand->rcBand.bottom); @@ -2141,7 +2141,7 @@ rcRowSep.right = infoPtr->calcSize.cx; DrawEdge (hdc, &rcRowSep, EDGE_ETCHED, BF_BOTTOM); } - TRACE ("drawing band separator bottom (%d,%d)-(%d,%d)\n", + TRACE ("drawing band separator bottom (%ld,%ld)-(%ld,%ld)\n", rcRowSep.left, rcRowSep.top, rcRowSep.right, rcRowSep.bottom); } @@ -2159,7 +2159,7 @@ rcSep.right += SEP_WIDTH_SIZE; DrawEdge (hdc, &rcSep, EDGE_ETCHED, BF_RIGHT); } - TRACE("drawing band separator right (%d,%d)-(%d,%d)\n", + TRACE("drawing band separator right (%ld,%ld)-(%ld,%ld)\n", rcSep.left, rcSep.top, rcSep.right, rcSep.bottom); } @@ -2186,7 +2186,7 @@ old = SetBkColor (hdc, new); rect = lpBand->rcBand; - TRACE("%s background color=0x%06lx, band (%d,%d)-(%d,%d), clip (%d,%d)-(%d,%d)\n", + TRACE("%s background color=0x%06lx, band (%ld,%ld)-(%ld,%ld), clip (%ld,%ld)-(%ld,%ld)\n", (lpBand->clrBack == CLR_NONE) ? "none" : ((lpBand->clrBack == CLR_DEFAULT) ? "dft" : ""), GetBkColor(hdc), @@ -2340,7 +2340,7 @@ LEADJ(band, Leadjust); READJ(band, Readjust); - TRACE("band %d: left=%d, right=%d, move=%d, rtn=%d, rcBand=(%d,%d)-(%d,%d)\n", + TRACE("band %d: left=%d, right=%d, move=%d, rtn=%d, rcBand=(%ld,%ld)-(%ld,%ld)\n", i, Leadjust, Readjust, movement, ret, band->rcBand.left, band->rcBand.top, band->rcBand.right, band->rcBand.bottom); @@ -2422,7 +2422,7 @@ infoPtr->ihitoffset); infoPtr->dragNow = *ptsmove; - TRACE("before: movement=%d (%d,%d), imindBand=%d, ihitBand=%d, imaxdBand=%d, LSum=%d, RSum=%d\n", + TRACE("before: movement=%d (%ld,%ld), imindBand=%d, ihitBand=%d, imaxdBand=%d, LSum=%d, RSum=%d\n", movement, ptsmove->x, ptsmove->y, imindBand, ihitBand, imaxdBand, LHeaderSum, RHeaderSum); REBAR_DumpBand (infoPtr); @@ -2864,7 +2864,7 @@ lpBand = &infoPtr->bands[iBand]; CopyRect (lprc, &lpBand->rcBand); - TRACE("band %d, (%d,%d)-(%d,%d)\n", iBand, + TRACE("band %d, (%ld,%ld)-(%ld,%ld)\n", iBand, lprc->left, lprc->top, lprc->right, lprc->bottom); return TRUE; @@ -3208,7 +3208,7 @@ movement = lpBand->rcBand.right - lpBand->rcBand.left - lpBand->cxHeader; if (movement < 0) { - ERR("something is wrong, band=(%d,%d)-(%d,%d), cxheader=%d\n", + ERR("something is wrong, band=(%ld,%ld)-(%ld,%ld), cxheader=%d\n", lpBand->rcBand.left, lpBand->rcBand.top, lpBand->rcBand.right, lpBand->rcBand.bottom, lpBand->cxHeader); @@ -3650,7 +3650,7 @@ if (TRACE_ON(rebar)) { GetWindowRect(infoPtr->hwndSelf, &wnrc1); GetClientRect(infoPtr->hwndSelf, &clrc1); - TRACE("window=(%d,%d)-(%d,%d) client=(%d,%d)-(%d,%d) cs=(%d,%d %dx%d)\n", + TRACE("window=(%ld,%ld)-(%ld,%ld) client=(%ld,%ld)-(%ld,%ld) cs=(%d,%d %dx%d)\n", wnrc1.left, wnrc1.top, wnrc1.right, wnrc1.bottom, clrc1.left, clrc1.top, clrc1.right, clrc1.bottom, cs->x, cs->y, cs->cx, cs->cy); @@ -3827,7 +3827,7 @@ InflateRect((LPRECT)lParam, -GetSystemMetrics(SM_CXEDGE), -GetSystemMetrics(SM_CYEDGE)); } - TRACE("new client=(%d,%d)-(%d,%d)\n", + TRACE("new client=(%ld,%ld)-(%ld,%ld)\n", ((LPRECT)lParam)->left, ((LPRECT)lParam)->top, ((LPRECT)lParam)->right, ((LPRECT)lParam)->bottom); return 0; @@ -3852,7 +3852,7 @@ if (TRACE_ON(rebar)) { GetWindowRect(hwnd, &wnrc1); GetClientRect(hwnd, &clrc1); - TRACE("window=(%d,%d)-(%d,%d) client=(%d,%d)-(%d,%d) cs=(%d,%d %dx%d)\n", + TRACE("window=(%ld,%ld)-(%ld,%ld) client=(%ld,%ld)-(%ld,%ld) cs=(%d,%d %dx%d)\n", wnrc1.left, wnrc1.top, wnrc1.right, wnrc1.bottom, clrc1.left, clrc1.top, clrc1.right, clrc1.bottom, cs->x, cs->y, cs->cx, cs->cy); @@ -3985,7 +3985,7 @@ return 0; GetWindowRect (infoPtr->hwndSelf, &rcWindow); OffsetRect (&rcWindow, -rcWindow.left, -rcWindow.top); - TRACE("rect (%d,%d)-(%d,%d)\n", + TRACE("rect (%ld,%ld)-(%ld,%ld)\n", rcWindow.left, rcWindow.top, rcWindow.right, rcWindow.bottom); DrawEdge (hdc, &rcWindow, EDGE_ETCHED, BF_RECT); @@ -4026,7 +4026,7 @@ GetClientRect(infoPtr->hwndSelf, &rc); hdc = wParam==0 ? BeginPaint (infoPtr->hwndSelf, &ps) : (HDC)wParam; - TRACE("painting (%d,%d)-(%d,%d) client (%d,%d)-(%d,%d)\n", + TRACE("painting (%ld,%ld)-(%ld,%ld) client (%ld,%ld)-(%ld,%ld)\n", ps.rcPaint.left, ps.rcPaint.top, ps.rcPaint.right, ps.rcPaint.bottom, rc.left, rc.top, rc.right, rc.bottom); @@ -4151,14 +4151,14 @@ TRACE("still in CreateWindow\n"); infoPtr->fStatus &= ~CREATE_RUNNING; GetWindowRect ( infoPtr->hwndSelf, &rcWin); - TRACE("win rect (%d,%d)-(%d,%d)\n", + TRACE("win rect (%ld,%ld)-(%ld,%ld)\n", rcWin.left, rcWin.top, rcWin.right, rcWin.bottom); if ((lParam == 0) && (rcWin.right-rcWin.left == 0) && (rcWin.bottom-rcWin.top == 0)) { /* native control seems to do this */ GetClientRect (GetParent(infoPtr->hwndSelf), &rcClient); - TRACE("sizing rebar, message and client zero, parent client (%d,%d)\n", + TRACE("sizing rebar, message and client zero, parent client (%ld,%ld)\n", rcClient.right, rcClient.bottom); } else { @@ -4172,7 +4172,7 @@ /* do the actual WM_SIZE request */ GetClientRect (infoPtr->hwndSelf, &rcClient); - TRACE("sizing rebar from (%ld,%ld) to (%d,%d), client (%d,%d)\n", + TRACE("sizing rebar from (%ld,%ld) to (%ld,%ld), client (%ld,%ld)\n", infoPtr->calcSize.cx, infoPtr->calcSize.cy, LOWORD(lParam), HIWORD(lParam), rcClient.right, rcClient.bottom); @@ -4192,11 +4192,11 @@ /* on a WM_SIZE to zero and current client not zero and AUTOSIZE */ /* native seems to use the current client rect for the size */ infoPtr->fStatus |= BAND_NEEDS_LAYOUT; - TRACE("sizing rebar to client (%d,%d) size is zero but AUTOSIZE set\n", + TRACE("sizing rebar to client (%ld,%ld) size is zero but AUTOSIZE set\n", rcClient.right, rcClient.bottom); } else { - TRACE("sizing rebar from (%ld,%ld) to (%d,%d), client (%d,%d)\n", + TRACE("sizing rebar from (%ld,%ld) to (%ld,%ld), client (%ld,%ld)\n", infoPtr->calcSize.cx, infoPtr->calcSize.cy, LOWORD(lParam), HIWORD(lParam), rcClient.right, rcClient.bottom); @@ -4210,7 +4210,7 @@ autosize.fChanged = 0; /* ??? */ autosize.rcActual = autosize.rcTarget; /* ??? */ REBAR_Notify((NMHDR *) &autosize, infoPtr, RBN_AUTOSIZE); - TRACE("RBN_AUTOSIZE client=(%d,%d), lp=%08lx\n", + TRACE("RBN_AUTOSIZE client=(%ld,%ld), lp=%08lx\n", autosize.rcTarget.right, autosize.rcTarget.bottom, lParam); } @@ -4251,7 +4251,7 @@ ret = DefWindowProcA(infoPtr->hwndSelf, WM_WINDOWPOSCHANGED, wParam, lParam); GetWindowRect(infoPtr->hwndSelf, &rc); - TRACE("hwnd %p new pos (%d,%d)-(%d,%d)\n", + TRACE("hwnd %p new pos (%ld,%ld)-(%ld,%ld)\n", infoPtr->hwndSelf, rc.left, rc.top, rc.right, rc.bottom); return ret; } diff -aur orig/dlls/comctl32/tab.c after/dlls/comctl32/tab.c --- orig/dlls/comctl32/tab.c 2002-12-21 21:52:09.000000000 -0800 +++ after/dlls/comctl32/tab.c 2002-12-24 05:11:18.000000000 -0800 @@ -366,7 +366,7 @@ SELECTED_TAB_OFFSET, 0); } - TRACE("item %d tab h=%d, rect=(%d,%d)-(%d,%d)\n", + TRACE("item %d tab h=%d, rect=(%ld,%ld)-(%ld,%ld)\n", itemIndex, infoPtr->tabHeight, itemRect->left, itemRect->top, itemRect->right, itemRect->bottom); @@ -487,7 +487,7 @@ */ if (isVisible) { - TRACE("invalidate (%d,%d)-(%d,%d)\n", + TRACE("invalidate (%ld,%ld)-(%ld,%ld)\n", selectedRect.left,selectedRect.top, selectedRect.right,selectedRect.bottom); InvalidateRect(hwnd, &selectedRect, TRUE); @@ -1571,7 +1571,7 @@ else center_offset = ((drawRect->right - drawRect->left) - (cx + HORIZONTAL_ITEM_PADDING + (rcText.right - rcText.left))) / 2; - TRACE("for <%s>, c_o=%d, draw=(%d,%d)-(%d,%d), textlen=%d\n", + TRACE("for <%s>, c_o=%d, draw=(%ld,%ld)-(%ld,%ld), textlen=%d\n", debugstr_w(infoPtr->items[iItem].pszText), center_offset, drawRect->left, drawRect->top, drawRect->right, drawRect->bottom, (rcText.right-rcText.left)); @@ -1855,7 +1855,7 @@ /* Adjust both rectangles to match native */ r.left += (1-ZZ); - TRACE("<left> item=%d, fill=(%d,%d)-(%d,%d), edge=(%d,%d)-(%d,%d)\n", + TRACE("<left> item=%d, fill=(%ld,%ld)-(%ld,%ld), edge=(%ld,%ld)-(%ld,%ld)\n", iItem, fillRect.left,fillRect.top,fillRect.right,fillRect.bottom, r.left,r.top,r.right,r.bottom); @@ -1899,7 +1899,7 @@ /* Adjust both rectangles to match native */ fillRect.right += (1-ZZ); - TRACE("<left> item=%d, fill=(%d,%d)-(%d,%d), edge=(%d,%d)-(%d,%d)\n", + TRACE("<left> item=%d, fill=(%ld,%ld)-(%ld,%ld), edge=(%ld,%ld)-(%ld,%ld)\n", iItem, fillRect.left,fillRect.top,fillRect.right,fillRect.bottom, r.left,r.top,r.right,r.bottom); @@ -1956,7 +1956,7 @@ r.bottom--; r.top -= ZZ; - TRACE("<bottom> item=%d, fill=(%d,%d)-(%d,%d), edge=(%d,%d)-(%d,%d)\n", + TRACE("<bottom> item=%d, fill=(%ld,%ld)-(%ld,%ld), edge=(%ld,%ld)-(%ld,%ld)\n", iItem, fillRect.left,fillRect.top,fillRect.right,fillRect.bottom, r.left,r.top,r.right,r.bottom); @@ -2001,7 +2001,7 @@ /* Adjust both rectangles to match native */ fillRect.bottom += (1-ZZ); - TRACE("<top> item=%d, fill=(%d,%d)-(%d,%d), edge=(%d,%d)-(%d,%d)\n", + TRACE("<top> item=%d, fill=(%ld,%ld)-(%ld,%ld), edge=(%ld,%ld)-(%ld,%ld)\n", iItem, fillRect.left,fillRect.top,fillRect.right,fillRect.bottom, r.left,r.top,r.right,r.bottom); @@ -2096,7 +2096,7 @@ } } - TRACE("border=(%d,%d)-(%d,%d)\n", + TRACE("border=(%ld,%ld)-(%ld,%ld)\n", rect.left, rect.top, rect.right, rect.bottom); DrawEdge(hdc, &rect, EDGE_RAISED, BF_SOFT|BF_RECT); @@ -2348,7 +2348,7 @@ ((lStyle & TCS_BUTTONS) ? lastRow * BUTTON_SPACINGY : 0) + 2; } - TRACE("invalidate (%d,%d)-(%d,%d)\n", + TRACE("invalidate (%ld,%ld)-(%ld,%ld)\n", clientRect.left,clientRect.top, clientRect.right,clientRect.bottom); InvalidateRect(hwnd, &clientRect, TRUE); @@ -2362,7 +2362,7 @@ hdc = wParam== 0 ? BeginPaint (hwnd, &ps) : (HDC)wParam; - TRACE("erase %d, rect=(%d,%d)-(%d,%d)\n", + TRACE("erase %d, rect=(%ld,%ld)-(%ld,%ld)\n", ps.fErase, ps.rcPaint.left,ps.rcPaint.top,ps.rcPaint.right,ps.rcPaint.bottom); diff -aur orig/dlls/comctl32/toolbar.c after/dlls/comctl32/toolbar.c --- orig/dlls/comctl32/toolbar.c 2002-12-21 21:52:09.000000000 -0800 +++ after/dlls/comctl32/toolbar.c 2002-12-24 05:11:18.000000000 -0800 @@ -231,7 +231,7 @@ bP->fsState, bP->fsStyle, bP->dwData, bP->iString); TRACE("string %s\n", debugstr_w(TOOLBAR_GetText(infoPtr,bP))); if (internal) - TRACE("button %d id %d, hot=%s, row=%d, rect=(%d,%d)-(%d,%d)\n", + TRACE("button %d id %d, hot=%s, row=%d, rect=(%ld,%ld)-(%ld,%ld)\n", btn_num, bP->idCommand, (bP->bHot) ? "TRUE":"FALSE", bP->nRow, bP->rect.left, bP->rect.top, @@ -474,7 +474,7 @@ InflateRect (&myrect, -2, 0); - TRACE("rect=(%d,%d)-(%d,%d)\n", + TRACE("rect=(%ld,%ld)-(%ld,%ld)\n", myrect.left, myrect.top, myrect.right, myrect.bottom); newcolor = (infoPtr->clrBtnShadow == CLR_DEFAULT) ? @@ -530,7 +530,7 @@ /* draw text */ if (lpText) { - TRACE("string rect=(%d,%d)-(%d,%d)\n", + TRACE("string rect=(%ld,%ld)-(%ld,%ld)\n", rcText->left, rcText->top, rcText->right, rcText->bottom); hOldFont = SelectObject (hdc, infoPtr->hFont); @@ -677,7 +677,7 @@ else rcBitmap.top+=(infoPtr->nButtonHeight - infoPtr->nBitmapHeight) / 2; - TRACE("iBitmap: %d, start=(%d,%d) w=%d, h=%d\n", + TRACE("iBitmap: %d, start=(%ld,%ld) w=%d, h=%d\n", btnPtr->iBitmap, rcBitmap.left, rcBitmap.top, infoPtr->nBitmapWidth, infoPtr->nBitmapHeight); TRACE ("iString: %x\n", btnPtr->iString); @@ -4578,7 +4578,7 @@ InvalidateRect(hwnd, 0, 1); GetWindowRect(hwnd, &rc); MapWindowPoints(0, hwndParent, (LPPOINT)&rc, 2); - TRACE("mapped to (%d,%d)-(%d,%d)\n", + TRACE("mapped to (%ld,%ld)-(%ld,%ld)\n", rc.left, rc.top, rc.right, rc.bottom); lpsize->cx = max(rc.right-rc.left, infoPtr->rcBound.right - infoPtr->rcBound.left); @@ -5397,7 +5397,7 @@ hdc = wParam==0 ? BeginPaint(hwnd, &ps) : (HDC)wParam; - TRACE("psrect=(%d,%d)-(%d,%d)\n", + TRACE("psrect=(%ld,%ld)-(%ld,%ld)\n", ps.rcPaint.left, ps.rcPaint.top, ps.rcPaint.right, ps.rcPaint.bottom); diff -aur orig/dlls/comctl32/treeview.c after/dlls/comctl32/treeview.c --- orig/dlls/comctl32/treeview.c 2002-12-21 21:52:09.000000000 -0800 +++ after/dlls/comctl32/treeview.c 2002-12-24 05:11:18.000000000 -0800 @@ -2554,7 +2554,7 @@ InflateRect(&rcText, -2, -1); /* allow for the focus rect */ - TRACE("drawing text %s at (%d,%d)-(%d,%d)\n", + TRACE("drawing text %s at (%ld,%ld)-(%ld,%ld)\n", debugstr_a(wineItem->pszText), rcText.left, rcText.top, rcText.right, rcText.bottom); diff -aur orig/dlls/d3d8/device.c after/dlls/d3d8/device.c --- orig/dlls/d3d8/device.c 2002-12-23 22:59:37.000000000 -0800 +++ after/dlls/d3d8/device.c 2002-12-24 05:11:18.000000000 -0800 @@ -1048,7 +1048,7 @@ int copyperline = (r->right - r->left) * bytesPerPixel; int j; - TRACE("Copying rect %d (%d,%d),(%d,%d) -> (%ld,%ld)\n", i, r->left, r->top, + TRACE("Copying rect %d (%ld,%ld),(%ld,%ld) -> (%ld,%ld)\n", i, r->left, r->top, r->right, r->bottom, p->x, p->y); /* Find where to start */ diff -aur orig/dlls/oleaut32/olepicture.c after/dlls/oleaut32/olepicture.c --- orig/dlls/oleaut32/olepicture.c 2002-11-11 11:54:22.000000000 -0800 +++ after/dlls/oleaut32/olepicture.c 2002-12-24 05:11:18.000000000 -0800 @@ -498,7 +498,7 @@ TRACE("(%p)->(%p, (%ld,%ld), (%ld,%ld) <- (%ld,%ld), (%ld,%ld), %p)\n", This, hdc, x, y, cx, cy, xSrc, ySrc, cxSrc, cySrc, prcWBounds); if(prcWBounds) - TRACE("prcWBounds (%d,%d) - (%d,%d)\n", prcWBounds->left, prcWBounds->top, + TRACE("prcWBounds (%ld,%ld) - (%ld,%ld)\n", prcWBounds->left, prcWBounds->top, prcWBounds->right, prcWBounds->bottom); /* diff -aur orig/dlls/user/text.c after/dlls/user/text.c --- orig/dlls/user/text.c 2002-11-22 13:22:15.000000000 -0800 +++ after/dlls/user/text.c 2002-12-24 05:11:18.000000000 -0800 @@ -846,7 +846,7 @@ int prefix_offset; ellipsis_data ellip; - TRACE("%s, %d , [(%d,%d),(%d,%d)]\n", debugstr_wn (str, count), count, + TRACE("%s, %d , [(%ld,%ld),(%ld,%ld)]\n", debugstr_wn (str, count), count, rect->left, rect->top, rect->right, rect->bottom); if (dtp) TRACE("Params: iTabLength=%d, iLeftMargin=%d, iRightMargin=%d\n", diff -aur orig/dlls/wineps/escape.c after/dlls/wineps/escape.c --- orig/dlls/wineps/escape.c 2002-11-14 16:02:13.000000000 -0800 +++ after/dlls/wineps/escape.c 2002-12-24 05:11:18.000000000 -0800 @@ -182,7 +182,7 @@ WARN("cbInput != sizeof(RECT) (=%d) for SET_BOUNDS\n", cbInput); return 0; } - TRACE("SET_BOUNDS (%d,%d) - (%d,%d)\n", r->left, r->top, + TRACE("SET_BOUNDS (%ld,%ld) - (%ld,%ld)\n", r->left, r->top, r->right, r->bottom); return 0; } diff -aur orig/dlls/x11drv/winpos.c after/dlls/x11drv/winpos.c --- orig/dlls/x11drv/winpos.c 2002-12-21 21:52:19.000000000 -0800 +++ after/dlls/x11drv/winpos.c 2002-12-24 05:11:18.000000000 -0800 @@ -1589,7 +1589,7 @@ GetWindowRect( hwnd, &rect ); if (rect.left == winpos.x && rect.top == winpos.y) winpos.flags |= SWP_NOMOVE; else - TRACE( "%p moving from (%d,%d) to (%d,%d)\n", + TRACE( "%p moving from (%ld,%ld) to (%d,%d)\n", hwnd, rect.left, rect.top, winpos.x, winpos.y ); if ((rect.right - rect.left == winpos.cx && rect.bottom - rect.top == winpos.cy) || diff -aur orig/windows/nonclient.c after/windows/nonclient.c --- orig/windows/nonclient.c 2002-12-21 21:52:39.000000000 -0800 +++ after/windows/nonclient.c 2002-12-24 05:11:18.000000000 -0800 @@ -424,7 +424,7 @@ WS_EX_STATICEDGE | WS_EX_TOOLWINDOW); if (exStyle & WS_EX_DLGMODALFRAME) style &= ~WS_THICKFRAME; - TRACE("(%d,%d)-(%d,%d) %08lx %d %08lx\n", + TRACE("(%ld,%ld)-(%ld,%ld) %08lx %d %08lx\n", rect->left, rect->top, rect->right, rect->bottom, style, menu, exStyle ); diff -aur orig/windows/spy.c after/windows/spy.c --- orig/windows/spy.c 2002-12-21 21:52:39.000000000 -0800 +++ after/windows/spy.c 2002-12-24 05:11:18.000000000 -0800 @@ -2106,7 +2106,7 @@ { LPRECT rc = (LPRECT) sp_e->lParam; if (rc) { - TRACE("lParam rect (%d,%d)-(%d,%d)\n", + TRACE("lParam rect (%ld,%ld)-(%ld,%ld)\n", rc->left, rc->top, rc->right, rc->bottom); } break; @@ -2149,7 +2149,7 @@ lpdis->CtlType, lpdis->CtlID); TRACE("itemID=0x%08x itemAction=0x%08x itemState=0x%08x\n", lpdis->itemID, lpdis->itemAction, lpdis->itemState); - TRACE("hWnd=%p hDC=%p (%d,%d)-(%d,%d) itemData=0x%08lx\n", + TRACE("hWnd=%p hDC=%p (%ld,%ld)-(%ld,%ld) itemData=0x%08lx\n", lpdis->hwndItem, lpdis->hDC, lpdis->rcItem.left, lpdis->rcItem.top, lpdis->rcItem.right, lpdis->rcItem.bottom, lpdis->itemData); @@ -2187,7 +2187,7 @@ case WM_NCCALCSIZE: { RECT *rc = (RECT *)sp_e->lParam; - TRACE("Rect (%d,%d)-(%d,%d)\n", + TRACE("Rect (%ld,%ld)-(%ld,%ld)\n", rc->left, rc->top, rc->right, rc->bottom); } break; diff -aur orig/windows/win.c after/windows/win.c --- orig/windows/win.c 2002-12-21 21:52:40.000000000 -0800 +++ after/windows/win.c 2002-12-24 05:11:18.000000000 -0800 @@ -576,7 +576,7 @@ win->rectWindow = *rectWindow; win->rectClient = *rectClient; - TRACE( "win %p window (%d,%d)-(%d,%d) client (%d,%d)-(%d,%d)\n", hwnd, + TRACE( "win %p window (%ld,%ld)-(%ld,%ld) client (%ld,%ld)-(%ld,%ld)\n", hwnd, rectWindow->left, rectWindow->top, rectWindow->right, rectWindow->bottom, rectClient->left, rectClient->top, rectClient->right, rectClient->bottom ); } diff -aur orig/windows/winpos.c after/windows/winpos.c --- orig/windows/winpos.c 2002-12-21 21:52:40.000000000 -0800 +++ after/windows/winpos.c 2002-12-24 05:11:18.000000000 -0800 @@ -158,7 +158,7 @@ if (ret) { MapWindowPoints( GetAncestor( hwnd, GA_PARENT ), 0, (POINT *)rect, 2 ); - TRACE( "hwnd %p (%d,%d)-(%d,%d)\n", + TRACE( "hwnd %p (%ld,%ld)-(%ld,%ld)\n", hwnd, rect->left, rect->top, rect->right, rect->bottom); } return ret;

Dec. 24, 2002

'make test' failure on sysparams.c

by Dan Kegel

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

Dec. 24, 2002

Wine Contrib v0.4

by Dimitrie O. Paun

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.

Dec. 24, 2002

Re: winebuild -N generalization (take 2)

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Yeah, that's why I said it's a hack. What about a new -F option? Sure that would be fine. -- Alexandre Julliard julliard(a)winehq.com

Dec. 23, 2002

Re: tchar fixes: _tcs{dup,icmp}

by Francois Gouget

On Mon, 23 Dec 2002, Dimitrie O. Paun wrote: > That's what I have to do on my system. > > Francois, does this seem OK to you? If the fix is right, > what about the other _str* symbols? According to the latest sdk I have (2000), _tcsdup is supposed to map to _strdup and _tcsicmp to _stricmp. I think the catch is you are supposed to link with the msvcrt library since these symbols are only exported there. Now, pointing _tcsdup to strdup should not make any difference. However I am not sure that _stricmp really behaves exactly like strcasecmp: you would need to check how each of these handles accentuated characters and locale. Then the question is whether tchar.h should be considered to be a pure msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether we want to make is usable in Ansi mode with a regular C library. Currently we set the macros based on _MBCS and _UNICODE. Maybe we need to add a WINE_LIBC flag and add mappings to the native C library routines? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.

Dec. 23, 2002

Re: wine/. configure.ac configure

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.de> writes: > i don't think this patch is too correct. I get in the Makefiles > following: > INSTALL = $(TOPSRCDIR)//usr/bin/install -c $(INSTALL_FLAGS) > and that obviously dosn't exist thus make install is failing. That was a quoting problem, should be fixed now. Thanks for the note. -- Alexandre Julliard julliard(a)winehq.com

Dec. 23, 2002

Re: winebuild -N generalization (take 2)

by Dimitrie O. Paun

On December 23, 2002 08:07 pm, Alexandre Julliard wrote: > No, it's still wrong IMO. DLLName and DLLFileName are two different > things and you shouldn't use the same option for both. Yeah, that's why I said it's a hack. What about a new -F option? -- Dimi.

Dec. 23, 2002

Re: wine/. configure.ac configure

by Michael Stefaniuc

Hello, i don't think this patch is too correct. I get in the Makefiles following: INSTALL = $(TOPSRCDIR)//usr/bin/install -c $(INSTALL_FLAGS) and that obviously dosn't exist thus make install is failing. bye michael On Mon, Dec 23, 2002 at 06:35:19PM -0600, Alexandre Julliard wrote: > ChangeSet ID: 6794 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/23 18:35:19 > > Modified files: > . : configure.ac configure > > Log message: > Make sure INSTALL path is relative to the top dir when using the > script in tools/. > > Patch: http://cvs.winehq.com/patch.py?id=6794 > > Old revision New revision Changes Path > 1.112 1.113 +6 -1 wine/configure.ac > 1.380 1.381 +1993 -652 wine/configure -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 23, 2002

Re: winebuild -N generalization (take 2)

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > What about this hack instead? Alexandre, if this is acceptable, > I can update the man page and submit a patch. Motivation for > having an option to force the DLLFileName is as before. No, it's still wrong IMO. DLLName and DLLFileName are two different things and you shouldn't use the same option for both. -- Alexandre Julliard julliard(a)winehq.com

Dec. 23, 2002

winebuild -N generalization (take 2)

by Dimitrie O. Paun

Of course, 99.99% percent of my previous message on this subject was just a bunch of crap, sorry to waste bandwidth, and kill neurons. I just want to note the DLLFileName has a very well defined semantics that should not get changed as I initially suggested. Mea culpa. What about this hack instead? Alexandre, if this is acceptable, I can update the man page and submit a patch. Motivation for having an option to force the DLLFileName is as before. Index: tools/winebuild/main.c =================================================================== RCS file: /var/cvs/wine/tools/winebuild/main.c,v retrieving revision 1.43 diff -u -r1.43 main.c --- tools/winebuild/main.c 12 Dec 2002 04:06:28 -0000 1.43 +++ tools/winebuild/main.c 23 Dec 2002 23:53:26 -0000 @@ -263,6 +263,7 @@ { strncpy( DLLName, arg, sizeof(DLLName) ); DLLName[sizeof(DLLName) - 1] = 0; + set_dll_file_name( arg ); } static void do_entry( const char *arg ) -- Dimi.

Dec. 23, 2002

Re: winebuild -N generalization

by Dimitrie O. Paun

On December 23, 2002 03:10 pm, Dimitrie O. Paun wrote: > ChangeLog > Support the -N option in all modes. <blush>This doesn't work.</blush> -- Dimi.

Dec. 23, 2002

Re: Winelib Apps v0.2

by Jeff Smith

Dimi, Alexandre has implemented import libraries. Your page does not yet reflect this fact. -- Jeff S >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >Hi, > >It's been almost a month since the last release of the >Winelib page, and a _lot_ has changes since then: > http://www.dssd.ca/wine/Winelib-Apps-0.2.html > >The page has been reorganized, enhanced, etc. Too many >changes to list here. If you haven't followed the working >version, it's a good time to check it out. > >-- >Dimi. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail&xAPID=42&PS=47575&PI=7324&… http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_addphotos_…

Dec. 23, 2002

Re: Winelib Apps v0.2

by Dimitrie O. Paun

On December 23, 2002 05:03 pm, Jeff Smith wrote: > Alexandre has implemented import libraries. Your > page does not yet reflect this fact. Yes, thanks for catching it. Updated in the working version, available here: http://www.dssd.ca/wine/Winelib-Apps.html -- Dimi.

Dec. 23, 2002

Re: Changing FS type reported by Wine

by Tony Lambregts

Duane Clark wrote: > Stephen Mollett wrote: > >> >> I'm using ReiserFS. I've also tried on a 40GB ext3 filesystem on a >> spare drive. The error comes from VirtualDub, which believes that >> it's running on a FAT32 filesystem (obviously that's what Wine >> reports to any program that asks what FS type a drive is). I've tried >> working around it by using vdub's 'segmented AVI' feature (which >> creates multiple AVIs <= 2GB) but I can't use these successfully >> under Linux. > > > In the file wine/files/drive.c, in the function > GetVolumeInformationW() (down around line 1965), is this: > > > if (fsname && fsname_len) > { > /* Diablo checks that return code ... */ > if (DOSDrives[drive].type == DRIVE_CDROM) > { > static const WCHAR cdfsW[] = {'C','D','F','S',0}; > strncpyW( fsname, cdfsW, fsname_len ); > } > else > { > static const WCHAR fatW[] = {'F','A','T',0}; > strncpyW( fsname, fatW, fsname_len ); > } > fsname[fsname_len - 1] = 0; /* ensure 0 termination */ > } > > That appears to hardcode the filesystem "name" to FAT. You might try > changing that to NTFS. That assumes that this is the call your app is > using to determine filesystem type. > > I assume you have already determined that ReiserFS supports files > larger than 2GB? > 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. -- Tony Lambregts

Dec. 23, 2002

making an so wrapper for a windows dll

by Patrick Michael Kane

Hi: I have some business logic that is wrapped up inside of a 32-bit Windows DLL. Unfortunately, the source code to this DLL is not available and it is unlikely to be ported to Linux anytime soon. The good news is that the DLL is just a bunch of business logic. It doesn't try to access hardware directly, rely on 9000 other DLLs, etc. My goal here is to end up with a Linux shared library that wraps the DLL, so that I can then create wrappers to call the business logic from Perl and/or Python. winemaker seems to want to build an application, not a library. mplayer/aviplayer seem to do this sort of thing, but there's no documentation and it's all fairly obscure to a newcomer. Is there a quick and easy way to accomplish this? If not, is there a Wine developer who might be interested in a small consulting project to solve this problem? Best, -- Patrick Michael Kane <modus(a)pr.es.to>

Dec. 23, 2002

Re: wineboot - Andy's version

by Andreas Mohr

On Tue, Dec 17, 2002 at 09:17:48PM +0200, Shachar Shemesh wrote: > Changelog: > Andreas Mohr > > programs/wineboot > > * Initial implementation This is exactly my implementation AFAICS. I could easily have submitted it on my own, thank you very much. Instead, I thought that somebody should refine some parts before submitting. Also, GUI.txt was meant to be an internal note only. Hmm, well, maybe it's indeed best to have it committed now and then get some improvements real soon. (like e.g. to have it integrated into startup) Andreas Mohr

Dec. 23, 2002

Winelib Apps v0.2

by Dimitrie O. Paun

Hi, It's been almost a month since the last release of the Winelib page, and a _lot_ has changes since then: http://www.dssd.ca/wine/Winelib-Apps-0.2.html The page has been reorganized, enhanced, etc. Too many changes to list here. If you haven't followed the working version, it's a good time to check it out. -- Dimi.

Dec. 23, 2002

Couldn't find a decent font, aborting

by Mark Knecht

Hi, On many installations, and even when running just wcmd, I'm getting this error message: [mark(a)Godzilla mark]$ wcmd err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting [mark(a)Godzilla mark]$ wine --version Wine 20021219 [mark(a)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

Dec. 23, 2002

Re: DDE command 'ActivateProgMan'?

by Mike Hearn

I'm no expert, but that sounds like it's part of the code to add stuff to the start menu. As WineHQ doesn't have menu integration, it doesn't work. Wine does have its own program manager implementation, I suppose this means it's not being found/started correctly. On Mon, 2002-12-23 at 06:17, Dan Kegel wrote: > With current CVS wine, doing a minimum install of MSVC4 > works fine (once you jump through the proper hoops), but > at the very end, I get the dialog box > Setup cannot execute the DDE command 'ActivateProgMan' > Press Abort to to (sic) stop installing shortcuts and continue Setup. > > I googled for ActivateProgMan, but found nothing... > > For the moment, I'm just going to say "Press Abort" in my > recipe for running msvc4 under Wine. > I'd be willing to track this down further if someone > feels like pointing me in the right direction. > - Dan -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 23, 2002

msvc4 success!

by Dan Kegel

wine still needs some polish before it can install msvc4 nicely, but it can indeed install it, and the installed copy of msdev appears to work! I used the IDE to create a "hello, world" console app, and it compiled and ran perfectly! The UI seems snappy enough on my dual pentium 650, too. I'm sure I'll find many problems with this later, but for now, I think it's awesome that Wine can install and run msvc4 at all! - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 23, 2002

DDE command 'ActivateProgMan'?

by Dan Kegel

With current CVS wine, doing a minimum install of MSVC4 works fine (once you jump through the proper hoops), but at the very end, I get the dialog box Setup cannot execute the DDE command 'ActivateProgMan' Press Abort to to (sic) stop installing shortcuts and continue Setup. I googled for ActivateProgMan, but found nothing... For the moment, I'm just going to say "Press Abort" in my recipe for running msvc4 under Wine. I'd be willing to track this down further if someone feels like pointing me in the right direction. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 23, 2002

MSVC4, "install" button. Possible wine bug.

by Dan Kegel

Big progress. Turns out the best way to trace these installer splash screens is wine --debugmsg +exec since all they do is exec other programs. The only problem with this button under Wine is that the current working directory MUST be /mnt/cdrom before starting setup.exe for the "install" button to work, else it doesn't find the subdirectory's setup.exe to launch. This is not true under Windows. This seems like an important little difference to track down. I guess something in Windows might implicitly change the working directory of a newly launched program, or...? I suppose I could write a little win32 program to mimic what setup.exe is doing, and see if it behaves differently on Windows and on Wine. I feel a regression test coming on... I might not have time to get to this for a bit, so I'm posting the output of wine --debugmsg +exec,+dosfs,+file d:setup.exe (click on "Install Visual C++" button) to http://kegel.com/msvc4/install.txt.gz in case someone else wants to look. Search for ShellExecute to find the interesting bits. The current directory is my Wine directory... disappointing the program, which expected it to be the root of the cd-rom. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 22, 2002

Re: Serious problem with / and mount points

by Tony Lambregts

Sylvain Petreolle wrote: > --- Tony Lambregts <tony_lambregts(a)telusplanet.net> a écrit : > Jeff >Smith wrote: > > >>>What I have so far: >>> in files/dos_fs.c:1343, drive is receiving the value -1. >>> at line 1358, this is blindly added to 'A'. As you may >>> know, in ASCII, 'A' - 1 = '@'. >>> >>> >The problem is that we don't check the status of DRIVE_FindDriveRoot, >as you spotted it. >The sources clearly states that -1 is error. > Well I was convinced it should not be an error. The path is valid if you are sitting at the mount point. Part of the problem is that the drives are initialized when the program starts, this sets the .ino for that drive, however the ino for a removeable drive can change depending on whether it is mounted or not. DRIVE_FindDriveRootW does the same thing without relying on the .ino. I have modified DRIVE_FindDriveRoot to work the same way. The way I see it is that if the drive is removable (or network) .ino is not a good way of dealing with it. Change Log: Modify DRIVE_FindDriveRoot to not use .ino Files: files/drive.c Tony Lambregts Index: drive.c =================================================================== RCS file: /home/wine/wine/files/drive.c,v retrieving revision 1.80 diff -u -r1.80 drive.c --- drive.c 7 Dec 2002 23:47:01 -0000 1.80 +++ drive.c 23 Dec 2002 05:21:21 -0000 @@ -408,63 +408,36 @@ */ int DRIVE_FindDriveRoot( const char **path ) { - /* Starting with the full path, check if the device and inode match any of - * the wine 'drives'. If not then remove the last path component and try - * again. If the last component was a '..' then skip a normal component - * since it's a directory that's ascended back out of. - */ - int drive, level, len; + int drive, rootdrive = -1; char buffer[MAX_PATHNAME_LEN]; char *p; - struct stat st; + int len = -1, match_len = -1 ; strcpy( buffer, *path ); while ((p = strchr( buffer, '\\' )) != NULL) - *p = '/'; - len = strlen(buffer); - - /* strip off trailing slashes */ - while (len > 1 && buffer[len - 1] == '/') buffer[--len] = 0; - - for (;;) + *p = '/'; + + for (drive = 0; drive < MAX_DOS_DRIVES; drive++) { - /* Find the drive */ - if (stat( buffer, &st ) == 0 && S_ISDIR( st.st_mode )) - { - for (drive = 0; drive < MAX_DOS_DRIVES; drive++) - { - if (!DOSDrives[drive].root || - (DOSDrives[drive].flags & DRIVE_DISABLED)) - continue; - - if ((DOSDrives[drive].dev == st.st_dev) && - (DOSDrives[drive].ino == st.st_ino)) - { - if (len == 1) len = 0; /* preserve root slash in returned path */ - TRACE( "%s -> drive %c:, root='%s', name='%s'\n", - *path, 'A' + drive, buffer, *path + len); - *path += len; - if (!**path) *path = "\\"; - return drive; - } - } - } - if (len <= 1) return -1; /* reached root */ - - level = 0; - while (level < 1) - { - /* find start of the last path component */ - while (len > 1 && buffer[len - 1] != '/') len--; - if (!buffer[len]) break; /* empty component -> reached root */ - /* does removing it take us up a level? */ - if (strcmp( buffer + len, "." ) != 0) - level += strcmp( buffer + len, ".." ) ? 1 : -1; - buffer[len] = 0; - /* strip off trailing slashes */ - while (len > 1 && buffer[len - 1] == '/') buffer[--len] = 0; - } + if (!DOSDrives[drive].root || + (DOSDrives[drive].flags & DRIVE_DISABLED)) continue; + + len = strlen(DOSDrives[drive].root); + if(strncmp(DOSDrives[drive].root, buffer, len)) continue; + + if(len <= match_len) continue; + match_len = len; + rootdrive = drive; + drive = MAX_DOS_DRIVES + 1; + } + if (rootdrive != -1) + { + TRACE("%s -> drive %c:, root='%s', name=%s\n", + *path, 'A' + rootdrive, DOSDrives[rootdrive].root, *path + len) ; + *path += len; + if (!**path) *path = "\\"; } + return rootdrive; }

Dec. 22, 2002

Re: A crash destroying imagelists

by Dimitrie O. Paun

On December 22, 2002 02:50 pm, Duane Clark wrote: > That area is then freed. When freed, COMCTL32_Free writes prev and next > entries into himl. Where? COMCTL32_Free() simply calls HeapFree(): BOOL WINAPI COMCTL32_Free (LPVOID lpMem) { TRACE("(%p)\n", lpMem); return HeapFree (COMCTL32_hHeap, 0, lpMem); } > The listview does not know that the imagelist was already destroyed, so > it again calls ImageList_Destroy. Yes, a common problem. > At the end of ImageList_Destroy, there is a call to ZeroMemory, which > obliterates the prev and next pointers which had been written there. > Then another COMCTL32_Free call detects the error. At least I assume it > is an error. Does this work any better? It shouldn't make any difference, but ... There is something else funny here. I can't see why zeroing out an area we're just about to free is problematic. Index: dlls/comctl32/imagelist.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.68 diff -u -r1.68 imagelist.c --- dlls/comctl32/imagelist.c 5 Dec 2002 20:33:09 -0000 1.68 +++ dlls/comctl32/imagelist.c 23 Dec 2002 04:37:55 -0000 @@ -693,7 +693,7 @@ if (himl->hbrBlend50) DeleteObject (himl->hbrBlend50); - ZeroMemory(himl, sizeof(*himl)); + ZeroMemory(himl, sizeof(struct _IMAGELIST)); COMCTL32_Free (himl); return TRUE; -- Dimi.

Dec. 22, 2002

Re: [RFH] _FORCENAMELESSUNION

by Dimitrie O. Paun

On December 22, 2002 02:22 pm, Francois Gouget wrote: > Maybe you should submit patches to wxWindows and/or MinGW. I think this > could only improve these projects to be more compatible with the Windows > headers... Well, but of course, I just want to make sure I fix the right thing. You see, I don't have the any MS devel stuff, so I have to ask if our implementation is correct or not. If it is, a fix we'll go to the other projects, don't worry :) -- Dimi.

Dec. 22, 2002

Re: MSVC4, next two buttons on installer

by Dan Kegel

Eric Pouech wrote: > so you're stuck with either using native riched20.dll, or doing lots of > hard work to implement version 1.0 and 2.0 Er, ok, I'll stick with native for now :-) >> Q2. Any idea what I'd need to do to get a Windows Explorer going >> without actually installing the real Windows Explorer?-) >> Does Wine have a builtin Windows Explorer clone yet? > > there's a winfile compatible (winefile) in the programs directory, but > this isn't really an explorer clone. however making it explorer.exe > compatible (from the command line point of view) shouldn't be too > difficult. but there are lots of other stuff in there (DDE server for > example) which will require quite some work too. Cool. OK, here's how things stand, then: With native mfc42.dll, riched20.dll, and wordpad.exe, and winefile running, I can put the msvc4.0 cd-rom in the drive, mount it, click on the 'd:' drive icon in winefile, double-click on setup.exe, and the setup program launches properly; clicking on "Standard Template Library" properly brings up WordPad (yay!), but with a display problem (see below); clicking on "Explore the CD" does nothing (because I didn't install native Windows Explorer). Q3. Although I'm using native riched20 and wordpad, all the section headers in the stl\Readme.WRI file are screwed up under Wine. Anyone seen that problem before, or know how to fix it? I've uploaded the file as http://www.kegel.com/readme.wri in case anyone wants to see it. Q4. Is winefile going to be installed in some standard place? I'm quite willing to write a tiny, stunted windows\explorer.exe that's just a wrapper around winefile, but that won't help if the standard installer isn't yet installing winefile. Also, is it a problem that winefile is a winelib application? Wouldn't we rather it be a straight Windows application if we're going to invoke it from inside wine? Thanks, Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 22, 2002

Re: Winemaker line 3041: "WRCFLAGS = -r -L" -> "WRCFLAGS = -r" ?

by Tony Lambregts

Kjetil S. Matheussen wrote: >Shouldnt it? Breaks the compilation of the vstserver. > >Please apply. :) > > > > Please refer to http://www.winehq.org/Docs/wine-devel/patches.shtml for how to submit future patches. Change Log: fix for compiling wstserver Files: tools/winemaker -- Tony Lambregts Index: winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.59 diff -u -r1.59 winemaker --- winemaker 15 Dec 2002 03:00:40 -0000 1.59 +++ winemaker 23 Dec 2002 01:45:47 -0000 @@ -3038,7 +3038,7 @@ WRC = @WRC@ CFLAGS = @CFLAGS@ CXXFLAGS = @CXXFLAGS@ -WRCFLAGS = -r -L +WRCFLAGS = -r OPTIONS = @OPTIONS@ -D_REENTRANT -DWINELIB $(GLOBAL_DEFINES) $(GLOBAL_INCLUDE_PATH) LIBS = @LIBS@ $(LIBRARY_PATH) ALLFLAGS = $(DEFINES) -I$(SRCDIR) $(INCLUDE_PATH) $(WINE_INCLUDE_PATH)

Dec. 22, 2002

Re: __WINE__ vs. __WINESRC__

by Francois Gouget

On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: [...] > So, my proposal is: let's rename the __WINE__ symbol (as it's > currently used) to something else (__WINESRC__, or whatever, > suggestions welcome), once that's done, define __WINE__ when > __WINESRC__ is not defined (the symbols would be mutually > exclusive). winemaker defines 'WINELIB'. But I'm open to change, '__WINE__' looks more like the others. Maybe '__WINELIB__' would do? (but I prefer '__WINE__') -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Dec. 22, 2002

Re: A crash destroying imagelists

by Duane Clark

Duane Clark wrote: > > ... > At the end of ImageList_Destroy, there is a call to ZeroMemory, which > obliterates the prev and next pointers which had been written there. > Then another COMCTL32_Free call detects the error. At least I assume it > is an error. And indeed simply commenting out the ZeroMemory fixes the application. Though I have no idea what the correct fix would be.

Dec. 22, 2002