April 2003 - Wine-Devel - list.winehq.org

Re: valgrind for WINE
by Alexandre Julliard April 4, 2003

April 4, 2003

Adam Gundy <arg(a)cyberscience.com> writes: > a new version of the valgrind patch has been uploaded to sourceforge - > the only change is a small fix to the signal handling which should > prevent "signal handler frame" uninitialized errors. > > http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… > > comments? bug reports? success stories? I played a bit with it, it works pretty well, and I have already fixed a few bugs found with it. Great work! I have also applied those of your fixes that seemed correct, the rest will need a bit more work The signal stuff in particular is not going to work properly with NPTL, it would be really better if we could somehow make valgrind use real threads. I have no idea if this is possible though. -- Alexandre Julliard julliard(a)winehq.com

4 9

winsock.h problem
by Dimitrie O. Paun April 3, 2003

April 3, 2003

I get this when trying to compile putty: winegcc -mno-cygwin -Wall -O2 -D_WINDOWS -DDEBUG -DWIN32S_COMPAT -DNO_SECURITY -D_NO_OLDNAMES -DNO_MULTIMON -I. -c winnet.c In file included from /usr/local/include/wine/windows/windows.h:62, from /usr/local/include/wine/windows/winsock.h:114, from winnet.c:46: /usr/local/include/wine/windows/winsock2.h:401: warning: type defaults to `int' in declaration of `SOCKET' /usr/local/include/wine/windows/winsock2.h:401: warning: `__stdcall__' attribute only applies to function types /usr/local/include/wine/windows/winsock2.h:401: parse error before "WSAAccept" /usr/local/include/wine/windows/winsock2.h:402: parse error before "DWORD" /usr/local/include/wine/windows/winsock2.h:403: parse error before "DWORD" /usr/local/include/wine/windows/winsock2.h:406: parse error before "const" /usr/local/include/wine/windows/winsock2.h:412: parse error before "HANDLE" /usr/local/include/wine/windows/winsock2.h:416: parse error before "HANDLE" /usr/local/include/wine/windows/winsock2.h:417: parse error before "LPWSAOVERLAPPED" /usr/local/include/wine/windows/winsock2.h:423: parse error before "u_long" /usr/local/include/wine/windows/winsock2.h:424: parse error before "u_short" /usr/local/include/wine/windows/winsock2.h:428: parse error before "DWORD" /usr/local/include/wine/windows/winsock2.h:435: parse error before "u_long" /usr/local/include/wine/windows/winsock2.h:436: parse error before "u_short" /usr/local/include/wine/windows/winsock2.h:438: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:439: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:440: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:443: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:444: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:445: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:449: warning: type defaults to `int' in declaration of `SOCKET' /usr/local/include/wine/windows/winsock2.h:449: warning: `__stdcall__' attribute only applies to function types /usr/local/include/wine/windows/winsock2.h:449: parse error before "WSASocketA" /usr/local/include/wine/windows/winsock2.h:450: warning: type defaults to `int' in declaration of `SOCKET' /usr/local/include/wine/windows/winsock2.h:450: warning: `__stdcall__' attribute only applies to function types /usr/local/include/wine/windows/winsock2.h:450: parse error before "WSASocketW" /usr/local/include/wine/windows/winsock2.h:451: parse error before "LPSOCKADDR" /usr/local/include/wine/windows/winsock2.h:452: parse error before "LPSOCKADDR" In file included from winnet.c:46: /usr/local/include/wine/windows/winsock.h:267: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:271: parse error before '}' token /usr/local/include/wine/windows/winsock.h:271: warning: type defaults to `int' in declaration of `PROTOENT' /usr/local/include/wine/windows/winsock.h:271: warning: type defaults to `int' in declaration of `PPROTOENT' /usr/local/include/wine/windows/winsock.h:271: warning: type defaults to `int' in declaration of `LPPROTOENT' /usr/local/include/wine/windows/winsock.h:271: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:279: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:284: parse error before '}' token /usr/local/include/wine/windows/winsock.h:345: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:350: parse error before '}' token /usr/local/include/wine/windows/winsock.h:350: warning: type defaults to `int' in declaration of `SERVENT' /usr/local/include/wine/windows/winsock.h:350: warning: type defaults to `int' in declaration of `PSERVENT' /usr/local/include/wine/windows/winsock.h:350: warning: type defaults to `int' in declaration of `LPSERVENT' /usr/local/include/wine/windows/winsock.h:350: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:359: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:366: parse error before '}' token /usr/local/include/wine/windows/winsock.h:366: warning: type defaults to `int' in declaration of `HOSTENT' /usr/local/include/wine/windows/winsock.h:366: warning: type defaults to `int' in declaration of `PHOSTENT' /usr/local/include/wine/windows/winsock.h:366: warning: type defaults to `int' in declaration of `LPHOSTENT' /usr/local/include/wine/windows/winsock.h:366: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:373: `SOCKET' redeclared as different kind of symbol /usr/local/include/wine/windows/winsock2.h:450: previous declaration of `SOCKET' /usr/local/include/wine/windows/winsock.h:383: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:386: parse error before '}' token /usr/local/include/wine/windows/winsock.h:386: warning: type defaults to `int' in declaration of `SOCKADDR' /usr/local/include/wine/windows/winsock.h:386: warning: type defaults to `int' in declaration of `PSOCKADDR' /usr/local/include/wine/windows/winsock.h:386: warning: type defaults to `int' in declaration of `LPSOCKADDR' /usr/local/include/wine/windows/winsock.h:386: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:389: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:392: parse error before '}' token /usr/local/include/wine/windows/winsock.h:392: warning: type defaults to `int' in declaration of `LINGER' /usr/local/include/wine/windows/winsock.h:392: warning: type defaults to `int' in declaration of `PLINGER' /usr/local/include/wine/windows/winsock.h:392: warning: type defaults to `int' in declaration of `LPLINGER' /usr/local/include/wine/windows/winsock.h:392: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:412: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:419: parse error before '}' token /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:419: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `FD_SET' /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `PFD_SET' /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `LPFD_SET' /usr/local/include/wine/windows/winsock.h:419: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:422: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:425: parse error before '}' token /usr/local/include/wine/windows/winsock.h:425: warning: type defaults to `int' in declaration of `TIMEVAL' /usr/local/include/wine/windows/winsock.h:425: warning: type defaults to `int' in declaration of `PTIMEVAL' /usr/local/include/wine/windows/winsock.h:425: warning: type defaults to `int' in declaration of `LPTIMEVAL' /usr/local/include/wine/windows/winsock.h:425: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:483: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:483: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:484: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:484: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:485: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:485: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:486: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:486: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:540: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:544: warning: type defaults to `int' in declaration of `S_un_b' /usr/local/include/wine/windows/winsock.h:544: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:549: parse error before '}' token /usr/local/include/wine/windows/winsock.h:549: warning: type defaults to `int' in declaration of `S_un' /usr/local/include/wine/windows/winsock.h:549: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:565: parse error before '}' token /usr/local/include/wine/windows/winsock.h:565: warning: type defaults to `int' in declaration of `IN_ADDR' /usr/local/include/wine/windows/winsock.h:565: warning: type defaults to `int' in declaration of `PIN_ADDR' /usr/local/include/wine/windows/winsock.h:565: warning: type defaults to `int' in declaration of `LPIN_ADDR' /usr/local/include/wine/windows/winsock.h:565: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:568: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:571: parse error before "sin_addr" /usr/local/include/wine/windows/winsock.h:571: warning: type defaults to `int' in declaration of `sin_addr' /usr/local/include/wine/windows/winsock.h:571: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:573: parse error before '}' token /usr/local/include/wine/windows/winsock.h:573: warning: type defaults to `int' in declaration of `SOCKADDR_IN' /usr/local/include/wine/windows/winsock.h:573: warning: type defaults to `int' in declaration of `PSOCKADDR_IN' /usr/local/include/wine/windows/winsock.h:573: warning: type defaults to `int' in declaration of `LPSOCKADDR_IN' /usr/local/include/wine/windows/winsock.h:573: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:583: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:591: parse error before '}' token /usr/local/include/wine/windows/winsock.h:591: warning: type defaults to `int' in declaration of `WSADATA' /usr/local/include/wine/windows/winsock.h:591: warning: type defaults to `int' in declaration of `LPWSADATA' /usr/local/include/wine/windows/winsock.h:591: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:903: parse error before "LPWSADATA" /usr/local/include/wine/windows/winsock.h:906: parse error before '*' token /usr/local/include/wine/windows/winsock.h:906: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:906: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:907: parse error before '*' token /usr/local/include/wine/windows/winsock.h:907: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:907: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:908: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:908: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:909: parse error before '*' token /usr/local/include/wine/windows/winsock.h:909: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:909: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:910: parse error before '*' token /usr/local/include/wine/windows/winsock.h:910: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:910: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:910: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:910: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:911: parse error before '*' token /usr/local/include/wine/windows/winsock.h:911: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:911: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:911: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:911: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:913: parse error before '*' token /usr/local/include/wine/windows/winsock.h:913: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:913: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:914: parse error before '*' token /usr/local/include/wine/windows/winsock.h:914: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:914: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:914: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:914: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:915: parse error before '*' token /usr/local/include/wine/windows/winsock.h:915: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:915: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:915: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:915: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:917: parse error before "WS" /usr/local/include/wine/windows/winsock.h:919: parse error before '*' token /usr/local/include/wine/windows/winsock.h:919: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:919: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:919: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:919: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:920: parse error before '*' token /usr/local/include/wine/windows/winsock.h:920: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:920: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:920: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:920: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:921: parse error before '*' token /usr/local/include/wine/windows/winsock.h:921: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:921: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:922: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:922: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:923: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:923: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:924: warning: parameter has incomplete type /usr/local/include/wine/windows/winsock.h:924: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:924: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:925: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:925: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:926: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:926: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:927: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:927: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:928: parse error before '*' token /usr/local/include/wine/windows/winsock.h:928: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:928: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:929: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:929: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:930: parse error before '*' token /usr/local/include/wine/windows/winsock.h:930: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:930: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:931: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:931: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:932: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:932: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:933: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:933: warning: parameter names (without types) in function declaration winnet.c: In function `sk_cleanup': winnet.c:143: warning: implicit declaration of function `closesocket' winnet.c: In function `sk_namelookup': winnet.c:239: warning: implicit declaration of function `inet_addr' winnet.c:275: warning: implicit declaration of function `gethostbyname' winnet.c:275: warning: assignment makes pointer from integer without a cast winnet.c:342: dereferencing pointer to incomplete type winnet.c:344: dereferencing pointer to incomplete type winnet.c:358: warning: implicit declaration of function `ntohl' winnet.c: In function `sk_getaddr': winnet.c:383: storage size of `a' isn't known winnet.c:384: warning: implicit declaration of function `htonl' winnet.c:385: warning: implicit declaration of function `inet_ntoa' winnet.c:385: warning: passing arg 2 of `strncpy' makes pointer from integer without a cast winnet.c:383: warning: unused variable `a' winnet.c: In function `sk_address_is_local': winnet.c:407: storage size of `a' isn't known winnet.c:407: warning: unused variable `a' winnet.c: In function `sk_addrcopy': winnet.c:434: storage size of `a' isn't known winnet.c:434: warning: unused variable `a' winnet.c: In function `sk_new': winnet.c:547: parse error before "a" winnet.c:573: warning: implicit declaration of function `socket' winnet.c:585: warning: implicit declaration of function `setsockopt' winnet.c:614: `a' undeclared (first use in this function) winnet.c:614: (Each undeclared identifier is reported only once winnet.c:614: for each function it appears in.) winnet.c:616: warning: implicit declaration of function `htons' winnet.c:625: warning: implicit declaration of function `bind' winnet.c:680: warning: implicit declaration of function `connect' winnet.c: In function `sk_newlistener': winnet.c:725: parse error before "a" winnet.c:778: `a' undeclared (first use in this function) winnet.c:826: warning: implicit declaration of function `listen' winnet.c: In function `try_send': winnet.c:876: warning: implicit declaration of function `send' winnet.c: In function `select_result': winnet.c:1012: warning: implicit declaration of function `ioctlsocket' winnet.c:1023: warning: implicit declaration of function `recv' winnet.c:1092: storage size of `isa' isn't known winnet.c:1093: sizeof applied to an incomplete type winnet.c:1096: sizeof applied to an incomplete type winnet.c:1098: warning: implicit declaration of function `accept' winnet.c:1092: warning: unused variable `isa' winnet.c: In function `net_service_lookup': winnet.c:1219: warning: implicit declaration of function `getservbyname' winnet.c:1219: warning: assignment makes pointer from integer without a cast winnet.c:1221: warning: implicit declaration of function `ntohs' winnet.c:1221: dereferencing pointer to incomplete type Error: gcc failed. make: *** [winnet.o] Error 2 [dimi(a)dimi putty]$ -- Dimi.

