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

Re: What are you really aiming to do with winetest?

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > 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" > }; > Yes, that would work fine for now. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2002

RE: What are you really aiming to do with winetest?

by Patrik Stridvall

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

Jan. 16, 2002

Re: What are you really aiming to do with winetest?

by Alexandre Julliard

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. All the rest that's used for debug/testing should be moved somewhere else, preferably directly into the code. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2002

Re: struct async-private - now tested and cleaned up

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > It is a polished resubmit of my former posting, without the GetOverlappedResult() stuff > which will follow in a separate patch. It is against clean CVS 2002-01-15. > > I would be really grateful if this patch was applied, because it is a prerequisite for me to > get going with Winsock2 overlapped IO. The comm.c part doesn't apply, are you sure this is against a clean CVS? You should probably consider using cvs diff, it helps making sure you do the diff against the right file. Also note that because of dll separation you cannot use functions like register_async() from winsock. If absolutely necessary they could be exported, but I think it would be much better to use straight server calls (and in theory these functions shouldn't be used from comm.c either). -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > More reliable than environment variable anyway. > Nothing prevents someone from forgetting to set > correct value to the environment variable before > running test application :-) This will be taken care of by the test environment. You don't need to set the variable when running make test, but you have the possibility to set it if you want to override the default for whatever reason. I don't see why we should impose a less flexible solution that won't be more robust anyway. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > 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. > > Well, that's the point, so that you can change the > platform to see > what happens. I needed that to test my todo > implementation without > having to reboot under Windows. Do you mean testing of TODO functionality for Perl winetest framework or running tests, marked as TODO? 1 - sure, you can test this with environment variable, but I'd expect this variable to be used for debugging only. I wonder why you are against using automatic recognition in production tests. 2 - TODO tests are executed in the same way as usual tests, only their results are reported differently > > Automatic platform definition is pretty reliable. > > I don't think checking for a Wine registry key is > reliable at > all. Nothing prevents someone from having this key > under Windows. More reliable than environment variable anyway. Nothing prevents someone from forgetting to set correct value to the environment variable before running test application :-) In either case the person will learn his mistake very quickly, after all those WINE_TODOs will blow up in his fase. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 16, 2002

Re: License problem with files in dlls/icmp/

by Alexandre Julliard

