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

How many APIs have been implemented yet?

by Roland

Hello, I`m new to this list and I have some questions: 1.How many APIs are there in Windows? I heard something around 12000, is that correct? 2.How many of them have been implemented yet(not necessaryly bug-free)? Finally I want to add something about being able to run M$ software, specifically M$-Office. Many see a problem in there because M$ is likely to complicate things by using obscure APIs and other nasty tricks to make it hard for Office to work under Wine. This way we will be facing an uphill battle all the time. But I think we shouldn't worry too much about it. In fact, I think there are replacements for most M$ software, like Staroffice and the like. The main concern should be the ability to run the huge amounts of 3rd party software. And this will not be a problem, since the producers of this software use the well documented APIs which will always have to be publicly available. Once we run all those apps, more and more users will use Linux. As for the M$ Office, people can start using Staroffice, since it can read M$ Office fileformats... Just my 0.05$ Roland

Jan. 7, 2002

Re: Lindows screenshots

by Bang Jun-Young

On Fri, Jan 04, 2002 at 08:06:11AM -0800, Bill Medland wrote: > I wouldn't hold my breath; why would they contribute the valuable stuff > back? What do you think of people that have contributed their invaluable time/money/energy/passion/etc to Wine for last years? :P Jun-Young -- Bang Jun-Young <junyoung(a)mogua.com>

Jan. 7, 2002

struct async_private needs generalization for Winsock

by Martin Wilck

Hi Mike, all, as I pointed out before, we must change the async_private type such that it accomodates the different needs of normal (e.g. ReadFileEx()) and Winsock (e.g. WSARecv()) async requests. The "generic" functions in scheduler/synchro.c must be able to handle these structures without knowing what type of async_private structure they have been passed. I try to summarize the differences between the two request types here: 1. Winsock async requests have a WSAOVERLAPPED struct rather than OVERLAPPED. Unlike File I/O, the routines complete if any positive number of bytes is read (there's no such thing as BytesToRead). 2. Unlike File I/O, The WSAOVERLAPPED struct is *not* accessed in any way, except for the hEvent field. The other fields do not carry useful information and are, according to the Winsock2 specs, reserved to service providers, i.e. we are not allowed to write to them. 3. Winsock functions take a scatter/gather array of type WSABUF* instead of a single buffer, and a number of WSABUFs instead of the number of bytes to read. 4. The completion routine takes an additional DWORD argument. 5. In the case of WSARecvFrom()/WSASendTo(), the socket address and length parameters passed by the user must be stored and filled in at completion. [These are the differences I've come across so far, there may be more.] I'd therefore recommend the following, similar to the treatment of "struct object" and derived types in the server code: struct async_private; typedef void (*async_handler)(struct async_private *ovp); struct async_private { unsigned int type; /* file/socket, read/write/... */ HANDLE handle; int fd; struct async_private *prev; struct async_private *next; async_handler func; } struct async_fileio { struct async_private async; char *buffer; int count; LPOVERLAPPED lpOverlapped; LPOVERLAPPED_COMPLETION_ROUTINE completion_func; } struct async_winsock { struct async_private async; LPWSABUF wsabuf; int n_wsabufs; LPWSAOVERLAPPED overlapped; LPWSAOVERLAPPED_COMPLETION_ROUTINE completion_func; struct WS_sockaddr* addr; /* User-specified pointers */ int *addrlen; int flags; /* Return values */ int NumberOfBytesRead; int status; /* cannot be stored in overlapped */ } To my knowledge, there are only these two types of Asynchronous requests. Thus, using a "struct async_ops" like "struct object_ops" in the server code would probably be too much; the type field could instead be used for distinction between the two request types and the "generic" code in scheduler/synchro.c could incorporate respective case distinctions. To my experience this runs faster than code with function pointers if we have only two cases. Actually, we might even do without the "async_handler" field and decide which function to call only according to the "type" field, but that's a cosmetic issue. Unless anybody objects, I'll soon submit a patch incorporating this approach. Comments welcome, 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

Jan. 7, 2002

implement Cancelio (updated), WriteFile update, comm16 update

by l_whitney＠juno.com

Good day! If you get this, these three patches fix a regression in 16 bit serial comms as practiced by Juno 1.49 that was intrduced by: Changes by: julliard(a)wine2. 01/12/31 20:11:33 Modified files: files : file.c scheduler : synchro.c Log message: Mike McCormack <mike_mccormack(a)start.com.au>R Set an overlapped's hEvent for ReadFile/WriteFile in an overlapped completion function, not in ReadFileEx or WriteFileEx. Patch: http://cvs.winehq.com/patch.py?id=1009847493736738936509937 So I'm in favor of committing them. Regards, Lawson

Jan. 7, 2002

Patch: 005-recv.diff

by Martin Wilck

#5 in series Patch file: 005-recv.diff Purpose: Move recv() functionality to WS2_32 code Created: 2002-01-07 Applies: CVS 2002-01-07 (with 004-socket.diff applied) This patch moves the recv() functionality to WS2_32 functions that provide a superset of the functionality of their WS counterparts. For the recv() family of functions, WSARecvFrom() becomes the "work horse". All other functions (WSARecv(), recv(), recvfrom()) are only wrappers around WSARecvFrom(). To provide the scatter/gather functionality of WSARecv() / WSARecvFrom(), the (only) unix function called is recvmsg(). This means some overhead for simple recv() calls, but allows for a single general "work" code. dlls/winsock/socket.c: WS_recv(): Is now a wrapper around WSARecv(). WS_recvfrom(): Is now a wrapper around WSARecvFrom(). WSARecv(): Is now a wrapper around WSARecvFrom(). WSARecvFrom(): Holds all "real" recv() functionality (formerly in WS_recv() / WS_recvfrom()). Calls recvmsg() to provide for scatter/gather functionality. dlls/winsock/ws2_32.spec: Add stdcall entry for WSARecv(). Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ru -X diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Mon Jan 7 12:55:24 2002 +++ MW/wine/dlls/winsock/socket.c Mon Jan 7 12:55:37 2002 @@ -1815,34 +1815,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; } /*********************************************************************** @@ -1860,60 +1842,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 - - res=SOCKET_ERROR; - if (fd != -1) - { - struct sockaddr* uaddr; - int uaddrlen; - int length; + DWORD n; + WSABUF wsabuf = { len, buf }; + DWORD dwFlags = flags; - 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; } /*********************************************************************** @@ -3404,34 +3340,132 @@ /*********************************************************************** + * 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); + +} + +/*********************************************************************** * 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, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) + { - DWORD dwCount; - INT rc; + /* Uses recvmsg() in order to provide scatter-gather I/O */ + + struct iovec* iovec; + struct msghdr msghdr; + int fd, i, length, err = WSAENOTSOCK; + + TRACE("socket %04x, wsabuf %p, nbufs %ld, flags %ld, from %p, fromlen %ld, ovl %p, func %p\n", + s, lpBuffers, dwBufferCount, *lpFlags, lpFrom, + (lpFromlen ? *lpFromlen : -1L), + lpOverlapped, lpCompletionRoutine); - FIXME( "(%i,%p,%lu,%p,%p,%p,%p,%p,%p: stub\n", - s, lpBuffers, dwBufferCount, lpNumberOfBytesRecvd, lpFlags, - lpFrom, lpFromlen, lpOverlapped, lpCompletionRoutine ); + fd = _get_sock_fd(s); - for( dwCount = 0, rc = 0; dwCount < dwBufferCount; dwCount++ ) - { + if (fd == -1) + { + err = WSAENOTSOCK; + goto error; + } - if( ( rc = WS_recvfrom(s, lpBuffers[ dwCount ].buf, (INT)lpBuffers[ dwCount ].len, - (INT)*lpFlags, lpFrom, lpFromlen ) ) != 0 ) + /* FIXME: should this be HeapAlloc() or WS_ALLOC ? */ + iovec = WS_ALLOC ( dwBufferCount * sizeof (struct iovec) ); + if ( !iovec ) { - break; + err = WSAENOBUFS; + goto err_close; } - } + for (i = 0; i < dwBufferCount; i++) + { + iovec[i].iov_base = lpBuffers[i].buf; + iovec[i].iov_len = lpBuffers[i].len; + } - return rc; -} + msghdr.msg_name = NULL; + if ( lpFrom ) + { +#if DEBUG_SOCKADDR + dump_sockaddr (lpFrom); +#endif + + msghdr.msg_namelen = *lpFromlen; + msghdr.msg_name = ws_sockaddr_alloc (lpFrom, lpFromlen, &msghdr.msg_namelen); + } + else + msghdr.msg_namelen = 0; + + msghdr.msg_iov = iovec; + msghdr.msg_iovlen = dwBufferCount; + msghdr.msg_control = NULL; + msghdr.msg_controllen = 0; + msghdr.msg_flags = 0; + + /* FIXME: Treat overlapped IO here */ + + if (_is_blocking(s)) + { + /* block here */ + /* FIXME: OOB and exceptfds? */ + do_block(fd, 1); + } + + /* FIXME: can we support MSG_PARTIAL ? + How does it relate to recvmsg()'s msg_flags ? */ + + if ((length = recvmsg (fd, &msghdr, *lpFlags)) == -1) + { + err = wsaErrno(); + goto err_free; + } + + TRACE(" -> %i bytes\n", length); + + if ( lpFrom && ws_sockaddr_u2ws (msghdr.msg_name, msghdr.msg_namelen, lpFrom, lpFromlen) != 0 ) + { + /* The from buffer was too small, but we read the data + * anyway. Is that really bad? + */ + SetLastError ( WSAEFAULT ); + WARN ( " -> Address buffer too small\n" ); + } + + + *lpNumberOfBytesRecvd = length; + + WS_FREE (iovec); + ws_sockaddr_free ( msghdr.msg_name, lpFrom ); + close(fd); + _enable_event(s, FD_READ, 0, 0); + + return 0; + +err_free: + WS_FREE (iovec); + ws_sockaddr_free ( msghdr.msg_name, lpFrom ); + +err_close: + close (fd); + +error: + WARN(" -> ERROR %d\n", err); + SetLastError ( err ); + return SOCKET_ERROR; +} /*********************************************************************** * WSCInstallProvider (WS2_32.88) diff -ru -X diffignore CVS/wine/dlls/winsock/ws2_32.spec MW/wine/dlls/winsock/ws2_32.spec --- CVS/wine/dlls/winsock/ws2_32.spec Mon Jan 7 12:42:08 2002 +++ MW/wine/dlls/winsock/ws2_32.spec Mon Jan 7 12:55:37 2002 @@ -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

Jan. 7, 2002

Patch: 004-socket.diff

by Martin Wilck

#4 in series (incremental) Patch file: 004-socket.diff Purpose: Move socket() functionality to WS2_32 code Created: 2002-01-07 Applies: CVS 2002-01-07 (with 003-sock_basic.diff applied) This patch moves the functionality of WS_socket() to WSASocketA(). WSASocketA() accounts for WSA_FLAG_OVERLAPPED. dlls/winsock/socket.c: WS_socket(): Is now a wrapper around WSASocketA(). WSA_FLAG_OVERLAPPED is set according to the SO_OPENTYPE value. WSASocketA(): Has the functionality formerly in WS_socket(). Honours WSA_FLAG_OVERLAPPED. Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ru -X diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Mon Jan 7 12:45:56 2002 +++ MW/wine/dlls/winsock/socket.c Mon Jan 7 12:51:27 2002 @@ -2329,81 +2329,14 @@ */ SOCKET WINAPI WS_socket(int af, int type, int protocol) { - SOCKET ret; - TRACE("af=%d type=%d protocol=%d\n", af, type, protocol); - /* check the socket family */ - switch(af) - { -#ifdef HAVE_IPX - case WS_AF_IPX: af = AF_IPX; -#endif - case AF_INET: - case AF_UNSPEC: break; - default: SetLastError(WSAEAFNOSUPPORT); - return INVALID_SOCKET; - } - - /* check the socket type */ - switch(type) - { - case WS_SOCK_STREAM: - type=SOCK_STREAM; - break; - case WS_SOCK_DGRAM: - type=SOCK_DGRAM; - break; - case WS_SOCK_RAW: - type=SOCK_RAW; - break; - default: SetLastError(WSAESOCKTNOSUPPORT); - return INVALID_SOCKET; - } - - /* check the protocol type */ - if ( protocol < 0 ) /* don't support negative values */ - { SetLastError(WSAEPROTONOSUPPORT); return INVALID_SOCKET; } - - if ( af == AF_UNSPEC) /* did they not specify the address family? */ - switch(protocol) - { - case IPPROTO_TCP: - if (type == SOCK_STREAM) { af = AF_INET; break; } - case IPPROTO_UDP: - if (type == SOCK_DGRAM) { af = AF_INET; break; } - default: SetLastError(WSAEPROTOTYPE); return INVALID_SOCKET; - } - - SERVER_START_REQ( create_socket ) - { - req->family = af; - req->type = type; - req->protocol = protocol; - req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; - req->flags = 0U; - req->inherit = TRUE; - set_error( wine_server_call( req ) ); - ret = (SOCKET)reply->handle; - } - SERVER_END_REQ; - if (ret) - { - TRACE("\tcreated %04x\n", ret ); - return ret; - } - - if (GetLastError() == WSAEACCES) /* raw socket denied */ - { - if (type == SOCK_RAW) - MESSAGE("WARNING: Trying to create a socket of type SOCK_RAW, will fail unless running as root\n"); - else - MESSAGE("WS_SOCKET: not enough privileges to create socket, try running as root\n"); - SetLastError(WSAESOCKTNOSUPPORT); - } + /* The Winsock2 specification states that socket() always opens sockets + in overlapped mode. + FIXME: is the SO_OPENTYPE behaviour correct? */ - WARN("\t\tfailed!\n"); - return INVALID_SOCKET; + return WSASocketA ( af, type, protocol, NULL, 0, + (opentype ? 0 : WSA_FLAG_OVERLAPPED) ); } /*********************************************************************** @@ -2974,17 +2907,88 @@ LPWSAPROTOCOL_INFOA lpProtocolInfo, GROUP g, DWORD dwFlags) { + SOCKET ret; + /* FIXME: The "advanced" parameters of WSASocketA (lpProtocolInfo, - g, dwFlags) are ignored. + g, dwFlags except WSA_FLAG_OVERLAPPED) are ignored. */ TRACE("af=%d type=%d protocol=%d protocol_info=%p group=%d flags=0x%lx\n", af, type, protocol, lpProtocolInfo, g, dwFlags ); - return ( WS_socket (af, type, protocol) ); -} + /* check the socket family */ + switch(af) + { +#ifdef HAVE_IPX + case WS_AF_IPX: af = AF_IPX; +#endif + case AF_INET: + case AF_UNSPEC: break; + default: SetLastError(WSAEAFNOSUPPORT); + return INVALID_SOCKET; + } + + /* check the socket type */ + switch(type) + { + case WS_SOCK_STREAM: + type=SOCK_STREAM; + break; + case WS_SOCK_DGRAM: + type=SOCK_DGRAM; + break; + case WS_SOCK_RAW: + type=SOCK_RAW; + break; + default: SetLastError(WSAESOCKTNOSUPPORT); + return INVALID_SOCKET; + } + + /* check the protocol type */ + if ( protocol < 0 ) /* don't support negative values */ + { SetLastError(WSAEPROTONOSUPPORT); return INVALID_SOCKET; } + + if ( af == AF_UNSPEC) /* did they not specify the address family? */ + switch(protocol) + { + case IPPROTO_TCP: + if (type == SOCK_STREAM) { af = AF_INET; break; } + case IPPROTO_UDP: + if (type == SOCK_DGRAM) { af = AF_INET; break; } + default: SetLastError(WSAEPROTOTYPE); return INVALID_SOCKET; + } + + SERVER_START_REQ( create_socket ) + { + req->family = af; + req->type = type; + req->protocol = protocol; + req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; + req->flags = dwFlags; + req->inherit = TRUE; + set_error( wine_server_call( req ) ); + ret = (SOCKET)reply->handle; + } + SERVER_END_REQ; + if (ret) + { + TRACE("\tcreated %04x\n", ret ); + return ret; + } + + if (GetLastError() == WSAEACCES) /* raw socket denied */ + { + if (type == SOCK_RAW) + MESSAGE("WARNING: Trying to create a socket of type SOCK_RAW, will fail unless running as root\n"); + else + MESSAGE("WS_SOCKET: not enough privileges to create socket, try running as root\n"); + SetLastError(WSAESOCKTNOSUPPORT); + } + WARN("\t\tfailed!\n"); + return INVALID_SOCKET; +} /*********************************************************************** * __WSAFDIsSet (WINSOCK.151)

Jan. 7, 2002

Patch: 003-sock_basic.diff

by Martin Wilck

#3 in series (incremental) Patch file: 003-sock_basic.diff Purpose: Basic implementation of socket flags. Created: 2002-01-07 Applies: CVS 2002-01-07 (with 002-fd_type.diff applied) This patch adds socket flags to the server data structure for sockets, and adds means to set these flags when creating sockets. It also provides basic server functionality to allow async I/O on sockets. ** NOTE ON BUILDING: tools/make_requests must be run ** ** after applying this patch ** server/protocol.def: create_socket request: add flags parameter. server/sock.c: struct socket: add flags field. add struct async_queue fields for async IO operations. sock_get_info(): Account for WSA_FLAG_OVERLAPPED. create_socket(): Additional parameter (unsigned int flags) Initialize async queues for overlapped sockets. create_socket_req(): Pass flags parameter to create_socket(). sock_destroy(): Destroy async queues for overlapped sockets. dlls/winsock/socket.c: WS_socket(): Initialize socket flags parameter (currently 0). Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ru -X diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Wed Jan 2 12:50:02 2002 +++ MW/wine/dlls/winsock/socket.c Fri Jan 4 11:13:03 2002 @@ -2381,6 +2381,7 @@ req->type = type; req->protocol = protocol; req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; + req->flags = 0U; req->inherit = TRUE; set_error( wine_server_call( req ) ); ret = (SOCKET)reply->handle; diff -ru -X diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Fri Jan 4 11:07:45 2002 +++ MW/wine/server/file.c Thu Jan 3 15:21:50 2002 @@ -342,7 +342,7 @@ reply->serial = 0; /* FIXME */ } - if (file->flags & FILE_FLAG_OVERLAPPED) + if ( file->flags & FILE_FLAG_OVERLAPPED ) fd_type |= FD_TYPE_FLAG_OVERLAPPED; return fd_type; diff -ru -X diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Fri Jan 4 11:07:45 2002 +++ MW/wine/server/protocol.def Fri Jan 4 10:20:53 2002 @@ -646,6 +646,7 @@ int family; /* family, see socket manpage */ int type; /* type, see socket manpage */ int protocol; /* protocol, see socket manpage */ + unsigned int flags; /* socket flags */ @REPLY handle_t handle; /* handle to the new socket */ @END diff -ru -X diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Fri Jan 4 11:07:45 2002 +++ MW/wine/server/sock.c Fri Jan 4 11:10:45 2002 @@ -36,6 +36,7 @@ #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" /* To avoid conflicts with the Unix socket headers. Plus we only need a few * macros anyway. @@ -50,8 +51,11 @@ unsigned int mask; /* event mask */ unsigned int hmask; /* held (blocked) events */ unsigned int pmask; /* pending events */ + unsigned int flags; /* socket flags */ struct event *event; /* event object */ int errors[FD_MAX_EVENTS]; /* event errors */ + struct async_queue read_q; /* Queue for asynchronous reads */ + struct async_queue write_q; /* Queue for asynchronous writes */ }; static void sock_dump( struct object *obj, int verbose ); @@ -275,6 +279,9 @@ static int sock_get_info( struct object *obj, struct get_file_info_reply *reply ) { + struct sock *sock = (struct sock*) obj; + assert ( obj->ops == &sock_ops ); + if (reply) { reply->type = FILE_TYPE_PIPE; @@ -288,6 +295,10 @@ reply->index_low = 0; reply->serial = 0; } + + if ( sock->flags & WSA_FLAG_OVERLAPPED ) + return FD_TYPE_SOCKET | FD_TYPE_FLAG_OVERLAPPED; + return FD_TYPE_SOCKET; } @@ -297,6 +308,13 @@ assert( obj->ops == &sock_ops ); /* FIXME: special socket shutdown stuff? */ + + if ( sock->flags & WSA_FLAG_OVERLAPPED ) + { + destroy_async_queue ( &sock->read_q ); + destroy_async_queue ( &sock->write_q ); + } + if (sock->event) { /* if the service thread was waiting for the event object, @@ -310,7 +328,7 @@ } /* create a new and unconnected socket */ -static struct object *create_socket( int family, int type, int protocol ) +static struct object *create_socket( int family, int type, int protocol, unsigned int flags ) { struct sock *sock; int sockfd; @@ -329,9 +347,15 @@ sock->mask = 0; sock->hmask = 0; sock->pmask = 0; + sock->flags = flags; sock->event = NULL; sock_reselect( sock ); clear_error(); + if (sock->flags & WSA_FLAG_OVERLAPPED) + { + init_async_queue (&sock->read_q); + init_async_queue (&sock->write_q); + } return &sock->obj; } @@ -377,6 +401,12 @@ acceptsock->event = NULL; if (sock->event && !(sock->mask & FD_WINE_SERVEVENT)) acceptsock->event = (struct event *)grab_object( sock->event ); + acceptsock->flags = sock->flags; + if ( acceptsock->flags & WSA_FLAG_OVERLAPPED ) + { + init_async_queue ( &acceptsock->read_q ); + init_async_queue ( &acceptsock->write_q ); + } sock_reselect( acceptsock ); clear_error(); @@ -463,7 +493,7 @@ struct object *obj; reply->handle = 0; - if ((obj = create_socket( req->family, req->type, req->protocol )) != NULL) + if ((obj = create_socket( req->family, req->type, req->protocol, req->flags )) != NULL) { reply->handle = alloc_handle( current->process, obj, req->access, req->inherit ); release_object( obj );

Jan. 7, 2002

Patch: 002-fd_type.diff

by Martin Wilck

Patch 2 in the series, a repost of my patch to wine-devel of 2002-01-03, Now incremental to the previous patch (i.e., also relies on Mike's patches being applied). Patch file: 002-fd_type.diff Purpose: More general approach to file descriptor types and flags. Created: 2002-01-07 Applies: CVS 2002-01-07 (with 001-file_overlapped.diff applied) If overlapped IO is to be allowed / implemented for several different types of file descriptors (regular files, serial ports, pipes, sockets, ...), a more general scheme must be found to obtain file descriptor types and flags or capabilities. The current scheme treats FD_TYPE_OVERLAPPED as a special type, making it impossible to distinguish between e.g. overlapped files and overlapped sockets. This patch fixes this behaviour by modifying the meaning of return value of the get_file_info() function. ** NOTE ON BUILDING: tools/make_requests must be run ** ** after applying this patch ** server/protocol.def: The lowest byte of the type value is reserved for the type itself (macro FD_TYPE (type)the rest is available for miscellaneous flags. New FD types: FD_TYPE_DEVICE, FD_TYPE_NAMED_PIPE, FD_TYPE_PIPE, FD_TYPE_SERIAL, FD_TYPE_SOCKET. New FD flags (were formerly FD types): FD_TYPE_FLAG_OVERLAPPED: The fd uses overlapped I/O. FD_TYPE_FLAG_TIMEOUT: The fd applies a timeout on its I/O operations New test macros: FD_TYPE_IS_OVERLAPPED (type), FD_TYPE_HAS_TIMEOUT (type) server/device.c: device_get_info(): return FD_TYPE_DEVICE. server/file.c: file_get_info(): set FD_TYPE_FLAG_OVERLAPPED on overlapped files. server/named_pipe.c: named_pipe_get_info(): return FD_TYPE_NAMED_PIPE. server/pipe.c: named_pipe_get_info(): return FD_TYPE_PIPE. server/serial.c: serial_get_info(): return FD_TYPE_SERIAL, account for OVERLAPPED and TIMEOUT flags. server/serial.c: sock_get_info(): return FD_TYPE_SOCKET. files/file.c: ReadFile(): Replace FD_TYPE_XYZ dependent switch statement with an equivalent if/elseif construct which will allow a morte fine-grained destinction of fd types and flags in the future. WriteFile(): dito. Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Mon Jan 7 16:04:31 2002 +++ MW/wine/files/file.c Mon Jan 7 16:00:33 2002 @@ -1467,9 +1467,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_READ, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1512,15 +1511,21 @@ /* fail on return, with ERROR_IO_PENDING */ SetLastError(ERROR_IO_PENDING); return FALSE; + } - case FD_TYPE_CONSOLE: + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { return ReadConsoleA(hFile, buffer, bytesToRead, bytesRead, NULL); + } - case FD_TYPE_TIMEOUT: + else if ( FD_TYPE_HAS_TIMEOUT (type) ) + { close(unix_handle); return FILE_TimeoutRead(hFile, buffer, bytesToRead, bytesRead); + } - default: + else + { /* normal unix files */ if (unix_handle == -1) return FALSE; @@ -1530,7 +1535,6 @@ SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } - break; } /* code for synchronous reads */ @@ -1689,9 +1693,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_WRITE, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1741,11 +1744,17 @@ SetLastError(ERROR_IO_PENDING); return FALSE; - case FD_TYPE_CONSOLE: + } + + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { TRACE("%d %s %ld %p %p\n", hFile, debugstr_an(buffer, bytesToWrite), bytesToWrite, bytesWritten, overlapped ); return WriteConsoleA(hFile, buffer, bytesToWrite, bytesWritten, NULL); - default: + } + + else + { if (unix_handle == -1) return FALSE; } diff -ruX diffignore CVS/wine/server/device.c MW/wine/server/device.c --- CVS/wine/server/device.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/device.c Mon Jan 7 16:00:33 2002 @@ -83,7 +83,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_DEVICE; } /* create a device */ diff -ruX diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Mon Jan 7 15:58:22 2002 +++ MW/wine/server/file.c Mon Jan 7 16:00:33 2002 @@ -308,6 +308,7 @@ { struct stat st; struct file *file = (struct file *)obj; + int fd_type = FD_TYPE_DEFAULT; assert( obj->ops == &file_ops ); if (reply) @@ -342,9 +343,10 @@ } if (file->flags & FILE_FLAG_OVERLAPPED) - return FD_TYPE_OVERLAPPED; + fd_type |= FD_TYPE_FLAG_OVERLAPPED; + + return fd_type; - return FD_TYPE_DEFAULT; } static struct async_queue *file_queue_async(struct object *obj, struct async *async, int type, int count) diff -ruX diffignore CVS/wine/server/named_pipe.c MW/wine/server/named_pipe.c --- CVS/wine/server/named_pipe.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/named_pipe.c Mon Jan 7 16:00:33 2002 @@ -197,7 +197,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_NAMED_PIPE; } static struct named_pipe *create_named_pipe( const WCHAR *name, size_t len ) diff -ruX diffignore CVS/wine/server/pipe.c MW/wine/server/pipe.c --- CVS/wine/server/pipe.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/pipe.c Mon Jan 7 16:00:33 2002 @@ -140,7 +140,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_PIPE; } static void pipe_destroy( struct object *obj ) diff -ruX diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Mon Jan 7 15:45:26 2002 +++ MW/wine/server/protocol.def Mon Jan 7 16:00:33 2002 @@ -544,12 +544,22 @@ int fd; /* file descriptor */ int type; /* the type of file */ @END +#define FD_TYPE(x) ((x) & 0xff) + #define FD_TYPE_INVALID 0 #define FD_TYPE_DEFAULT 1 #define FD_TYPE_CONSOLE 2 -#define FD_TYPE_OVERLAPPED 3 -#define FD_TYPE_TIMEOUT 4 +#define FD_TYPE_DEVICE 3 +#define FD_TYPE_NAMED_PIPE 4 +#define FD_TYPE_PIPE 5 +#define FD_TYPE_SERIAL 6 +#define FD_TYPE_SOCKET 7 + +#define FD_TYPE_FLAG_OVERLAPPED 0x100 +#define FD_TYPE_FLAG_TIMEOUT 0x200 +#define FD_TYPE_IS_OVERLAPPED(x) ((x) & FD_TYPE_FLAG_OVERLAPPED) +#define FD_TYPE_HAS_TIMEOUT(x) ((x) & FD_TYPE_FLAG_TIMEOUT) /* Set a file current position */ @REQ(set_file_pointer) diff -ruX diffignore CVS/wine/server/serial.c MW/wine/server/serial.c --- CVS/wine/server/serial.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/serial.c Mon Jan 7 16:00:33 2002 @@ -192,6 +192,7 @@ static int serial_get_info( struct object *obj, struct get_file_info_reply *reply ) { struct serial *serial = (struct serial *) obj; + int fd_type = FD_TYPE_SERIAL; assert( obj->ops == &serial_ops ); if (reply) @@ -209,13 +210,13 @@ } if(serial->attrib & FILE_FLAG_OVERLAPPED) - return FD_TYPE_OVERLAPPED; + fd_type |= FD_TYPE_FLAG_OVERLAPPED; - if( (serial->readinterval == MAXDWORD) && - (serial->readmult == 0) && (serial->readconst == 0) ) - return FD_TYPE_DEFAULT; + else if( !((serial->readinterval == MAXDWORD) && + (serial->readmult == 0) && (serial->readconst == 0)) ) + fd_type |= FD_TYPE_FLAG_TIMEOUT; - return FD_TYPE_TIMEOUT; + return fd_type; } static void serial_poll_event(struct object *obj, int event) diff -ruX diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Mon Jan 7 15:45:26 2002 +++ MW/wine/server/sock.c Mon Jan 7 16:00:33 2002 @@ -288,7 +288,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_SOCKET; } static void sock_destroy( struct object *obj )

Jan. 7, 2002

Patch: 001-file_overlapped.diff

by Martin Wilck

This patch is a repost of my patch of 2002-01-03, now against the current CVS version including Mike McCormack's latest patches (01-cancelio.diff, 01-write_file_update.diff, 01-comm16_update.diff as of 2002-01-06). It is the first in a series of patches that constitute intermediate steps towards async socket IO. I consider them pretty clean and have done basic testing. My testing possibilities are limited, though - I'd be grateful to anybody who could run tests especially with 16-bit network-oriented windows applications. Bugs in my code should show up immediately as regressions. Patch file: 001-file_overlapped.diff Purpose: This patch fixes overlapped I/O on regular files. Created: 2002-01-07 Applies: CVS 2002-01-07 with Mike McCorkack's patches of 2002-01-06 applied (01-cancelio.diff, 01-write_file_update.diff, 01-comm16_update.diff) Add server side support for async IO on files. FILE_Async[Read|Write]Service and WriteFile() use pread() / pwrite() rather than read() / write () for fd's on which lseek()ing is possible to honour the fact that lpOverlapped->Offset and lpOverlapped->OffsetHigh contain the offset from which the file is to be read. files/file.c: OVERLAPPED_OFFSET: Macro to calculate file offset from OVERLAPPED struct. FILE_AsyncReadService(): Use pread() on fd's that allow lseek(). FILE_AsyncWriteService(): Use pwrite() on fd's that allow lseek(). WriteFile(): dito. server/file.c: struct file: Add two struct async_queue fields (for async read/write). file_ops: file specific poll_event() method accounts for overlapped IO. define queue_async() method. create_file_for_fd(): call init_async_queue() on overlapped files. file_poll_event(): call default_poll_event() only after checking for queued async requests. file_get_info(): return FD_TYPE_OVERLAPPED if FILE_FLAG_OVERLAPPED is set. file_queue_async(): implement queue_async() method for files. file_destroy(): destroy async queues on overlapped files. Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Mon Jan 7 15:54:59 2002 +++ MW/wine/files/file.c Mon Jan 7 15:55:36 2002 @@ -9,6 +9,9 @@ * Right now, they simply call the CopyFile method. */ +/* This is needed to avoid compile-time warnings about pread / pwrite */ +#define _GNU_SOURCE +#define _XOPEN_SOURCE 500 #include "config.h" #include "wine/port.h" @@ -55,6 +58,9 @@ /* Size of per-process table of DOS handles */ #define DOS_TABLE_SIZE 256 +/* Macro to derive file offset from OVERLAPPED struct */ +#define OVERLAPPED_OFFSET(overlapped) ((off_t) (overlapped)->Offset + ((off_t) (overlapped)->OffsetHigh << 32)) + static HANDLE dos_handles[DOS_TABLE_SIZE]; @@ -1304,12 +1310,21 @@ { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; + int already = lpOverlapped->InternalHigh; TRACE("%p %p\n", lpOverlapped, ovp->buffer ); /* check to see if the data is ready (non-blocking) */ - result = read(ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], - ovp->count - lpOverlapped->InternalHigh); + + /* Check if this file object can lseek() */ + /* FIXME: test this only once for each file object ?? */ + if (lseek (ovp->fd, 0, SEEK_CUR) != (off_t) -1) + result = pread (ovp->fd, + &ovp->buffer[already], + ovp->count - already, + OVERLAPPED_OFFSET (lpOverlapped) + already); + else + result = read (ovp->fd, &ovp->buffer[already], ovp->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1543,12 +1558,21 @@ { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; + int already = lpOverlapped->InternalHigh; TRACE("(%p %p)\n",lpOverlapped,ovp->buffer); /* write some data (non-blocking) */ - result = write(ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], - ovp->count-lpOverlapped->InternalHigh); + + /* Check if this file object can lseek() */ + /* FIXME: test this only once for each file object ?? */ + if (lseek (ovp->fd, 0, SEEK_CUR) != (off_t) -1) + result = pwrite (ovp->fd, + &ovp->buffer[already], + ovp->count - already, + OVERLAPPED_OFFSET (lpOverlapped) + already); + else + result = write (ovp->fd, &ovp->buffer[already], ovp->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1678,7 +1702,13 @@ } /* see if we can write some data already (this shouldn't block) */ - result = write( unix_handle, buffer, bytesToWrite ); + + if ( lseek(unix_handle, 0, SEEK_CUR) != (off_t) -1 ) + result = pwrite( unix_handle, buffer, bytesToWrite, + OVERLAPPED_OFFSET (overlapped) ); + else + result = write( unix_handle, buffer, bytesToWrite ); + close(unix_handle); if(result<0) @@ -1693,7 +1723,7 @@ result = 0; } - /* if we read enough to keep the app happy, then return now */ + /* if we wrote enough to keep the app happy, then return now */ if(result>=bytesToWrite) { *bytesWritten = result; diff -ruX diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Mon Jan 7 15:54:59 2002 +++ MW/wine/server/file.c Mon Jan 7 15:55:28 2002 @@ -29,6 +29,7 @@ #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" struct file { @@ -39,6 +40,9 @@ unsigned int flags; /* flags (FILE_FLAG_*) */ unsigned int sharing; /* file sharing mode */ int drive_type; /* type of drive the file is on */ + + struct async_queue read_q; + struct async_queue write_q; }; #define NAME_HASH_SIZE 37 @@ -47,10 +51,12 @@ static void file_dump( struct object *obj, int verbose ); static int file_get_poll_events( struct object *obj ); +static void file_poll_event( struct object *obj, int event ); static int file_get_fd( struct object *obj ); static int file_flush( struct object *obj ); static int file_get_info( struct object *obj, struct get_file_info_reply *reply ); static void file_destroy( struct object *obj ); +static struct async_queue * file_queue_async(struct object *obj, struct async* async, int type, int count); static const struct object_ops file_ops = { @@ -61,11 +67,11 @@ default_poll_signaled, /* signaled */ no_satisfied, /* satisfied */ file_get_poll_events, /* get_poll_events */ - default_poll_event, /* poll_event */ + file_poll_event, /* poll_event */ file_get_fd, /* get_fd */ file_flush, /* flush */ file_get_info, /* get_file_info */ - NULL, /* queue_async */ + file_queue_async, /* queue_async */ file_destroy /* destroy */ }; @@ -116,6 +122,11 @@ file->flags = attrs; file->sharing = sharing; file->drive_type = drive_type; + if (file->flags & FILE_FLAG_OVERLAPPED) + { + init_async_queue (&file->read_q); + init_async_queue (&file->write_q); + } } return file; } @@ -253,6 +264,27 @@ return events; } +static void file_poll_event( struct object *obj, int event ) +{ + struct file *file = (struct file *)obj; + assert( obj->ops == &file_ops ); + if ( file->flags & FILE_FLAG_OVERLAPPED ) + { + if( IS_READY(file->read_q) && (POLLIN & event) ) + { + async_notify(file->read_q.head, STATUS_ALERTED); + return; + } + if( IS_READY(file->write_q) && (POLLIN & event) ) + { + async_notify(file->write_q.head, STATUS_ALERTED); + return; + } + } + default_poll_event( obj, event ); +} + + static int file_get_fd( struct object *obj ) { struct file *file = (struct file *)obj; @@ -308,9 +340,45 @@ reply->index_low = st.st_ino; reply->serial = 0; /* FIXME */ } + + if (file->flags & FILE_FLAG_OVERLAPPED) + return FD_TYPE_OVERLAPPED; + return FD_TYPE_DEFAULT; } +static struct async_queue *file_queue_async(struct object *obj, struct async *async, int type, int count) +{ + struct file *file = (struct file *)obj; + struct async_queue *q; + + assert( obj->ops == &file_ops ); + + if ( !(file->flags & FILE_FLAG_OVERLAPPED) ) + { + set_error ( STATUS_INVALID_HANDLE ); + return NULL; + } + + switch(type) + { + case ASYNC_TYPE_READ: + q = &file->read_q; + break; + case ASYNC_TYPE_WRITE: + q = &file->write_q; + break; + default: + set_error( STATUS_INVALID_PARAMETER ); + return NULL; + } + + if(async && !async->q) + async_insert(q, async); + + return q; +} + static void file_destroy( struct object *obj ) { struct file *file = (struct file *)obj; @@ -325,6 +393,11 @@ *pptr = (*pptr)->next; if (file->flags & FILE_FLAG_DELETE_ON_CLOSE) unlink( file->name ); free( file->name ); + } + if (file->flags & FILE_FLAG_OVERLAPPED) + { + destroy_async_queue (&file->read_q); + destroy_async_queue (&file->write_q); } }

Jan. 7, 2002

mvcrt patch

by Waldek Hebisch

Enclosed is a patch (diff to 2001.12.26 snapshot) which impements stdio buffering in msvcrt. Since I cannot make Visual C binaries could anybady with Visual C++ test it? I have testet it with mingw32 and I incude my test program (iotst.c). The program prints a line indicating which test it is making and then complains about failures. Comment 1: current builtin msvcrt fails test1 (and few other as a consequence). Some native versions of msvcrt fail test 8. Comment 2: I wrote the test the way naive programmer would wrote it (IMHO). Now I think that for a testing framework we need an assert-like macro to make checking and printing code shorter and to have uniform printouts. I ommited some tests that require multiple processes (expandig file while it is read, checking that stdio buffers got flushed at exit) - I guess that doing such test in portable way is quite tricky. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

Jan. 7, 2002

Changes regarding wnaspi32 layer ?

by ma.hoff＠t-online.de

Hi, i have some problems with the winaspi implementation (scsi cd-writer) of the current version of Wine (tried cvs one or two weeks ago ...) With the version 20010731 which is included in my SuSE 7.3 distribution it works fine (except for some graphic glitches in the application - but thats another story). I try to run Aheads Nero Burning Rom 5.0 , which refuses to detect the cd-writer with the newer versions of wine ! I heard of someone running a cvs snapshot from october 2001 which is working, too - but all later version of wine refuse to work with nero ! The error message is the following: fixme:win32:DEVICE_Open Unknown/unsupported VxD nerocd95. Try --winver nt40 or win31 ! fixme:win32:DEVICE_Open Unknown/unsupported VxD BsUDF.VXD. Try --winver nt40 or win31 ! Guess what: --winver nt40 / win31 didn't change anything :-) So it seems that its not implemented, but with older versions it worked ! Is this a known bug - or do i have to change something else when using the newer version of wine ? Or is it just broken ? Thanks in advance for any help ! Martin

Jan. 6, 2002

Re: cutting teeth

by Andriy Palamarchuk

Shane, welcome to the Wine developers list! Shane Shields wrote: > hello everybody, > > just want to let everyone know that i (shane shields) have joined the mailing > list and downloaded the latest cvs. > > what i want to know now is what can i do i have some c experience but mostly > dos (and some windows), vb (but i dont think its relevent) and i know the > windows os quite well. as i converted to linux 8 months ago and totally > removed windows i would like to help with wine development with the aim of > not having to use any proprietry dlls at all (to do with the core os that > is). i have looked at the 20011226 version and noticed that the ole > functionality is virtually nonexistant. is anyone working on that? or is > there a better way to cut my teeth with wine programming. suggestions, > directions and flames welcome. just remember that i am relatively new to > linux programming. > > looking forward to joining the community > Shane Shields Your experience is the most relevant to the project. A lot of things can be done in pure Win32 API. Start from small things to become familiar with Wine, development process. Look in the archive of this mailinng list - there was thread with Subj "Wine Tasklist" which will have you some clues what is needed. Another good approach is to run an application, see what breaks and fix it. Another really easy thing for developer with your experience (and very needed) is to write unit tests. We are still discussing the best approach but work already started. See thread "We *really* need a development model change !" for more details. I'd also recommend you to setup CVS access to Wine source tree. Knowlege of CVS will be valuable for you outside of the Wine project. See documentation on winehq.com how to start with CVS. Happy hacking! Andriy Palamarchuk

Jan. 6, 2002

Re: WinSpool Ordinal Addition

by Alexandre Julliard

"Mark G. Adams" <mgadams(a)sympatico.ca> writes: > I came across a program which imports a function from winspool.drv via > ordinal instead of via name. Now back in February, a patch from Huw Davies > was committed which removed all the ordinals from the spec file for winspool > (see http://www.winehq.com/hypermail/wine-cvs/2001/02/0016.html) I don't > know what the reason was (maybe some were wrong?), so I've attached a patch > which re-adds the ordinal for the one function this program requires. What app is that? None of the winspool.drv I checked have PrinterProperties at ordinal 201, so I don't see how this could work. Or does it just want to have something there? does it work if you put a stub at 201 instead of PrinterProperties? -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2002

RE: PATCH: Euro

by Patrik Stridvall

> On Sun, 6 Jan 2002, Patrik Stridvall wrote: > > > > This patch changes the NLS currency of all Euro countries to > > > use the "EUR" > > > as international currency and the euro-sign (iso-8859-15, > > > character 164). > > > > Hmm. While I'm do not doubt that some users of Wine might > find this useful, > > Wine is supposed to do what Windows does and if Windows > does something > > wrong Wine usually should as well. > > Wrong? Microsoft has released Euro updates for Windows, which > seems like > it's supposed to change the Windows NLS files to use the new > currency. It > should be available on the Windows Update site. I don't see > anything wrong > here. You are sure it changes the .NLS files (the default), not just the "copy" in registry? Does patches exists for all versions of Windows? Including Windows 3.1 and Windows 95? Anyway, I'm not worried primarily about this specific patch, but that any deviation from Windows no matter how "correct" it is in some meaning will make it harder to for example write a test suite for Wine. If no patch exist for say Windows 95 all Windows 95 users will have to make the change in the registry and the test suite on such a platform might not work correctly. Again this is not an argument for not having this patch including but rather a warning that we need to be careful when we have to do this type of changes. Obviously Wine must handle the Euro correctly, regardless what Windows do, otherwise we might get bad press and/or annoyed users.

Jan. 6, 2002

RE: PATCH: Euro

by Ove Kaaven

On Sun, 6 Jan 2002, Patrik Stridvall wrote: > > This patch changes the NLS currency of all Euro countries to > > use the "EUR" > > as international currency and the euro-sign (iso-8859-15, > > character 164). > > Hmm. While I'm do not doubt that some users of Wine might find this useful, > Wine is supposed to do what Windows does and if Windows does something > wrong Wine usually should as well. Wrong? Microsoft has released Euro updates for Windows, which seems like it's supposed to change the Windows NLS files to use the new currency. It should be available on the Windows Update site. I don't see anything wrong here.

Jan. 6, 2002

Re: PATCH: Euro

by Marcus Meissner

> So I do not really oppose the patch. It is more the principle I'm intrested > in: > Under what circumstances should Wine change the behavior > if Windows does something in the wrong way? I have no clue how windows does that, do they have Euro service pack? Fact is though that the the currency has been changed, so it should be reflected in the NLS defaults. Ciao, Marcus

Jan. 6, 2002

RE: PATCH: Euro

by lawson_whitney＠juno.com

On Sun, 6 Jan 2002, Patrik Stridvall wrote: > > This patch changes the NLS currency of all Euro countries to > > use the "EUR" > > as international currency and the euro-sign (iso-8859-15, > > character 164). > > Hmm. While I'm do not doubt that some users of Wine might find this useful, > Wine is supposed to do what Windows does and if Windows does something > wrong Wine usually should as well. Nuts! Wine is an implementation of the windows API, not a copy of any damned thing. We only need to implement bugs when some useful apps rely on them. Lawson

Jan. 6, 2002

cutting teeth

by Shane Shields

hello everybody, just want to let everyone know that i (shane shields) have joined the mailing list and downloaded the latest cvs. what i want to know now is what can i do i have some c experience but mostly dos (and some windows), vb (but i dont think its relevent) and i know the windows os quite well. as i converted to linux 8 months ago and totally removed windows i would like to help with wine development with the aim of not having to use any proprietry dlls at all (to do with the core os that is). i have looked at the 20011226 version and noticed that the ole functionality is virtually nonexistant. is anyone working on that? or is there a better way to cut my teeth with wine programming. suggestions, directions and flames welcome. just remember that i am relatively new to linux programming. looking forward to joining the community Shane Shields _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Jan. 6, 2002

RE: PATCH: Euro

by Patrik Stridvall

> This patch changes the NLS currency of all Euro countries to > use the "EUR" > as international currency and the euro-sign (iso-8859-15, > character 164). Hmm. While I'm do not doubt that some users of Wine might find this useful, Wine is supposed to do what Windows does and if Windows does something wrong Wine usually should as well. If I'm not mistaken the .nls contains that default values. It is entirely possible to change the currency and such in the registry to specify things differently for each user. That said I would find it unlikely that this patch would cause any serious problem. After all, as I said, the user can specify whatever currency it likes after the defaults have been set and every application is supposed to be able to handle it. So I do not really oppose the patch. It is more the principle I'm intrested in: Under what circumstances should Wine change the behavior if Windows does something in the wrong way?

Jan. 6, 2002

Re: MSDOS Error Table Handling

by ccrayne＠crayne.org

In <Pine.LNX.4.21.0201052317120.4461-100000(a)mizar.ping.uio.no>, on 01/05/02 at 11:29 PM, Ove Kaaven <ovehk(a)ping.uio.no> said: :So stuff like that must probably either be initialized :before the executable is loaded, or DPMI must reserve some DOS memory for :itself which it can allocate RMCBs from. (The latter may be a good idea :anyway, it may even be in the DPMI spec) My documention says "DPMI must provide 16 callback addresses per client". However, since this has not yet been implemented in wine, and since I need to move on to finding out what change between the 20010822 and 20011226 versions of wine broke the last error handling logic for DOS, I will resubmit my patch with the minimal changes necessary to use an RMCB. -- Chuck Crayne ----------------------------------------------------------- ccrayne(a)crayne.org -----------------------------------------------------------

Jan. 5, 2002

Re: Debugger on Solaris

by Robert Lunnon

> On Fri, 4 Jan 2002 10:49, Alexandre Julliard wrote: > > Robert Lunnon <bobNoSpaM(a)yarrabee.net.au> writes: > > > Without calling ptrace (TRACEME,...) Solaris returns ESRCH even though > > > the process exists which causes the wineserver to assume the process is > > > defunct and delete the app, apparently causing the deadlock (This > > > deadlock will have to be fixed too !). > > > > Are you sure this is not rather an issue of process id vs. thread id? > > I would be surprised if Solaris required TRACEME in this case, since > > this would mean you couldn't attach a debugger to a running process. > >it seems something is missing from your mail <grin> > >-- >Alexandre Julliard >julliard(a)winehq.com Some strange behaviour of my mail client is removing edits from replies Sorry all. Here is what the Sun man page says about Ptrace, with apologies to sun, you can find this page at docs.sun.com. Not the comment for call 0 (TRACEME) and ESRCH in the error section System Calls ptrace(2) NAME ptrace - allows a parent process to control the execution of a child process SYNOPSIS #include <unistd.h> #include <sys/types.h> int ptrace(int request, pid_t pid, int addr, int data); DESCRIPTION The ptrace() function allows a parent process to control the execution of a child process. Its primary use is for the implementation of breakpoint debugging. The child process behaves normally until it encounters a signal (see signal(3HEAD)), at which time it enters a stopped state and its parent is notified via the wait(2) function. When the child is in the stopped state, its parent can examine and modify its "core image" using ptrace(). Also, the parent can cause the child either to terminate or continue, with the possibility of ignoring the signal that caused it to stop. The request argument determines the action to be taken by ptrace() and is one of the following: 0 This request must be issued by the child process if it is to be traced by its parent. It turns on the child's trace flag that stipulates that the child should be left in a stopped state on receipt of a signal rather than the state specified by func (see signal(3C)). The pid, addr, and data arguments are ignored, and a return value is not defined for this request. Peculiar results ensue if the parent does not expect to trace the child. The remainder of the requests can only be used by the parent process. For each, pid is the process ID of the child. The child must be in a stopped state before these requests are made. 1, 2 With these requests, the word at location addr in the address space of the child is returned to the parent process. If instruction and data space are separated, request 1 returns a word from instruction space, and request 2 returns a word from data space. If instruc- tion and data space are not separated, either request 1 or request 2 may be used with equal results. The data argument is ignored. These two requests fail if addr is not the start address of a word, in which case -1 is returned to the parent process and the parent's errno is set to EIO. SunOS 5.8 Last change: 5 Jul 1990 1 System Calls ptrace(2) 3 With this request, the word at location addr in the child's user area in the system's address space (see <sys/user.h>) is returned to the parent process. The data argument is ignored. This request fails if addr is not the start address of a word or is outside the user area, in which case -1 is returned to the parent process and the parent's errno is set to EIO. 4, 5 With these requests, the value given by the data argu- ment is written into the address space of the child at location addr. If instruction and data space are separated, request 4 writes a word into instruction space, and request 5 writes a word into data space. If instruction and data space are not separated, either request 4 or request 5 may be used with equal results. On success, the value written into the address space of the child is returned to the parent. These two requests fail if addr is not the start address of a word. On failure -1 is returned to the parent process and the parent's errno is set to EIO. 6 With this request, a few entries in the child's user area can be written. data gives the value that is to be written and addr is the location of the entry. The few entries that can be written are the general regis- ters and the condition codes of the Processor Status Word. 7 This request causes the child to resume execution. If the data argument is 0, all pending signals including the one that caused the child to stop are canceled before it resumes execution. If the data argument is a valid signal number, the child resumes execution as if it had incurred that signal, and any other pending signals are canceled. The addr argument must be equal to 1 for this request. On success, the value of data is returned to the parent. This request fails if data is not 0 or a valid signal number, in which case -1 is returned to the parent process and the parent's errno is set to EIO. 8 This request causes the child to terminate with the same consequences as exit(2). 9 This request sets the trace bit in the Processor Status Word of the child and then executes the same steps as listed above for request 7. The trace bit causes an interrupt on completion of one machine instruction. This effectively allows single stepping of the child. SunOS 5.8 Last change: 5 Jul 1990 2 System Calls ptrace(2) To forestall possible fraud, ptrace() inhibits the set- user-ID facility on subsequent calls to one of the exec fam- ily of functions (see exec(2)). If a traced process calls one of the exec functions, it stops before executing the first instruction of the new image showing signal SIGTRAP. ERRORS The ptrace() function will fail if: EIO The request argument is an illegal number. EPERM The effective user of the calling process is not super-user. ESRCH The pid argument identifies a child that does not exist or has not executed a ptrace() call with request 0. SEE ALSO exec(2), exit(2), wait(2), signal(3C), signal(3HEAD)

Jan. 5, 2002

Re: MSDOS Error Table Handling

by Ove Kaaven

On Sat, 5 Jan 2002 ccrayne(a)crayne.org wrote: > That being the case, what do you think about removing the > DOSMEM_InitErrorTable function entirely, and letting int2f funcion 0x122e > subfunction 8 allocate the RMCB, and the associated real mode message > buffer, the first time it is called? Well, while good in theory, it won't currently always work too well with the current implementation, because DPMI_AllocRMCB allocates memory directly from the DOS memory pool, not from memory reserved for DPMI, which means that most executables, e.g. command.com, which by default allocate *all* available DOS memory, will cause such a DOS memory allocation to fail. So stuff like that must probably either be initialized before the executable is loaded, or DPMI must reserve some DOS memory for itself which it can allocate RMCBs from. (The latter may be a good idea anyway, it may even be in the DPMI spec)

Jan. 5, 2002

Re: MSDOS Error Table Handling

by ccrayne＠crayne.org

In <Pine.LNX.4.21.0201051112170.4461-100000(a)mizar.ping.uio.no>, on 01/05/02 at 11:38 AM, Ove Kaaven <ovehk(a)ping.uio.no> said: :I'm not concerned about runtime technicalities in this case (this is not :a performance-critical operation by any means), what's important is code :clarity and maintainability. Adding all kinds of Wine-specific function :handlers and associated asm code all over the place doesn't help :clarity, maintainability, or modularity. (I feel it's already wrong for :Wine's XMS code to not use the RMCB facility... my excuse is that they :didn't exist when I wrote that XMS code... and probably not when Joseph :started on the DOS error tables either) That being the case, what do you think about removing the DOSMEM_InitErrorTable function entirely, and letting int2f funcion 0x122e subfunction 8 allocate the RMCB, and the associated real mode message buffer, the first time it is called? In addition to consolidating all of the error table handling in one place, it would mean that no real mode space would be reserved unless a program actually called the function. -- Chuck Crayne ----------------------------------------------------------- ccrayne(a)crayne.org -----------------------------------------------------------

Jan. 5, 2002

Re: MSDOS Error Table Handling

by Ove Kaaven

On Fri, 4 Jan 2002 ccrayne(a)crayne.org wrote: > Thank you for pointing out the DPMI function to me. However, before > discussing the advantages and disadvantages of your suggestion, I feel > obligated to point out that all I have done is to fix the existing broken > code, and therefore can not speak to what design alternatives the original > author may have considered. In fact, my search of the change logs has > failed to find any mention of DOSMEM_InitErrorTable whatsoever. If the > original author of this code still follows the wine-devl list, perhaps he > or she will enlighten us. Seems to be in documentation/ChangeLog.OLD Fri Aug 28 21:04:13 1998 Joseph Pranevich <knight(a)baltimore.wwaves.com> * [msdos/dosmem.c] [msdos/int2f.c] Added beginnings of DOS error table. Nothing is done on those error tables since, and Joseph hasn't been active for quite a while. > Speaking for myself, the phrase "WINE-only interrupt" is misleading. The > reality is that DOS uses int2f ax:0x122e for setting and getting the > address of various error tables. The specific routine is selected by the > value in dl, of which only the values 0-9 are defined. My fix adds dl:0x7f > as the wine routine which moves the requested error message to the real > mode buffer. I noticed. > To me, it seems that the only advantage to using the DPMI callback > mechanism in this specific case, is that it would save nine bytes of real > mode memory, at a cost of degraded performance and increased code > complexity. I'm not concerned about runtime technicalities in this case (this is not a performance-critical operation by any means), what's important is code clarity and maintainability. Adding all kinds of Wine-specific function handlers and associated asm code all over the place doesn't help clarity, maintainability, or modularity. (I feel it's already wrong for Wine's XMS code to not use the RMCB facility... my excuse is that they didn't exist when I wrote that XMS code... and probably not when Joseph started on the DOS error tables either) How are people going to know that dl=0x7f is wine-specific (you haven't even marked it as such in the code), and what if it turns out that MS used dl=0x7f for something after all, and someone decides to implement it? Then they need to also find that asm code and figure out how to change it, or break stuff. Using RMCBs, you don't need to hook into such handlers, the thunking is all done for you, so code clarity and maintainability increases.

Jan. 5, 2002

Re: ReadFile() question (Bug?)

by Mike McCormack

Hi Martin, The console doesn't use an fd, so no fd will be fetched in FILE_GetUnixHandle. (have a look at server/console.c) Mike > Btw, > > in the code in ReadFile() / WriteFile() handling consoles, > shouldn't there be a > close (unix_handle) > statement before calling ReadConsoleA() / WriteConsoleA() ? > > Martin ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Jan. 4, 2002