2 4

PuTTY: server infinite loop
by Dimitrie O. Paun April 3, 2003

April 3, 2003

On startup, PuTTY remains in an infinite loop. A run with --debugmsg +all reveals the following repeating sequence: [...] 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=0049035c, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=1 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423955.356901 (-0.000050), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423955.357089 (-0.000027), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: set_queue_mask( wake_mask=00000040, changed_mask=0000007f, skip_wait=1 ) 000b: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000b: select( flags=4, cookie=0x40801c18, timeout=0, handles={0x38,0x3c} ) 000b: select() = PENDING 000b: *wakeup* signaled=0 cookie=0x40801c18 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423955.854213 (-0.000046), handles={0x3c} ) 000b: select() = TIMEOUT [the above seems to be repeated ad infinitum] 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=0049054f, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=0 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423955.855377 (-0.000051), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423955.855568 (-0.000027), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: set_queue_mask( wake_mask=00000040, changed_mask=0000007f, skip_wait=1 ) 000b: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000b: select( flags=4, cookie=0x40801c18, timeout=0, handles={0x38,0x3c} ) 000b: select() = PENDING 000b: *wakeup* signaled=0 cookie=0x40801c18 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.355795 (-0.000045), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=00490744, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=1 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423956.356958 (-0.000052), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.357150 (-0.000027), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: set_queue_mask( wake_mask=00000040, changed_mask=0000007f, skip_wait=1 ) 000b: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000b: select( flags=4, cookie=0x40801c18, timeout=0, handles={0x38,0x3c} ) 000b: select() = PENDING 000b: *wakeup* signaled=0 cookie=0x40801c18 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.853835 (-0.000046), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=00490936, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=0 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423956.855226 (-0.000113), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.855488 (-0.000026), handles={0x3c} ) 000b: select() = TIMEOUT [... ad infinitum...] -- Dimi.

