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

HEAP_ZERO_MEMORY was: Re: Prevent passing uninitialised string to WARN
by Uwe Bonnes Jan. 17, 2002

Jan. 17, 2002

>>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: Medland,> Bill Medland (medbi01(a)accpac.com) Prevent trying to handle Medland,> uninitialised memory as a string. Medland,> Index: wine/loader/module.c Medland,> =================================================================== Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving Medland,> revision 1.144 diff -u -r1.144 module.c --- Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++ Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7 @@ Medland,> filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 ); Medland,> if ( !filename ) return NULL; Medland,> + *filename = 0; /* Just in case Wouldn't HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0? This would apply to many places. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...
by Dmitry Timoshkov Jan. 17, 2002

Jan. 17, 2002

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > For me it looks like we need to keep both tests > together, because we'll want to compare results of W > and A versions. One more advantage - it is easier to > make changes because both versions are in one place. Then we should invent some approach to easily compare two strings: ANSI and Unicode. > What approach we will use with UNICODE tests on Win95 > platform? There is no difference in API between emulated Windows versions from the Wine point of view. -- Dmitry.

2 3

Re: DOSFS_ToFCBFormat Bug Fix
by Ove Kaaven Jan. 17, 2002

Jan. 17, 2002

On Sun, 13 Jan 2002 ccrayne(a)crayne.org wrote: > Change Log: > files/dos_fs.c > ccrayne(a)crayne.org > Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*." instead > of as "*.*" This sounds like intended behaviour. Under real DOS, "*" really means "*.". The user must type "*.*" to get all files. (This is the stuff that used to confuse DOS users converting to Linux - "*.*" no longer meant all files...) Also, your mailer seems to mangle your patches. You may want to attach them instead of pasting them to avoid that.

4 4

Re: user32.TrackMouseEvent
by David Elliott Jan. 17, 2002

Jan. 17, 2002

On 2002.01.15 11:37 Rein Klazes wrote: > hi, > > to implement user32.TrackMouseEvent: > > Changelog: > dlls/comctl32/ : commctrl.c > dlls/user/ : user32.spec > windows/ : input.c > include/ : winuser.h > > Move the implementation of comctl32._TrackMouseEvent to > user32.TrackMouseEvent and call this function in accordance > with the specs. > Man, it must not be my week. I did the exact same thing two days ago ('cept I put the TME stuff into windows/tme.c instead of adding it to input.c). Was part of making IE work as mentioned in my last mail regarding the stumbling block I hit with DPA that Aric has figured out. That'll teach me to leave patches sitting around in my tree for a couple days. -Dave

1 0

Re: common controls updown patch
by David Elliott Jan. 17, 2002

Jan. 17, 2002

On 2002.01.14 14:45 Shane Shields wrote: > hi all > > this is just a little patch to fix the UPDOWN_GetArrowRect function where > the > midpoint is calculated by adding 1 to odd numbers. before it just added 1 > to > every number now it tests for odd numbers before adding. > > Shane > > Thanks Dan for the tips > > Changelog: > > Shane Shields locutus(a)all.at > > updown.c UPDOWN_GetArrowRect function > added odd number checking > --- ./dlls/comctl32/updown.c.orig Mon Jan 14 20:35:07 2002 > +++ ./dlls/comctl32/updown.c Sun Jan 13 17:28:18 2002 > @@ -1,4 +1,4 @@ > -/* > +/* > * Updown control > * > * Copyright 1997 Dimitrie O. Paun > @@ -176,14 +176,16 @@ > * round the uneven numbers by adding 1. > */ > if (dwStyle & UDS_HORZ) { > - len = rect->right - rect->left + 1; /* compute the width */ > + len = rect->right - rect->left; /* compute the width */ > + if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */ > if (incr) > - rect->left = rect->left + len/2; > + rect->left = rect->left + len/2; > else > rect->right = rect->left + len/2; > } > else { > - len = rect->bottom - rect->top + 1; /* compute the height */ > + len = rect->bottom - rect->top; /* compute the height */ > + if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */ > if (incr) > rect->bottom = rect->top + len/2; > else > The remainder of any even number divided by two is 0, the remainder of any odd number divided by two is 1. Knowing this doesn't: len+=(len%2); make more sense. Leave the comment as is for clarity if you wish. -Dave

1 0

Re: basic structures for async IO in winsock
by lawson_whitney＠juno.com Jan. 17, 2002

Jan. 17, 2002

On Wed, 16 Jan 2002, Martin Wilck wrote: > > Patch: async-winsock.diff > Applies: CVS 2002-01-15 > > Introduce data structures and basic functions for asynchronous > Winsock2 operations. > > ChangeLog: > > include/winsock2.h: Fix LPWSAOVERLAPPED declaration. > dlls/winsock/socket.c: Add basic data strutures & functions for overlapped IO > in Winsock. > Juno 4 without the async winsock patches.

1 0

16 bit menus
by lawson_whitney＠juno.com Jan. 17, 2002

Jan. 17, 2002

Good day! Last time but one I tested juno 1.49 for regressions in 16 bit comms, it downloaded a new list of access numbers. Next it presented me with the attached menu (well, I attached a trace of it making the menu), which it expects me to work through and select a new number. Unfortunately, the menu seems to be either 0 or 1 pixels high and I can't find any of the controls in there. If somebody can tell me what parameter to what function provokes this, maybe I can work out a way to fix it. Of course, anybody who knows what [s]he is doing with menus is welcome to fix it, too. I have used this menu with this app, but not for perhaps a year. Lawson

1 0

[PATCH] Overlapped recv(), WSARecv()
by Martin Wilck Jan. 17, 2002

Jan. 17, 2002

This patch needs testing yet - I am sending it for people to review and point out errors right from the start. Currently I only verified that it compiles. ChangeLog: implement overlapped recv(), much like overlapped IO in files/file.c. make WS2_32 WSARecvFrom() the "working" function, all others are wrappers only. implement WSAGetOverlappedResult(). NOTE: My patches submitted yesterday and today (16/01) to wine-patches are necessary for this one to work. CVS base version is 2002-01-15. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy diff -ruX diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Wed Jan 16 18:14:19 2002 +++ MW/wine/dlls/winsock/socket.c Wed Jan 16 18:18:27 2002 @@ -85,6 +85,7 @@ #include "wine/winbase16.h" #include "wingdi.h" #include "winuser.h" +#include "winerror.h" #include "winsock2.h" #include "ws2tcpip.h" #include "wsipx.h" @@ -95,7 +96,6 @@ #include "file.h" #include "debugtools.h" - DEFAULT_DEBUG_CHANNEL(winsock); /* critical section to protect some non-rentrant net function */ @@ -167,11 +167,22 @@ if ( !as->user_overlapped ) HeapFree ( GetProcessHeap(), 0, as->overlapped ); + else + /* FIXME: is this correct? How else can we communicate the flags + to WSAGetOverlappedResult() ? */ + as->overlapped->Offset = as->flags; HeapFree ( GetProcessHeap(), 0, as->iovec ); HeapFree ( GetProcessHeap(), 0, as ); } +static void CALLBACK ws2_default_completion ( DWORD dwError, DWORD cbTransferred, + LPWSAOVERLAPPED lpOverlapped, + DWORD dwFlags ) +{ + NtSetEvent ( lpOverlapped->hEvent, NULL ); +} + /****************************************************************/ /* ----------------------------------- internal data */ @@ -307,14 +318,19 @@ static char* check_buffer(int size); -static int _get_sock_fd(SOCKET s) +static int _get_sock_fd_type (SOCKET s, enum fd_type *type, DWORD *flags) { - int fd = FILE_GetUnixHandle( s, GENERIC_READ ); + int fd = FILE_GetUnixHandleType ( s, GENERIC_READ, type, flags ); if (fd == -1) FIXME("handle %d is not a socket (GLE %ld)\n",s,GetLastError()); return fd; } +static int _get_sock_fd (SOCKET s) +{ + return _get_sock_fd_type (s, NULL, NULL); +} + static void _enable_event(SOCKET s, unsigned int event, unsigned int sstate, unsigned int cstate) { @@ -1887,34 +1903,16 @@ */ int WINAPI WS_recv(SOCKET s, char *buf, int len, int flags) { - int fd = _get_sock_fd(s); + DWORD n; + WSABUF wsabuf = { len, buf }; + DWORD dwFlags = flags; TRACE("socket %04x, buf %8x, len %d, flags %d\n", s, (unsigned)buf, len, flags); - if (fd != -1) - { - INT length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds? */ - do_block(fd, 1); - } - if ((length = recv(fd, buf, len, flags)) >= 0) - { - TRACE(" -> %i bytes\n", length); - - close(fd); - _enable_event(s, FD_READ, 0, 0); - return length; - } - SetLastError(wsaErrno()); - close(fd); - } - else SetLastError(WSAENOTSOCK); - WARN(" -> ERROR\n"); - return SOCKET_ERROR; + if ( WSARecv (s, &wsabuf, 1, &n, &dwFlags, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; + else + return n; } /*********************************************************************** @@ -1932,60 +1930,14 @@ int WINAPI WS_recvfrom(SOCKET s, char *buf, INT len, int flags, struct WS_sockaddr *from, int *fromlen) { - int fd = _get_sock_fd(s); - int res; - - TRACE("socket %04x, ptr %08x, len %d, flags %d\n", s, (unsigned)buf, len, flags); -#if DEBUG_SOCKADDR - if (from) - dump_sockaddr(from); - else - DPRINTF("from = NULL\n"); -#endif + DWORD n; + WSABUF wsabuf = { len, buf }; + DWORD dwFlags = flags; - res=SOCKET_ERROR; - if (fd != -1) - { - struct sockaddr* uaddr; - int uaddrlen; - int length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds */ - do_block(fd, 1); - } - - uaddr=ws_sockaddr_alloc(from,fromlen,&uaddrlen); - length=recvfrom(fd, buf, len, flags, uaddr, &uaddrlen); - if (length < 0) - { - SetLastError(wsaErrno()); - WARN(" -> ERROR\n"); - } - else if (ws_sockaddr_u2ws(uaddr,uaddrlen,from,fromlen) != 0) - { - /* The from buffer was too small, but we read the data - * anyway. Is that really bad? - */ - SetLastError(WSAEFAULT); - WARN(" -> WSAEFAULT\n"); - } - else - { - TRACE(" -> %i bytes\n", length); - _enable_event(s, FD_READ, 0, 0); - res=length; - } - close(fd); - } + if ( WSARecvFrom (s, &wsabuf, 1, &n, &dwFlags, from, fromlen, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; else - { - SetLastError(WSAENOTSOCK); - WARN(" -> WSAENOTSOCK\n"); - } - return res; + return n; } /*********************************************************************** @@ -2811,6 +2763,44 @@ return SOCKET_ERROR; } +/********************************************************************** + * WSAGetOverlappedResult (WS2_32.40) + */ +BOOL WINAPI WSAGetOverlappedResult ( SOCKET s, LPWSAOVERLAPPED lpOverlapped, + LPDWORD lpcbTransfer, BOOL fWait, + LPDWORD lpdwFlags ) +{ + DWORD r; + + TRACE ( "socket %d ovl %p trans %p, wait %d flags %p\n", + s, lpOverlapped, lpcbTransfer, fWait, lpdwFlags ); + + if ( !(lpOverlapped && lpOverlapped->hEvent) ) + { + ERR ( "Invalid pointer\n" ); + WSASetLastError (WSA_INVALID_PARAMETER); + return FALSE; + } + + do { + TRACE("waiting on %p\n",lpOverlapped); + r = WaitForSingleObjectEx (lpOverlapped->hEvent, fWait ? INFINITE : 0, TRUE); + TRACE("wait on %p returned %ld\n",lpOverlapped,r); + } while (r == STATUS_USER_APC); + + if ( lpcbTransfer ) + *lpcbTransfer = lpOverlapped->InternalHigh; + + if ( lpdwFlags ) + *lpdwFlags = lpOverlapped->Offset; /* see ws2_async_call_completion */ + + if (lpOverlapped->Internal == STATUS_PENDING ) + WSASetLastError ( WSA_IO_INCOMPLETE ); + + return (r == WAIT_OBJECT_0); +} + + /*********************************************************************** * WINSOCK_DoAsyncSelect */ @@ -3481,34 +3471,267 @@ /*********************************************************************** + * WSARecv (WS2_32.67) + */ +int WINAPI WSARecv (SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, + LPDWORD NumberOfBytesReceived, LPDWORD lpFlags, + LPWSAOVERLAPPED lpOverlapped, + LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) +{ + + return WSARecvFrom (s, lpBuffers, dwBufferCount, NumberOfBytesReceived, lpFlags, + NULL, NULL, lpOverlapped, lpCompletionRoutine); + +} + +/*********************************************************************** + * WS2_recv (INTERNAL) + */ +static int WS2_recv (int fd, struct iovec* iov, int count, + struct WS_sockaddr *lpFrom, LPINT lpFromlen, LPDWORD lpFlags) +{ + /* Uses recvmsg() in order to provide scatter-gather I/O */ + struct msghdr hdr; + int n; + TRACE ( "fd %d, iovec %p, count %d addr %p, len %p, flags %lx\n", + fd, iov, count, lpFrom, lpFromlen, *lpFlags); + + hdr.msg_name = NULL; + + if ( lpFrom ) + { +#if DEBUG_SOCKADDR + dump_sockaddr (lpFrom); +#endif + + hdr.msg_namelen = *lpFromlen; + hdr.msg_name = ws_sockaddr_alloc (lpFrom, lpFromlen, &hdr.msg_namelen); + if ( !hdr.msg_name ) + { + WSASetLastError ( WSAENOBUFS ); + n = -1; + goto out; + } + } + else + hdr.msg_namelen = 0; + + hdr.msg_iov = iov; + hdr.msg_iovlen = count; + hdr.msg_control = NULL; + hdr.msg_controllen = 0; + hdr.msg_flags = 0; + + if ( (n = recvmsg (fd, &hdr, *lpFlags)) == -1 ) + goto out; + + if ( lpFrom && + ws_sockaddr_u2ws ( hdr.msg_name, hdr.msg_namelen, + lpFrom, lpFromlen ) != 0 ) + { + /* The from buffer was too small, but we read the data + * anyway. Is that really bad? + */ + WSASetLastError ( WSAEFAULT ); + WARN ( "Address buffer too small\n" ); + } + +out: + TRACE ( "recvmsg returned %d\n", n ); + + ws_sockaddr_free ( hdr.msg_name, lpFrom ); + return n; +} + + +/*********************************************************************** + * WS2_async_recv (INTERNAL) + */ +static void WS2_async_recv (async_private *as) +{ + ws2_async* wsa = (ws2_async*) as; + int result, err; + + TRACE ( "async %p\n", wsa ); + + result = WS2_recv ( wsa->async.fd, wsa->iovec, wsa->n_iovecs, + wsa->addr, wsa->addrlen, &wsa->flags ); + + if (result >= 0) + { + wsa->overlapped->Internal = STATUS_SUCCESS; + wsa->overlapped->InternalHigh = result; + TRACE ( "received %d bytes\n", result ); + return; + } + + err = errno; + if ( err == EAGAIN || err == EINTR ) + { + wsa->overlapped->Internal = STATUS_PENDING; + TRACE ( "still pending\n" ); + } + else + { + wsa->overlapped->Internal = STATUS_UNSUCCESSFUL; + TRACE ( "Error: %d\n", errno ); + } +} + +/*********************************************************************** * WSARecvFrom (WS2_32.69) */ INT WINAPI WSARecvFrom( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, - LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, struct WS_sockaddr *lpFrom, - LPINT lpFromlen, LPWSAOVERLAPPED lpOverlapped, + LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, + struct WS_sockaddr *lpFrom, LPINT lpFromlen, + LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) { - DWORD dwCount; - INT rc; + struct iovec* iovec; + int fd, i, length, err = WSAENOTSOCK; + enum fd_type type; + DWORD flags; + ws2_async *wsa; + + fd = _get_sock_fd_type (s, &type, &flags); + + TRACE("socket %04x, wsabuf %p, nbufs %ld, flags %ld, from %p, " + "fromlen %ld, ovl %p, func %p, fd %d, type %d, flags %ld\n", + s, lpBuffers, dwBufferCount, *lpFlags, lpFrom, + (lpFromlen ? *lpFromlen : -1L), + lpOverlapped, lpCompletionRoutine, + fd, (int) type, flags); - FIXME( "(%i,%p,%lu,%p,%p,%p,%p,%p,%p: stub\n", - s, lpBuffers, dwBufferCount, lpNumberOfBytesRecvd, lpFlags, - lpFrom, lpFromlen, lpOverlapped, lpCompletionRoutine ); + if (fd == -1) + { + err = WSAENOTSOCK; + goto error; + } - for( dwCount = 0, rc = 0; dwCount < dwBufferCount; dwCount++ ) - { + iovec = HeapAlloc (GetProcessHeap(), 0, + dwBufferCount * sizeof (struct iovec) ); + if ( !iovec ) + { + err = WSAENOBUFS; + goto err_close; + } - if( ( rc = WS_recvfrom(s, lpBuffers[ dwCount ].buf, (INT)lpBuffers[ dwCount ].len, - (INT)*lpFlags, lpFrom, lpFromlen ) ) != 0 ) + for (i = 0; i < dwBufferCount; i++) { - break; + iovec[i].iov_base = lpBuffers[i].buf; + iovec[i].iov_len = lpBuffers[i].len; } - } + if ( (lpOverlapped || lpCompletionRoutine) && flags & FD_FLAG_OVERLAPPED ) + { + /* Asynchronous recv */ - return rc; -} + wsa = HeapAlloc ( GetProcessHeap(), 0, sizeof (ws2_async) ); + if ( !wsa ) + { + err = WSAENOBUFS; + goto err_free; + } + + wsa->async.ops = &ws2_async_ops; + wsa->async.handle = (HANDLE) s; + wsa->async.fd = fd; + wsa->async.type = ASYNC_TYPE_READ; + wsa->async.func = WS2_async_recv; + wsa->user_overlapped = lpOverlapped; + if ( lpOverlapped ) + wsa->overlapped = lpOverlapped; + else + { + wsa->overlapped = HeapAlloc ( GetProcessHeap(), 0, + sizeof (WSAOVERLAPPED) ); + if ( !wsa->overlapped ) + { + err = WSAENOBUFS; + goto err_free_as; + } + } + wsa->completion_func = ( lpCompletionRoutine ? + lpCompletionRoutine : ws2_default_completion ); + wsa->iovec = iovec; + wsa->n_iovecs = dwBufferCount; + wsa->addr = lpFrom; + wsa->addrlen = lpFromlen; + wsa->flags = *lpFlags; + + wsa->overlapped->Internal = STATUS_USER_APC; + wsa->overlapped->InternalHigh = 0; + TRACE ( "async %p, overlapped: %p, user overlapped: %p, completion: %p\n", + wsa, wsa->overlapped, wsa->user_overlapped, wsa->completion_func ); + + if ( !register_async ( &wsa->async ) ) + { + err = wsaErrno (); + goto err_free_ov; + } + + /* Check for immediate completion + (only possible if lpOverlapped is non-NULL) */ + if ( !lpOverlapped ) + { + WSASetLastError ( WSA_IO_PENDING ); + return SOCKET_ERROR; + } + else if ( WSAGetOverlappedResult ( (HANDLE) s, lpOverlapped, + lpNumberOfBytesRecvd, FALSE, lpFlags) ) + { + return 0; + } + else if ( WSAGetLastError () == WSA_IO_INCOMPLETE ) + { + WSASetLastError ( WSA_IO_PENDING ); + return SOCKET_ERROR; + } + else + goto err_free_ov; + } + + /* Synchronous recv */ + + if (_is_blocking(s)) + { + /* block here */ + /* FIXME: OOB and exceptfds? */ + do_block(fd, 1); + } + + length = WS2_recv ( fd, iovec, dwBufferCount, lpFrom, lpFromlen, lpFlags ); + if ( length == -1 ) + { + err = wsaErrno(); + goto err_free; + } + + TRACE(" -> %i bytes\n", length); + + *lpNumberOfBytesRecvd = length; + + WS_FREE (iovec); + close(fd); + _enable_event(s, FD_READ, 0, 0); + + return 0; + +err_free_ov: + if ( !wsa->user_overlapped ) + HeapFree ( GetProcessHeap(), 0, wsa->overlapped ); +err_free_as: + HeapFree ( GetProcessHeap(), 0, wsa ); +err_free: + WS_FREE (iovec); +err_close: + close (fd); +error: + WARN(" -> ERROR %d\n", err); + SetLastError ( err ); + return SOCKET_ERROR; +} /*********************************************************************** * WSCInstallProvider (WS2_32.88) diff -ruX diffignore CVS/wine/dlls/winsock/ws2_32.spec MW/wine/dlls/winsock/ws2_32.spec --- CVS/wine/dlls/winsock/ws2_32.spec Tue Jan 15 20:17:38 2002 +++ MW/wine/dlls/winsock/ws2_32.spec Wed Jan 16 18:13:36 2002 @@ -52,7 +52,7 @@ 37 stub WSAEnumProtocolsA 38 stub WSAEnumProtocolsW 39 stdcall WSAEventSelect(long long long) WSAEventSelect -40 stub WSAGetOverlappedResult +40 stdcall WSAGetOverlappedResult(long ptr ptr long ptr) WSAGetOverlappedResult 41 stub WSAGetQOSByName 42 stub WSAGetServiceClassInfoA 43 stub WSAGetServiceClassInfoW @@ -79,7 +79,7 @@ 64 stub WSANtohl 65 stub WSANtohs 66 stub WSAProviderConfigChange -67 stub WSARecv +67 stdcall WSARecv(long ptr long ptr ptr ptr ptr) WSARecv 68 stub WSARecvDisconnect 69 stdcall WSARecvFrom(long ptr long ptr ptr ptr ptr ptr ptr ) WSARecvFrom 70 stub WSARemoveServiceClass diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Wed Jan 16 18:14:09 2002 +++ MW/wine/files/file.c Wed Jan 16 17:34:34 2002 @@ -224,7 +224,7 @@ * Retrieve the Unix handle corresponding to a file handle. * Returns -1 on failure. */ -static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum fd_type *type, DWORD *flags ) +int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum fd_type *type, DWORD *flags ) { int ret, fd = -1; diff -ruX diffignore CVS/wine/include/file.h MW/wine/include/file.h --- CVS/wine/include/file.h Wed Jan 16 18:14:04 2002 +++ MW/wine/include/file.h Wed Jan 16 18:15:12 2002 @@ -12,6 +12,9 @@ #include "winbase.h" #include "wine/windef16.h" /* HFILE16 */ +/* FIXME: including server/protocol.h here leads to a handle_t type conflict elsewhere */ +enum fd_type; /* declared in server_protocol.h */ + #define MAX_PATHNAME_LEN 1024 /* Definition of a full DOS file name */ @@ -97,6 +100,7 @@ extern int FILE_strncasecmp( const char *str1, const char *str2, int len ); extern void FILE_SetDosError(void); extern HANDLE FILE_DupUnixHandle( int fd, DWORD access, BOOL inherit ); +extern int FILE_GetUnixHandleType ( HANDLE handle, DWORD access, enum fd_type *type, DWORD *flags ); extern int FILE_GetUnixHandle( HANDLE handle, DWORD access ); extern BOOL FILE_Stat( LPCSTR unixName, BY_HANDLE_FILE_INFORMATION *info ); extern HFILE16 FILE_Dup2( HFILE16 hFile1, HFILE16 hFile2 );

2 1

Re: SHGetSpecialFolderLocation function
by juergen.schmied＠debitel.net Jan. 17, 2002

Jan. 17, 2002

> What I've found though with the SHGetSpecialFolderLocation, is that it seems > to me that it is designed to allow the caller to pick an arbitrary value for > the CSIDL, and that this will cause windows to create a new CSIDL. As the > function's implementation currently stands, it has a hard-coded table of > possible CSIDLs, and rejects calls with unknown CSIDLs. This is right. There is a list with valid CSIDL's. These CSIDL's are mapped to a unique value name in the registry. These functions are supposed to fail when called with a CSIDL which is not predefined. (Whats not saying wine knows all CSIDL's). > Has anyone else looked at this function, and does anyone have any comments or > suggestions on ways to address this? I'm thinking that these values probably > need to go into the registry, or something, rather than being stored in the > code... There is only a need to store the values in the registry when the path is different from the default value. If the there are no registry entrys in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\Shell Folders HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\User Shell Folders HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVer sion\Explorer\Sh ell Folders HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVer sion\Explorer\Us er Shell Folders the the default values are used. (Was in w95, nt4 like this. Don't know it its true for w2k since apparently most values are set at installation time and there are more values used than before.) Last but the not least: the current implementation was designed to work without much preset values in the registry to simplify the installation. The implementation should be cleaned up starting with ShGetFolderLocation since this is the common base of SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocationand SHGetSpecialFolderPath and you should have a fallback to deal with a empty registry. (I'm not up to date with the wine installation procedure but the installer would have to put many keys in the registry for a good shell32 konfiguration.) Juergen --- juergen.schmied(a)debitel.net

1 0

Re: [PATCH] Overlapped recv(), WSARecv()
by lawson_whitney＠juno.com Jan. 16, 2002

Jan. 16, 2002

> > This patch needs testing yet - I am sending it for people to > review and point out errors right from the start. > > Currently I only verified that it compiles. > > ChangeLog: > implement overlapped recv(), much like overlapped IO in > files/file.c. > make WS2_32 WSARecvFrom() the "working" function, > all others are wrappers only. > implement WSAGetOverlappedResult(). > > NOTE: My patches submitted yesterday and today (16/01) to wine-patches > are necessary for this one to work. CVS base version is 2002-01-15. > > Martin > > -- Just to add insult to injury, this letter is by juno version 4 using winsocks, this patch and the 3 others mentioned above. Had to use patch -l again. It doesn't constitute a test for asynchronous winsocks, but at least the patches don't break my mail apps. Maybe. Lawson

1 1

RE: What are you really aiming to do with winetest?
by Patrik Stridvall Jan. 16, 2002

Jan. 16, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps you remember me wanting to extend the .spec files > > with information whether a ptr/str was [in], [out], [in/out] > > > > In Perl all string, like in C, are read/write, so I think > > we can live without it. > > > > But return type would be nice to have in the .spec files. > > We discussed this before; I agree it would be nice to have a lot more > information like in/out, return values, more detailed types, etc. But > I don't think the spec file is the right place for that. I'd like the > spec to remain simple (and in fact to even be simplified) and to > contain only the minimal info needed to generate a correct dll. Yes, I remember. I just pointed out the possibillity, in case you had changed your mind. > All > the rest that's used for debug/testing should be moved somewhere else, > preferably directly into the code. So what you basicly want is something like: my %return_type_exceptions; $return_type_exceptions{"foo"} = { Bar => "str", Baz => "ptr" }; $return_type_exceptions{"bar"} = { Foo => "str" }; A file in this format could quite easily be generated by an appropriate script as well.

2 1

RE: What are you really aiming to do with winetest?
by Patrik Stridvall Jan. 16, 2002

Jan. 16, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > It would be nice if you commented on what you > > think about my spec2pm script for automatically > > generating Perl modules for calling the Windows API. > > Sure; I was looking into integrating it, but found some problems. > I agree generating modules automatically is a good idea; the main > problem right now is that we cannot get the return type of the > functions, and this breaks functions returning a string. Yes, that is true. But it was better than nothing. Many (most?) functions, like strcpy, returns a pointer returns a pointer to one of the arguments anyway so there is little need to actually access it in the test. But of course it should be solved. I see two way of solving this. 1. Extend the spec files to include this information. 2. Have an exception table like the one in make_symbols Fortunately winetest uses Perl, not Python. If we did we would have an additional problem, namely that strings in Python are read-only and passing it as an [out] or [in/out] string would break Python semantics. Perhaps you remember me wanting to extend the .spec files with information whether a ptr/str was [in], [out], [in/out] In Perl all string, like in C, are read/write, so I think we can live without it. But return type would be nice to have in the .spec files. I think I can quite easily can adapt winapi_fixup to do this automatically for all spec files if you wish. You have to decide on the syntax though. > > Also, I'm not sure that you are trying to do: > > The files generated by make_symbols are quite useless, > > they just contain a lot of LOCAL variables. > > They seem to work just fine for me, but I'm no Perl expert, so if you > think your approach is better I'll do it that way. Hmm. I guess that is because you usually write Perl application without "use strict". IIRC variables defaults to global without it and to _local_ with it. In any case, my test with "use strict" didn't work. Anyway, my way is the offical way that is recommended in the Perl documentation and work both with and without "use strict". As a special bonus you can now do things like: use winerror qw(ERROR_CALL_NOT_IMPLEMENTED); without having to, like C, include everything.

2 1

Re: C testing framewok. Updated. SystemParametersInfo unit test.
by Andriy Palamarchuk Jan. 16, 2002

Jan. 16, 2002

Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > >>Can you suggest how to implement these switches - as >>command-line arguments or environment variables? >> > > Environment variables are better. I did that already in the perl > framework, look at the runtest script for the variables I'm using. You > probably want to do things the same way so that it's easier to mix > Perl and C tests. Looked at the runtest script. Defined processing of environment variables WINETEST_DEBUG and WINETEST_DIE_ON_FAILURE. As we discussed before we can define platform at runtime, so do we really need the WINETEST_PLATFORM switch? This is one more thing to break. Somebody will eventually mess with the switch when they run the test application manually. Automatic platform definition is pretty reliable. Attached new version of the library. > I don't have a die on failure flag though, but I > don't think this is really necessary. It is not really necessary, only nice thing to have :-) I was thinking about situations when we need to run big batch of tests on unfamiliar platform - e.g. on untested version of Windows or move tests between Win32 implementation. In these situations we are interested to see all possible failures to see amount of work needed to fix them. On other hand we'd like to see only 1 failure on testing regressions. I'm going to leave the option for now. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 3

The 4th Coming : Mmsystem Question
by Sylvain Petreolle Jan. 16, 2002

Jan. 16, 2002

Hi, Using The 4th Coming game (directx game), wine crashes (no debugger is launched) after displaying following some error messages : (game is at http://t4cweb.aliens.com/download/T4csetup.exe) you can use the following game account : T4CWineUser pass: test4U err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=044f err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=043f err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=008f err:mmsys:MULTIMEDIA_GetIData IData not found for pid=0806b920. Suicide !!! (displayed 4 times) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

1 0

Re: async immediate completion - now tested
by l_whitney＠juno.com Jan. 16, 2002

Jan. 16, 2002

On Tue, Jan 15, 2002 at 08:06:22PM +0100, Martin Wilck wrote: > > PATCH: async-immediate.diff > > This patch uses a more elegant and (IMO) more wine-ish method to check for > possible immediate completion of asynchronous IO requests in ReadFile() and > WriteFile(). > If you get this, async-struct and async-immediate don't harm the 16 bit app. Just making sure I tested exactly what is being proposed. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

2 1

Re: Listview Unicodification (take 3) (fwd)
by Gerard Patel Jan. 16, 2002

Jan. 16, 2002

At 01:58 PM 1/15/02 -0500, you wrote: >[once again, I attached the patch by mistake, and the mail did not go >through...oh well, that happens if you don't sleep at night:) ] I think that by zipping the patch it should be below 64K and be fine. >Here is the latest version of the Unicode ListView control: >http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff Better - all columns have something now - but only the first character. This fixes it : @@ -5075,7 +5076,14 @@ else if (lpLVItem->mask & LVIF_TEXT) { if (internal) lpLVItem->pszText = *ppszText; - else textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW); + else + { + if (isW) + textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW); + else + WideCharToMultiByte(CP_ACP,0,*ppszText,-1,lpLVItem->pszText, + lpLVItem->cchTextMax,NULL,NULL); + } } if (lpLVItem->iSubItem == 0) I'll let you turn into something correct since it's now more than 2 in the morning and I need some sleep even if you don't. Gerard

2 1

Listview Unicodification (take 4)
by Dimitrie O. Paun Jan. 16, 2002

Jan. 16, 2002

OK guys, This one fixes the bug found by Gerard (thanks a lot -- very good spotting). You can find the patch here: http://www.cs.toronto.edu/~dimi/listview-unicode-4.diff This one can go to Alexandre, as far as I'm concerned. So if you still see big problems, please let me know. -- Dimi.

1 0

Re: WSAAccept
by Martin Wilck Jan. 16, 2002

Jan. 16, 2002

Hi Daniel, I have some concerns wrt your WSAAccept implementation you sent to wine-patches on Sunday. I have thought a bit about this function (did you notice my preliminary implementation on Nov. 7 (subject "[EXPERIMENTAL PATCH]: Winsock2" ?). The problem I see is related to the treatment of the peer when the user-supplied condition function returns CF_REJECT or CF_DEFER. Your implementation calls WS_Accept _before_ calling the condition function. That is, the peer will think its connection request was accepted, and possibly start to send or poll for data. Then if the Condition function returns CF_REJECT, the connection is closed. Even worse, for CF_DEFER, the peer receives nothing, the new socket cs returned by WS_Accept remains open but is forgotten after WSAAccept() returns (correct me if I'm wrong). So the peer will think it's connected, but no future WSAAccept or WS_Accept call will ever return a socket connected to it, and it'll be sending data into the void. I think you must at least closesocket(cs) for CS_DEFER as well to avoid this situation. Alternatively (that's the way I did it) the new socket can be stored in the wineserver to be returned by future WSAAccept calls. The Winsock2 specs say that "[WSAAccept] extracts the first connection on the queue of pending connections" (after a CF_DEFER, that should be the previously deferred connection, until it's either accepted or rejected). Moreover, it says that "[In the CF_DEFER case] no action about this connection request should be taken by the service provider". Taken seriously, this means that it's wrong to call accept() on this request before a positive decision was made by the Condition function. Summarizing, the peer should see: CF_ACCEPT: his request is accepted (this case is OK). CF_REJECT: his request is rejected (not ok, he receives an accept followed by a close). CF_DEFER: nothing (not OK, he receives an accept followed by ???) I have no idea how this affects behaviour of "real" applications. The essential problem is that there is no way (well, I have found none) to obtain the peer's socket address on Linux without accept()ing first. I guess that is what made you call accept() before the condition routine. Perhaps someone can come up with a method to read the socket address of a waiting connection request before it's accepted, but my guess is this won't work without a kernel hack. At the very least, though, I consider it necessary to include a FIXME that tells users that this function may behave different from what the specs say. Please don't get me wrong, it's great to see other people work on Winsock, and your code is clean. I just thought I need to express these concerns. Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 3

Filesystem Regression Test, was: Re: RESEND: Fix return value ...
by Uwe Bonnes Jan. 16, 2002

Jan. 16, 2002

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> Hello. Please use this patch instead of the previous one. I'll Dmitry> try to find some time and figure out how to write regression Dmitry> test for this functions. Please let us know if you find some sensible way to test filesystem functions. What I do now is - export some filesystem tree with SMB(NCP) - import it in Vmware with some drive letter - use the same drive letter in the wine-config for the same filesystem tree I don't think this solution is very sensible for a more generalized test... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 7

Using Python with Wine
by Gerard Patel Jan. 16, 2002

Jan. 16, 2002

I have finally succeeded in using Python to make test applications. I find the idea pretty interesting to build quick-and-dirty applications to test a specific api. Here is how it can be done. Get from www.python.org : Python 2.1.1 for windows http://www.python.org/ftp/python/2.1.1/ Get from ftp://ftp.nightmare.com/pub/python/python-ext/ npstruct-2001-05-20.zip calldll-2001-05-20.zip dynwin-2001-05-20.zip Install python under Wine : ./wine -managed <path to python installer>Python-2.1.1.exe unzip the 3 additional packages under the Python directory (c:\program files\python21) add these 3 directories to the Python path. The easier way is to create a dir.pth file in the main Python directory containing : c:\\Program Files\\Python21\\calldll c:\\Program Files\\Python21\\npstruct c:\\Program Files\\Python21\\dynwin add the path to the main python directory to the Wine path. launch python (the command line version, I did not try the gui version) : wine python Here are some commands I tried (I edited out most of the Wine Fixme and Err, and removed prompts) : import windll (.... 1. Basic example) user32=windll.module("user32") cstr=windll.cstring MessageBox=user32.MessageBox MessageBox(0,cstr('test'),cstr('example'),0) 1 (1 is the value returned by MessageBox - success) (.... 2. more involved example, using buffers) winmm=windll.module('winmm') winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) 279 (error 279) buf=windll.membuf(256) winmm.mciGetErrorString(279,buf,255) 1 import calldll print calldll.read_string(buf) Cannot use 'all' as the device name with the specified command. (I fix line 516 of mci.c to return a correct error message and compile Wine, try again) i = winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) fixme:mci:MCI_LoadMciDriver Couldn't load driver for type WAVEAUDIO. If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini print i 306 (I had indeed commented out the waveaudio entry in my system.ini -> fix user error and try again) winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) 0 (well, the mci call returns 0 - success - the sound is not played completely - but that's another story :-//) (.... 3. complete example of testing a gui function : TextOut) import windll cstr = windll.cstring gdi32 = windll.module ('gdi32') import wingdi import windc import winwin class test(winwin.python_window): style = winwin.WS_OVERLAPPEDWINDOW def WM_DESTROY (self, wparam, lparam): winwin.user32.PostQuitMessage (0) def WM_PAINT (self, wparam, lparam): dc = self.begin_paint() gdi32.TextOut(dc.handle,50,50,cstr("text output"),11) self.end_paint() if __name__ == '__main__': import msgloop w = test("test 1").create() w.show_window() msgloop.go() (in this example most of the code use calls to higher level functions hiding somewhat the Win32 Api, except the api call, that uses the 'handle' member of the dc object to access the Win32 object) There is a Python error message when the gui app terminates, however this is a problem with the python system (it shows the same under WinNT, for example) Note : don't begin command by spaces - Python interpreter don't like it. Also, Python don't care for case but Wine does, so writing 'mcisendstring' will fail, for example.

1 0

fixme:richedit:RICHED32_WindowProc Unknown message 129
by lawson_whitney＠juno.com Jan. 15, 2002

Jan. 15, 2002

Good day! Thanks, Daniel Walker, for your work on riched32. I don't know what or why is richedit and I'm kind of GUI-challenged, or I'd have a go at implementing these myself, but I have an app that uses it, so if traces would help, just say which traces and if you want them for builtin or native riched32. The app fails with a bogus message box: "Insufficient memory or disk space" after these three fixme's with the builtin, so those traces should be pretty short, but maybe it would also be useful to try to use spy on the native riched32. If spying on msvcrt, mfc42, and/or the app's own dll's is likely to make noise, I can filter it out, but at this point I don't know. fixme:richedit:RICHED32_WindowProc Unknown message 129 fixme:richedit:RICHED32_WindowProc Unknown message 528 fixme:richedit:RICHED32_WindowProc Unknown message 130 Regards, Lawson

3 4

C testing framewok. Updated. SystemParametersInfo unit test.
by Andriy Palamarchuk Jan. 15, 2002

Jan. 15, 2002

Attached are new version of the C testing framework. Changed SystemParametersInfo unit test to use this framework. Alexandre, I need to use a couple switches for the test application: - output verbosity level - die on failure indicator Can you suggest how to implement these switches - as command-line arguments or environment variables? Using environment variables is easier for me - I don't need to do parsing of 2 types of command line (main and WinMain formats), no need to force test developers to use function like start_test( args ) in the beginning of their tests. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 1

Re: What are you really aiming to do with winetest?
by Alexandre Julliard Jan. 15, 2002

Jan. 15, 2002

Patrik Stridvall <ps(a)leissner.se> writes: > It would be nice if you commented on what you > think about my spec2pm script for automatically > generating Perl modules for calling the Windows API. Sure; I was looking into integrating it, but found some problems. I agree generating modules automatically is a good idea; the main problem right now is that we cannot get the return type of the functions, and this breaks functions returning a string. > Also, I'm not sure that you are trying to do: > The files generated by make_symbols are quite useless, > they just contain a lot of LOCAL variables. They seem to work just fine for me, but I'm no Perl expert, so if you think your approach is better I'll do it that way. -- Alexandre Julliard julliard(a)winehq.com

1 0

Sponsoring by IBM, lets get it done
by Roland Jan. 15, 2002

Jan. 15, 2002

Hello, to put an end to this discussion, I will start trying to contact people at IBM for sponsoring, unless someone more qualified wants to do it. Anyone? Ok, so where do I start, can someone give me an email adress? I also wanted to know some technical terms: 1. How do you call the person who is TECHNICALLY responsible for a project, in this case, for the Linux stuff at IBM? 2. How do you call the person who is FINANCIALLY responsible for a project, in this case, for the Linux stuff at IBM? If someone can provide the answer to 1 and 2, it would help, the email adress I will figure out myself...if no one can provide one... Thanks...Roland

1 0

Listview Unicodification (take 3) (fwd)
by Dimitrie O. Paun Jan. 15, 2002

Jan. 15, 2002

[once again, I attached the patch by mistake, and the mail did not go through...oh well, that happens if you don't sleep at night:) ] Hi folks, Here is the latest version of the Unicode ListView control: http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff It fixes a silly (e.g. brown paper bag type of bug, really) pointed to me by Gerard (thanks!). It does fix a problem with the subitem handling (before, the subitems were simply ignored). Tested with the Common Control Spy Sample thingy from MS. I still could not get Gerard's examples going, and it seems I really need to test with those... If things look OK, I will forward it to Alexandre soon. -- Dimi.

1 0