Ilja Kamps <ikarus(a)ikarus.ath.cx> writes: > It appaers that files under dlls/icmp/ are licensed under the BSD license and not > the X11 license, this might be a problem as wine does not honor the advertisment > part and also it makes wine GPL incompaitible, I would consider this a serious > problem. Either we honor the advertisment part and note that wine is not directly > GPL compaitible (GPL doesn't allow such texts) or we reimplement that dll. UC Berkeley has announced some time ago that the advertising clause on their code can be considered null and void and removed, so that's not really a problem. We could probably remove the clause to make it clear. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > 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. Well, that's the point, so that you can change the platform to see what happens. I needed that to test my todo implementation without having to reboot under Windows. > Automatic platform definition is pretty reliable. I don't think checking for a Wine registry key is reliable at all. Nothing prevents someone from having this key under Windows. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2002

[PATCH] Overlapped recv(), WSARecv()

by Martin Wilck

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

Jan. 16, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Andriy Palamarchuk

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > > > 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. I mean real Windows 95. Tests should be compiled and run on all the Windows platforms to insure their correctness. Is there a way to check whether given version of Win32 supports UNICODE? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 16, 2002

The 4th Coming : Mmsystem Question

by Sylvain Petreolle

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

Jan. 16, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Dmitry Timoshkov

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

Jan. 16, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

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/

Jan. 16, 2002

RE: What are you really aiming to do with winetest?

by Patrik Stridvall

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

Jan. 16, 2002

Re: async immediate completion - now tested

by Martin Wilck

On Tue, 15 Jan 2002 l_whitney(a)juno.com wrote: > 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. It is exactly the same, except for the additional traces that I left out, and of course the changes in CVS between 2002-01-08 and 2002-01-15. Martin

Jan. 16, 2002

Re: Listview Unicodification (take 3) (fwd)

by Dimitrie O. Paun

On Tue, 15 Jan 2002, Gerard Patel wrote: > 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. Apparently, the limit is 64K. But there's no much point in gzipping it, such patches are sooo hard to read from the mailer (save attachment, ungzip, etc). I hate them. Much simpler if I dump them on the web site, it's just I did the attachment as an automatism... > >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 : Thanks. That was a tricky one. I think the nicer thing is for the textcpynT function to correctly handle all cases, so I did that in the (take 4) version of the patch. It didn't receive any testing, as I don't have your test case which trigger that condition, so I hope everything is OK now. > 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. Sleep tight, I'm off to bed too! -- Dimi.

Jan. 16, 2002

Listview Unicodification (take 4)

by Dimitrie O. Paun

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.

Jan. 16, 2002

Re: WSAAccept

by Daniel Walker

Martin Wilck wrote: > > Dear Daniel, > > I seem to have problems sending mail directly to your address ... You have a "g" on the end instead of a "k" . diwalker(a)earthlink.net (not earthling) . > > No problem .. Although, Something is better than nothing .. I have an > > application that uses this function, and I wanted that application to > > work .. Even though my implementation is not complete, since it's now in > > the main wine source it can mature .. By withholding your implementation > > your not doing anyone any favors .. > > Yeah, that was my very first wine patch ever, and I didn't understand the > rules of wine-devel & wine-patches by that time. Afterwards I forgot about > it, concentrating on overlapped IO, and was reminded of it by your patch. I hope you submit it .. I think it was more than just WSAAccept() .. > It is good to see that we seem to be in basic agreement, though. > After all, it will probably happen very rarely that an app rejects > or even defers clients. I would guess that rejection might be common, but I can't see many apps taking advantage of defer .. > Btw: will you be working on more Winsock stuff in the near future? > If yes, I guess we should try to coordinate our efforts somehow. I don't have anything planned, right now .. Daniel Walker

Jan. 16, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > Dmitry, I changed the your test to use the C testing > framework I posted today. The test is attached. It looks good to me, but we should not forget to test both unicode and ANSI versions of functions. There are two approaches to accomplish this task: 1. Have two separate tests for A and W functions. 2. Have single test without using A or W suffix and choose appropriate test by [not] defining UNICODE before including windows.h. Does anybody have other suggestions or ideas? -- Dmitry.

Jan. 16, 2002

Re: Listview Unicodification (take 3) (fwd)

by Gerard Patel

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

Jan. 16, 2002

License problem with files in dlls/icmp/

by Ilja Kamps

It appaers that files under dlls/icmp/ are licensed under the BSD license and not the X11 license, this might be a problem as wine does not honor the advertisment part and also it makes wine GPL incompaitible, I would consider this a serious problem. Either we honor the advertisment part and note that wine is not directly GPL compaitible (GPL doesn't allow such texts) or we reimplement that dll. I hope I got it right.

Jan. 16, 2002

Using Python with Wine

by Gerard Patel

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.

Jan. 16, 2002

Re: async immediate completion - now tested

by l_whitney＠juno.com

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

Jan. 15, 2002

Re: fixme:richedit:RICHED32_WindowProc Unknown message 129

by lawson_whitney＠juno.com

On Tue, 15 Jan 2002, Francois Gouget wrote: > What happens when snoop hangs? Does the process seem to get into an > infinite loop? No, it just stops. (well, I guess it could be looping in something not being traced, except that the cpu is idle). > I once had a problem with +snoop where it would get into an infinite > loop when the pointer was 0xffffffff (-1). I did not have time to get to > the bottom of this at the time and now I am not sure I can even > reproduce the problem. > > But I did work around the problem by checking for -1 before doing the > string check. See the attached patch. +snoop was looping where I added > the TRACEs. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > The software said it requires Win95 or better, so I installed Linux. > ________________________________________________________________ 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/.

Jan. 15, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Dmitry, I changed the your test to use the C testing > framework I posted today. The test is attached. > > Alexandre, can we start to submit unit tests to CVS? I haven't really finished the stuff I want to do for the C framework, so I won't apply the tests right away; but there shouldn't be major changes, mostly makefiles stuff, so you can submit them now and I'll put them in when I get things working. -- Alexandre Julliard julliard(a)winehq.com

Jan. 15, 2002