1 0

Re: PATCH: provide MSVCRTD.DLL debugging C runtime DLL
by Alexandre Julliard April 3, 2003

April 3, 2003

Adam Gundy <arg(a)cyberscience.com> writes: > * dlls/Makefile.in: Rebuild the msvcrt directory twice, once for > msvcrt.dll.so and once for the debug msvcrtd.dll.so. You can't do that, the Makefile.in is generated automatically. I'd suggest creating a separate directory for msvcrtd and make it forward everything to msvcrt like crtdll does. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: valgrind for WINE
by Adam Gundy April 3, 2003

April 3, 2003

At 19:45 01/04/03 -0600, Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: >Adam Gundy wrote: >> a new version of the valgrind patch has been uploaded to sourceforge - >> the only change is a small fix to the signal handling which should >> prevent "signal handler frame" uninitialized errors. >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… >> >> comments? bug reports? success stories? > >did test it yet. > >As a global note, I think it would be appreciated breaking the patch in >smaller bits... it makes it easier to track/follow what happens. For >example, I don't see any reason for including the msvcrtd patches into >this patch the reason msvcrtd is there is that you need to use it for valgrind to do any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c) is required to tell valgrind that freshly allocated blocks are uninitialized, and the freed blocks are now invalid. If you build a debug executable using MSVC you have to use MSVCRTD.DLL, hence the new spec file for msvcrtd.dll.so >I think that Alexandre is currently integrating (bit per bit) your >changes into wine. look for the patch about zeroing the request zones >(which is another implementation of your structure packing), as well as >local availability of the thread PID haven't seen these yet >on a more minor side of things, I would keep the VALGRIND prefix in heap.c not sure what you mean here, but the heap.c stuff appears to have been committed (slightly rewritten by the look of it...). To be of ANY use you need the MSVCRTD stuff as well though! >last point, using the .vg extension to the wine script may not be >optimal. it won't work (as it is written) for winelib programs (which >got started also thru the wine script) >one solution would be (to follow your idea) to link (for a winelib app >called foo) foo.vg to script wine (and change your rule something like >*.vg|*/*.vg). another option would be to embed this support as an option >to the wine script (like --valgrind) maybe, this was just a hack to make it easier to use "in tree". not sure people would want a "--valgrind" switch in a (presumably) production winelib piece of software - it would show the world all your bugs ;-) >how are your patches doing on the "other side" (I mean valgrind's) ? just starting to make progress into CVS commits - there appear to be several other patches which overlap with mine, so there will probably be some ordering and refactoring required... Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

4 12

glibc 2.3.2 and Xilinx Webpack 5.1
by Steven Garrison April 3, 2003

April 3, 2003

I am running RedHat 9.0 and wine 20030219. So I have run afoul of the new thread issue. I cannot successfully install the Xilinx Webpack tools with the current setup which includes: setting LD_ASSUME_KERNEL=2.2.5 or setting the kernel parameter nosysinfo. The install dies with the following error with either of the above settings: wine setup.exe fixme:ntdll:RtlImpersonateSelf (00000002), stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x40b9ea98): stub fixme:ntdll:RtlAddAccessAllowedAce (0x403b3ff0,0x00000002,0x00000003,0x403b3fb0),stub! fixme:ntdll:NtAccessCheck (0x403b3fd0, 0xcafe, 00000001, 0x40b9eacc, 0x40b9eab0, 0x40b9eadc, 0x40b9eac4, 0x40b9eaa8), stub fixme:advapi:RevertToSelf (), stub XIO: fatal IO error 2 (Success) on X server ":0.0" after 5251 requests (5243 known processed) with 0 events remaining. This package does install and run if I follow the instructions posted on the comp.emulators.ms-windows.wine thread with RedHat 8.0, kernel 2.4.20 and XFree86 4.3.0. So there are applications that do not now run under RedHat 9.0 with the new threading disabled. -Steve Garrison

4 3

loading dlls & winemaker & --wrap option
by Juraj Hercek April 3, 2003

April 3, 2003

Hi, I would like to know whether it's important to load xyz.dll.so using dlopen() *before* I would use LoadLibrary() on xyz.dll and call GetProcAddress() to get address of function I would like to call. "winemaker --wrap" uses this way to get adress of WinMain/main in wrapped executable. However, I've figured out that it is not needed to dlopen shared object before it can be used by LoadLibrary() function. It work's without dlopening - I'm surprised & happy, since it was annoying to dlopen .so file before using. I also know it *was* needed before. Reason why I'm asking is that I want to be sure it's save to get rid of dlopen/dlclose functions and related stuff in <filename_>wrapper.c file created by winemaker. --Juraj

1 0

Re: Re[2]: SEGFAULT on WM_SETFOCUS
by Sylvain Petreolle April 3, 2003

April 3, 2003

oops... didnt see your name :) --- Vitaliy Margolen <wine-devel(a)kievinfo.com> a écrit : > Thanks for the replay, but I'm already between steps 6.1.11 - debug > it and > 6.1.12 - Fix it. ;-) > > Thursday, April 3, 2003, 12:00:00 AM, you wrote: > > > Please use the wine-users list and read > > http://www.winehq.com/docs/wine-user/bugs.shtml. > > > --- Vitaliy Margolen <wine-devel(a)kievinfo.com> a écrit : > >> I'm getting more and more of %subj%. Most of the time when I > closing > >> window. > >> After that program tries to show some error message box, but > frizzes > >> up (main > >> window). Other windows continue to update. But can't get focus or > >> keyboard > >> input. Debugger doesn't say anything, after initial segfault. > >> > >> This problem appeared some time in January-February. Last week it > got > >> really bad. > >> The e-mail program I'm using (The Bat) frizzing up every time I'm > >> closing message > >> window. > >> > >> Any advise on what should I look for (--debugmsg)? > > > ===== > > Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ > #170597259 > > No more War ! > > > "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". > > > For the Law of Oil and Fire, Im an European that lives in France. > > For all my Brothers and friends, Im a human living on Earth. > > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.com > ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

SEGFAULT on WM_SETFOCUS
by Vitaliy Margolen April 3, 2003

April 3, 2003

I'm getting more and more of %subj%. Most of the time when I closing window. After that program tries to show some error message box, but frizzes up (main window). Other windows continue to update. But can't get focus or keyboard input. Debugger doesn't say anything, after initial segfault. This problem appeared some time in January-February. Last week it got really bad. The e-mail program I'm using (The Bat) frizzing up every time I'm closing message window. Any advise on what should I look for (--debugmsg)? -- Best regards, Vitaliy Margolen

2 1

Re: Fix MaskEdit from Delphi
by Brad Campbell April 3, 2003

April 3, 2003

Vitaliy Margolen wrote: > This suppose to be SetKeyboardState function, not Reset :-) > > Vitaliy Margolen > > changelog: > remove bogus initialization in SetKeyboardState > Indeed that fixed part of the problem, but there is still an issue with the input box accepting more than three characters, where under windows 95/98 it will stop hard at three. Thanks for the fix and pointer though. I'll have a play and see if I can sus the other half out. -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

SMATCH: Returning with freed result
by Michael Stefaniuc April 2, 2003

April 2, 2003

Hello, this was found by unfree-wine.pl a slight modification of smatch's unfree.pl. The first occurence was easy to fix (see attachment) but i don't know what should be done in this case: dlls/ole32/filemoniker.c 1084 1086 FileMonikerImpl_CommonPrefixWith(75) Returning with freed result var_decl(commonPath) This is due to this code: HeapFree(GetProcessHeap(),0,commonPath); return CreateFileMoniker(commonPath,ppmkPrefix); I would save the return of CreateFileMoniker to a temp variable and after that free commonPath but i don't know if it's the desired fix. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - fix for return of a previous freed object bye michael -- 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

1 0

RE: glibc 2.3.2 and Xilinx Webpack 5.1
by Steven Garrison April 2, 2003

April 2, 2003

I'll give this a shot. One more thing, I'm running Gnome, the default environment of RedHat 9. I just did and here is the error output: export LD_ASSUME_KERNEL=2.2.5 [steveng(a)localhost xilinx]$ wine setup fixme:ntdll:RtlImpersonateSelf (00000002), stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x40b9ea98): stub fixme:ntdll:RtlAddAccessAllowedAce (0x403b3fe0,0x00000002,0x00000003,0x403b3fa0),stub! fixme:ntdll:NtAccessCheck (0x403b3fc0, 0xcafe, 00000001, 0x40b9eacc, 0x40b9eab0, 0x40b9eadc, 0x40b9eac4, 0x40b9eaa8), stub fixme:advapi:RevertToSelf (), stub XIO: fatal IO error 2 (Success) on X server ":0.0" after 8777 requests (8776 known processed) with 0 events remaining. I did not notice anything unusual in either /var/log/messages or /var/log/XFree86.0.log Thanks, Steve -----Original Message----- From: Uwe Bonnes [mailto:bon(a)elektron.ikp.physik.tu-darmstadt.de] Sent: Wednesday, April 02, 2003 12:04 PM To: Steven Garrison Cc: wine-devel(a)winehq.com Subject: Re: glibc 2.3.2 and Xilinx Webpack 5.1 >>>>> "Steven" == Steven Garrison <Steven.Garrison(a)siimage.com> writes: ... Steven> stub fixme:advapi:RevertToSelf (), stub XIO: fatal IO error 2 Steven> (Success) on X server ":0.0" after 5251 requests (5243 known Steven> processed) with 0 events remaining. Try running with "Synchronous" = "Y" in the ~/.wine/config [x11drv] section. Perhaps you get more information that way. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Any DCOM experts?
by Bill Medland April 2, 2003

April 2, 2003

Hi guys For the next part of the work I am doing I am trying to figure out if there is any way that the DCOM part of one of our products is going to work under Wine at the server end. I am not having much success so far and I was wondering if anyone knows whether this is because I don't have things set up properly or if it is because of some inherent known lack of functionality. To start the ball rolling I was working with MSDN's DCOMTST test program pair. I managed to get that working using the local server (after adding the definition of IStream to the registry) but am having no luck getting the client under Wine to talk to the server under Win98. In fact the client side doesn't even seem to send out a single TCP/IP packet. (Aside - Nice demonstration of lazy Microsoft code; in their error reporting they call FormatMessage, ignore the return code and somehow print the returned error message, even when one hasn't been allocated; I guess it only works under Windows because the print routine traps the access violation) I am currently running native ole32 and native rpcrt4. The builtin rpcrt4 fails on a call to unimplemented RpcServerInqDefaultPrincName but I don't understand why it is even calling that; why does it think I have Netware only and why does it think this is a server process. Anyone an expert in any of this stuff? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

3 5

Winemine colors
by Joshua Thielen April 2, 2003

April 2, 2003

Hello, I was just going through my old mail and I noticed Shachar's email (below) on Jan. 26. Just to let you know, I do try to keep up with the wine devel discussions, but as you can see, I'm not very successful. I still have a bug assigned to me that is almost a year old now. I'd like to work on wine more, but I've been really busy with school lately. Hopefully, I'll have more time when I graduate. Anyway, I chose that green color in winemine specifically to make it annoying ;). Actually, at the time I didn't want it to have a boring old gray background, so I chose green in order to make it would look like grass (a mine field). But I guess it's pretty annoying. Do you have a color preference? Do you or anyone else have more suggestions for improving winemine? Maybe ideas for a 3D minesweeper game or something? I wrote it like four years ago, and I didn't know a whole lot about what I was doing (I was in Comp. Sci. 1 when I wrote it). I'd like it to be more fun than your typical minesweeper game. Also, when I originally submitted it, someone complained that it was slow. Is this still the case for anyone out there? Thanks, Josh -------------------------------- >From Shachar Shemesh on Jan. 26: Tom Wickline wrote: > I am in the process of updating section 3.1. ( Wine Static and > Shareable Files ) of the > Packagers Guide : > http://www.winehq.com/Docs/wine-pkg/pkg-components.shtml#PKG-STATIC > > Below is a list of what I have so far. This list is by no means done > or correct . > I would like to submit it here for overview. If you are aware of > something that > is out of place, incorrect, or just out right wrong could you please give > feed back on it. > > This could also serve to start as a mini Wine Dictionary :)) > That is not my current goal but if others think it could be of use > I could spend some time on one after the Packagers Guide is updated. > > Tom > > > -------------------------------------------- > > -- = files that are listed in this Doc but are not installed on my > system. > * = files are in this Doc and on my system > @ = files that are on my system but not in the Doc > # = files that are not in the Doc or on my System ( wineboot ) Then how do you know of their existance ;-). If wineboot is not installed, that's a bug. We should fix it. I'll try to help with the things I know. This is far from authorative on most, however. > @ regedit : A tool to browse/edit your regestory or for exporting a > windows registory to Wine. Not browse. At least, not yet. > # wineboot : A Winelib application that's executed by Wine on startup > of the first wine process of a particular user. > * wininit.ini processing > * registry RenameFiles entries > * RunServices* / RunOnce* / Run registry keys > * win.ini Load= / Run= entries > * StartUp folder processing the last two are not yet done. Also not yet done is for wineboot to automatically run when needed. Currently you have to manually run it after you install something. > @ winemine : A winmine clone "Windows Minesweeper" ??? Yep, using horrid green colors. I'm sorry if I have offended the author (Joshua Thielen, are you still with us?) > @ winepath : Specifies the path(s) in which to search for builtin dlls > and Winelib applications. I think this is an executable that, given a Unix path, will tell you what Wine sees it like (i.e. - you tell it ~/c/windows, and it tells you C:\Windows). I'm not sure on that one. > -- winesetup : This is a Tcl/Tk based front end that provides a user > friendly tool to edit and configure the WINECONFDIR/config file. Anyone knows where it is? It was never based on the winehq sources. Shachar __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

2 1

Re: PATCH: dlls/ntdll/ntdll_misc.h and struct timeval
by Dimitrie O. Paun April 2, 2003

April 2, 2003

On Wed, 2 Apr 2003, Gerald Pfeifer wrote: > #define __WINE_NTDLL_MISC_H > > +#include <unistd.h> > #include "winnt.h" This needs something like this: +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif -- Dimi.

1 0

glibc tracker bug
by Mike Hearn April 2, 2003

April 2, 2003

Hi, As we've been getting quite a few reports of glibc 2.3.x related failures in bugzilla lately, it makes sense to mark them as dupes of a bug, so I've started duping them against bug #1343 http://bugs.winehq.com/show_bug.cgi?id=1343 That way, when these problems are sorted out, we won't have to go through and resolve them all manually. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

4 3

Re: ImageList - dirty hack
by Vitaliy Margolen April 2, 2003

April 2, 2003

Is there are any reason why this one haven't been checked in? This is pretty close to what windows does. Vitaliy Margolen > Fix ImageList_Read. This hopefully fixes these ugly images mostly on tool bars. > I'll continue to work on ImageList since ImageList_Replace, ImageList_Add, > ImageList_GetImageInfo and perhaps some other functions doesn't work right. > Vitaliy Margolen > changelog: > - dlls/comctl32/imagelist.c > fix ImageList_Read - the root cause of ugly toolbar icons > Index: dlls/comctl32/imagelist.c > =================================================================== [skip]

1 0

Compiling Wine sources with duplicated include parameters
by Rolf Kalbermatter April 2, 2003

April 2, 2003

While downloading and compiling the latest CVS sources I noticed that the command line for each (most?) source files reads like gcc -c -I. -I. -I../../include -I../../include ............. or similar This is not a serious problem but the duplication of the two include parameters strikes me as odd and definitely unnecessary, making the command line unnecessarily long. Seems like something in the makefile generation is causing this. Rolf Kalbermatter

5 8

Unexpected message from winebuild...
by Kevin Cousins April 2, 2003

April 2, 2003

...when attempting to build a WineLib application. Remember, I'm attempting to get something that will run-time link against a native DLL, so I take my code, run it by "winemaker", run "./configure", then "make", all with options I believe to be appropriate. In particular, given export WINEDIR=/home/kevin/wine, the root of my Wine source tree checked out from winehq CVS yesterday, and export DLLINCDIR=/home/kevin/include, then from within the directory containing the C source code for my simple console app I execute the following: $ winemaker --cuiexe -I${DLLINCDIR} -I${WINEDIR} [...snip...] $ ./configure --with-wine=${WINEDIR} \ --with-wine-dlls=${WINEDIR}/libs/dlls --srcdir=`pwd` \ --with-wine-libraries=${WINEDIR}/libs/wine:${WINEDIR}/libs/uuid:${WINEDIR}/libs/unicode [...snip...] $ make [...snip...] Until make executes, there seems to be no obvious problem (at least to my eyes), and even then, as the compilation happens, I get a nice file called "prog.o" written. However, as "winebuild" executes, I see the following: --- LD_LIBRARY_PATH="/home/kevin/wine/libs/wine:/home/kevin/wine/libs/unicode:$LD_LIBRARY_PATH" /home/kevin/wine/tools/winebuild/winebuild -fPIC -o prog.exe.spec.c --exe prog.exe -mcui prog.o -L/home/kevin/lib -L/home/kevin/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 -lshell32 -luser32 -lwinspool could not open .def file for advapi32 --- I don't believe I even need anything from advapi32.dll.so, let alone most of the other Wine DLLs mentioned on the winebuild command line. Even if I hack the generated Makefile so as to remove mention of any Wine DLLs on the winebuild command line, winebuild still complains about not opening "...a .def file for ntdll". On a related note, the configure script generated by winemaker complains about test linking against -L${WINEDIR}/dlls -lntdll.dll and subsequent equivalent builtin DLLs such as -lkernel32.dll and -luser32.dll. My quick hack is merely to clone the symbolic links in ${WINEDIR}/dlls to add a "lib" prefix, vis: $ ( cd ${WINEDIR}/dlls ; ls -l *ntdll.dll* ) lrwxrwxrwx 1 kevin 18 Apr 1 15:29 ntdll.dll.so -> ntdll/ntdll.dll.so lrwxrwxrwx 1 kevin 18 Apr 1 15:29 libntdll.dll.so -> ntdll/ntdll.dll.so $ That keeps configure happy, but I wonder what I'm doing wrong. This is Wine built from CVS as of 20030401 (i.e. yesterday). Suggestions? Particularly for the wanted .def files. They're %^*&@# builtin DLLs! -- Kevin.

2 1

Re: What happend to the Stdole2 / Stdole32 (RESEND) patch from Robert Shearman
by Robert Shearman April 2, 2003

April 2, 2003

> what happend to the stdole32.tlb patch that Robert sent around 22.1? It was rejected on the grounds that we shouldn't have binary files in CVS and we can't generate the .tlb files at the moment. Rob

1 0

Agent and threads
by Rein Klazes April 2, 2003

April 2, 2003

Hi, Agent news/email client spawns a new thread for each news/mail retrieval command. Something in the last week causes these threads not to be waited upon, leaving hundreds of <defunct> wine processes lying around. I wonder if this is a known issue with the new thread implementation work in progress, or if it is worth investigating? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

CVS Statistics for academic research
by Riccardo 'Jack' Lucchetti April 2, 2003

April 2, 2003

Hi all, this message was originally sent to Alexandre Juilliard; I am resending this to the list on his suggestion. I am a wine user and a regular mailing list lurker. Beside that, however, I earn my living as an academic econometrician (halfway between an economist and a statistician) and I was considering the idea of doing some econometric research on open source development. At least initially, I would focus on Wine, for a number or reasons, not least the fact that the wine project is largely unknown in the economics community. My problem is that the data I need for my analysis can be theoretically extracted from the mailing list archives, but this definitely exceeds my VERY limited perl skills. The data I'd need would, ideally, be in the form of a CSV file, a typical record of which would be DATE,PN,PLA,PLD,PCN,CN,CLA,CLD where PN = number of patches received on day DATE PLA = number of code lines added in patches PLD = number of code lines deleted in patches PCN = number of patches contributors (ie number of coders submitting patches on that particular day) CN = CVS commits CLA = number of lines added in CVS CLD = number of lines deleted in CVS Of course, the longer the time span the data cover, the larger my sample, the happier I am. I understand this isn't trivial. Is there anyone out there willing to help me? I know some perl, so maybe all I need is to get started somehow. Thanks in advance, and keep up the good work! ---------------------------------------------------------- Riccardo `Jack' Lucchetti Dipartimento di Economia Università di Ancona jack(a)dea.unian.it http://www.econ.unian.it/lucchetti

1 0

Re: Unexpected message from winebuild...
by juraj April 2, 2003

April 2, 2003

Hi Kevin, I had similar problem with winemaker when I used winemaker's --wrap option. I hacked winemaker script (see attachment) and managed to get rid of "...could not open .def file for...". If you see it, the difference is that .dll extension was removed from libnames in makefiles. I.e. there is only kernel32 instead of kernel32.dll, and so on. This helped me to get rid of problem with missing .def file.The second adjustment is related to incorrect generation of wrapper exe spec.c file. However, I'm not sure it's correct hack (that's the reason I didn't post it to wine-patches yet) since I have still troubles with running wrapped application - simple hello world example. The problem I have is that GetProcAddress couldn't find the WinMain() of my hello world app. After a little debugging and inspection of .spec.c file it seems the problem is with winebuild and not with winemaker (__wine_spec_exports is resolved to NULL and that's bad...). But I need to investigate little more yet. Anyways I got information from #winehq irc channel that winemaker is beeing deprecated, and that I should try to use winegcc with winewrap instead. But I'm not sure whether these two guys are able to cope with wrapping. I wasn't able to find some documentation about them and winewrap alone throws segmentation fault in my current build (updated & build today, about 3 hours ago). --Juraj Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.63 diff -u -r1.63 winemaker --- tools/winemaker 27 Mar 2003 18:36:27 -0000 1.63 +++ tools/winemaker 31 Mar 2003 20:53:53 -0000 @@ -1001,7 +1001,7 @@ @$wrapper[$T_TYPE]=@$target[$T_TYPE]; @$wrapper[$T_INIT]=get_default_init(@$target[$T_TYPE]); @$wrapper[$T_FLAGS]=$TF_WRAPPER | (@$target[$T_FLAGS] & $TF_MFC); - @$wrapper[$T_DLLS]=[ "kernel32.dll", "user32.dll" ]; + @$wrapper[$T_DLLS]=[ "kernel32", "user32" ]; push @{@$wrapper[$T_LIBRARIES]}, "dl"; push @{@$wrapper[$T_SOURCES_C]},"@$wrapper[$T_NAME]_wrapper.c"; @@ -1650,7 +1650,6 @@ my $path=$_[0]; my $target=$_[1]; my $app_name=@$target[$T_NAME]; - $app_name=~ s/\.exe$//; return generate_from_template("$path${app_name}_wrapper.c","wrapper.c",[ ["APP_NAME",$app_name],

1 0

What happend to the Stdole2 / Stdole32 (RESEND) patch from Robert Shearman
by Uwe Bonnes April 2, 2003

April 2, 2003

Hallo, what happend to the stdole32.tlb patch that Robertsent around 22.1? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: FindFirstFileExW
by Mike Hearn April 2, 2003

April 2, 2003

I ran my test case on 98, and that produced a return value of 2 as well (same as XP), so unless my test case is stuffed up, I think this patch is correct. The test is attached, it's extremely simple. On Tue, 2003-04-01 at 16:37, Mike Hearn wrote: > > That sounds awfully much like the already pretty well-known Win9x vs. NT > > incompatibility in file not found GetLastError values. > > Awwww suckage. I thought that fix was too easy. File not found > differences are new to me. Well I have a little test case for this, I'll > email it home and find out what it returns on Win98. > > If so, then, how do you find out what version of windows we're supposed > to be emulating, so I can adjust the return value accordingly? > > > Please make sure this is indeed what we should do; I really think > > you'd break some Win9x programs when simply doing such a general replacement. > > Hmm, well, the old value appeared to break some NT programs. > > > As such, I suspect you did not "Correct" the error code returned; > > instead, you only fixed it "to please the other half" of Windows programs. > > ;-) > > Right. So we need to change the return value depending on the setting of > winver? -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0