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

PATCH: async-sock-server.diff (7 in series)

by Martin Wilck

PATCH: async-sock-server.diff Basic implementation of async IO queues in the server code for sockets. Patch against: CVS-2002-04-12, with my sock-fd-type patch applied. Modified files: server: sock.c diff -ruNX ignore TMP/wine/server/sock.c MW/wine/server/sock.c --- TMP/wine/server/sock.c Fri Apr 12 14:38:16 2002 +++ MW/wine/server/sock.c Fri Apr 12 15:26:36 2002 @@ -86,6 +86,7 @@ static void sock_destroy( struct object *obj ); static int sock_get_error( int err ); static void sock_set_error(void); +static struct async_queue * sock_queue_async(struct object *obj, struct async* async, int type, int count); static const struct object_ops sock_ops = { @@ -100,7 +101,7 @@ sock_get_fd, /* get_fd */ no_flush, /* flush */ sock_get_info, /* get_file_info */ - NULL, /* queue_async */ + sock_queue_async, /* queue_async */ sock_destroy /* destroy */ }; @@ -229,6 +230,21 @@ } } else { + + if ( sock->flags & WSA_FLAG_OVERLAPPED ) + { + if( IS_READY(sock->read_q) && (POLLIN & event) ) + { + if (debug_level) fprintf ( stderr, "activating read queue for socket %p\n", sock ); + async_notify(sock->read_q.head, STATUS_ALERTED); + } + if( IS_READY(sock->write_q) && (POLLOUT & event) ) + { + if (debug_level) fprintf ( stderr, "activating write queue for socket %p\n", sock ); + async_notify(sock->write_q.head, STATUS_ALERTED); + } + } + /* normal data flow */ if (event & POLLIN) { @@ -312,6 +328,8 @@ int ev = 0; assert( obj->ops == &sock_ops ); + if ( debug_level ) + fprintf (stderr, "mask: %x %x %x -> %x\n", sock->mask, sock->state, sock->hmask, mask); if (sock->state & FD_CONNECT) /* connecting, wait for writable */ @@ -320,8 +338,11 @@ /* listening, wait for readable */ return (sock->hmask & FD_ACCEPT) ? 0 : POLLIN; - if (mask & FD_READ) ev |= POLLIN | POLLPRI; - if (mask & FD_WRITE) ev |= POLLOUT; + if (mask & FD_READ || (sock->flags & WSA_FLAG_OVERLAPPED && IS_READY (sock->read_q))) + ev |= POLLIN | POLLPRI; + if (mask & FD_WRITE || (sock->flags & WSA_FLAG_OVERLAPPED && IS_READY (sock->write_q))) + ev |= POLLOUT; + return ev; } @@ -353,6 +374,38 @@ *flags = 0; if (sock->flags & WSA_FLAG_OVERLAPPED) *flags |= FD_FLAG_OVERLAPPED; return FD_TYPE_DEFAULT; +} + +static struct async_queue *sock_queue_async(struct object *obj, struct async *async, int type, int count) +{ + struct sock *sock = (struct sock *)obj; + struct async_queue *q; + + assert( obj->ops == &sock_ops ); + + if ( !(sock->flags & WSA_FLAG_OVERLAPPED) ) + { + set_error ( STATUS_INVALID_HANDLE ); + return NULL; + } + + switch(type) + { + case ASYNC_TYPE_READ: + q = &sock->read_q; + break; + case ASYNC_TYPE_WRITE: + q = &sock->write_q; + break; + default: + set_error( STATUS_INVALID_PARAMETER ); + return NULL; + } + + if(async && !async->q) + async_insert(q, async); + + return q; } static void sock_destroy( struct object *obj )

April 12, 2002

PATCH: accept-deferred.diff (5 in series)

by Martin Wilck

PATCH: accept-deferred.diff If a connection request is deferred in a call to WSAAccept(), a subsequent accept()/WSAAccept() call must return the previously deferred connection rather than a new one. The current CVS implementation of WSAAccept is wrong in this respect. This patch fixes this. Furthermore, it includes a trivial implementation of WSAConnect(). Patch against: CVS 2002-04-12. Modified files: dlls/winsock: socket.c, ws2_32.spec include/wine: server_protocol.h server: protocol.def, sock.c, request.h, trace.c diff -ruNX ignore TMP/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- TMP/wine/dlls/winsock/socket.c Tue Apr 9 13:29:12 2002 +++ MW/wine/dlls/winsock/socket.c Fri Apr 12 14:50:50 2002 @@ -1140,6 +1140,19 @@ } /*********************************************************************** + * WSAConnect (WS2_32.30) + */ +int WINAPI WSAConnect ( SOCKET s, const struct WS_sockaddr* name, int namelen, + LPWSABUF lpCallerData, LPWSABUF lpCalleeData, + LPQOS lpSQOS, LPQOS lpGQOS ) +{ + if ( lpCallerData || lpCalleeData || lpSQOS || lpGQOS ) + WARN ("unsupported parameters!"); + return WS_connect ( s, name, namelen ); +} + + +/*********************************************************************** * getpeername (WS2_32.5) */ int WINAPI WS_getpeername(SOCKET s, struct WS_sockaddr *name, int *namelen) @@ -3420,7 +3433,7 @@ SOCKET cs; SOCKADDR src_addr, dst_addr; - TRACE("Socket %ui, sockaddr %p, addrlen %p, fnCondition %p, dwCallbackD ata %ld\n", + TRACE("Socket %u, sockaddr %p, addrlen %p, fnCondition %p, dwCallbackD ata %ld\n", s, addr, addrlen, lpfnCondition, dwCallbackData); @@ -3451,7 +3464,14 @@ addr = memcpy(addr, &src_addr, (*addrlen > size) ? size : *addrlen ); return cs; case CF_DEFER: - SetLastError(WSATRY_AGAIN); + SERVER_START_REQ ( set_socket_deferred ) + { + req->handle = s; + req->deferred = cs; + if ( !wine_server_call_err ( req ) ) + SetLastError ( WSATRY_AGAIN ); + } + SERVER_END_REQ; return SOCKET_ERROR; case CF_REJECT: WS_closesocket(cs); diff -ruNX ignore TMP/wine/dlls/winsock/ws2_32.spec MW/wine/dlls/winsock/ws2_32.spec --- TMP/wine/dlls/winsock/ws2_32.spec Mon Apr 8 10:56:59 2002 +++ MW/wine/dlls/winsock/ws2_32.spec Fri Apr 12 14:52:57 2002 @@ -42,7 +42,7 @@ 27 stub WSAAddressToStringA 28 stub WSAAddressToStringW 29 stdcall WSACloseEvent(long) WSACloseEvent -30 stub WSAConnect +30 stdcall WSAConnect(long ptr long ptr ptr ptr ptr) WSAConnect 31 stdcall WSACreateEvent () WSACreateEvent 32 stub WSADuplicateSocketA 33 stub WSADuplicateSocketW diff -ruNX ignore TMP/wine/include/wine/server_protocol.h MW/wine/include/wine/server_protocol.h --- TMP/wine/include/wine/server_protocol.h Mon Apr 8 10:56:59 2002 +++ MW/wine/include/wine/server_protocol.h Fri Apr 12 14:25:47 2002 @@ -1001,6 +1001,16 @@ struct reply_header __header; }; +struct set_socket_deferred_request +{ + struct request_header __header; + handle_t handle; + handle_t deferred; +}; +struct set_socket_deferred_reply +{ + struct reply_header __header; +}; struct alloc_console_request @@ -2758,6 +2768,7 @@ REQ_set_socket_event, REQ_get_socket_event, REQ_enable_socket_event, + REQ_set_socket_deferred, REQ_alloc_console, REQ_free_console, REQ_get_console_renderer_events, @@ -2919,6 +2930,7 @@ struct set_socket_event_request set_socket_event_request; struct get_socket_event_request get_socket_event_request; struct enable_socket_event_request enable_socket_event_request; + struct set_socket_deferred_request set_socket_deferred_request; struct alloc_console_request alloc_console_request; struct free_console_request free_console_request; struct get_console_renderer_events_request get_console_renderer_events_request; @@ -3078,6 +3090,7 @@ struct set_socket_event_reply set_socket_event_reply; struct get_socket_event_reply get_socket_event_reply; struct enable_socket_event_reply enable_socket_event_reply; + struct set_socket_deferred_reply set_socket_deferred_reply; struct alloc_console_reply alloc_console_reply; struct free_console_reply free_console_reply; struct get_console_renderer_events_reply get_console_renderer_events_reply; @@ -3183,6 +3196,6 @@ struct get_window_properties_reply get_window_properties_reply; }; -#define SERVER_PROTOCOL_VERSION 78 +#define SERVER_PROTOCOL_VERSION 79 #endif /* __WINE_WINE_SERVER_PROTOCOL_H */ diff -ruNX ignore TMP/wine/server/protocol.def MW/wine/server/protocol.def --- TMP/wine/server/protocol.def Mon Apr 8 10:56:59 2002 +++ MW/wine/server/protocol.def Fri Apr 12 14:18:38 2002 @@ -746,6 +746,10 @@ unsigned int cstate; /* status bits to clear */ @END +(a)REQ(set_socket_deferred) + handle_t handle; /* handle to the socket */ + handle_t deferred; /* handle to the socket for which accept() is deferred */ +(a)END /* Allocate a console (only used by a console renderer) */ @REQ(alloc_console) diff -ruNX ignore TMP/wine/server/request.h MW/wine/server/request.h --- TMP/wine/server/request.h Fri Apr 5 12:21:25 2002 +++ MW/wine/server/request.h Fri Apr 12 14:16:35 2002 @@ -152,6 +152,7 @@ DECL_HANDLER(set_socket_event); DECL_HANDLER(get_socket_event); DECL_HANDLER(enable_socket_event); +DECL_HANDLER(set_socket_deferred); DECL_HANDLER(alloc_console); DECL_HANDLER(free_console); DECL_HANDLER(get_console_renderer_events); @@ -312,6 +313,7 @@ (req_handler)req_set_socket_event, (req_handler)req_get_socket_event, (req_handler)req_enable_socket_event, + (req_handler)req_set_socket_deferred, (req_handler)req_alloc_console, (req_handler)req_free_console, (req_handler)req_get_console_renderer_events, diff -ruNX ignore TMP/wine/server/sock.c MW/wine/server/sock.c --- TMP/wine/server/sock.c Tue Apr 2 16:51:51 2002 +++ MW/wine/server/sock.c Fri Apr 12 14:24:35 2002 @@ -72,6 +72,7 @@ unsigned int message; /* message to send */ unsigned int wparam; /* message wparam (socket handle) */ int errors[FD_MAX_EVENTS]; /* event errors */ + handle_t deferred; /* socket that waits for a deferred accept */ struct async_queue read_q; /* Queue for asynchronous reads */ struct async_queue write_q; /* Queue for asynchronous writes */ }; @@ -361,6 +362,9 @@ /* FIXME: special socket shutdown stuff? */ + if ( sock->deferred ) + close_handle ( current->process, sock->deferred, NULL ); + if ( sock->flags & WSA_FLAG_OVERLAPPED ) { destroy_async_queue ( &sock->read_q ); @@ -394,18 +398,19 @@ sock->window = 0; sock->message = 0; sock->wparam = 0; - sock_reselect( sock ); - clear_error(); + sock->deferred = 0; if (sock->flags & WSA_FLAG_OVERLAPPED) { init_async_queue (&sock->read_q); init_async_queue (&sock->write_q); } + sock_reselect( sock ); + clear_error(); return &sock->obj; } /* accept a socket (creates a new fd) */ -static struct sock *accept_socket( handle_t handle ) +static struct sock *accept_socket( handle_t handle, handle_t *accept_handle, unsigned int access, int inherit ) { struct sock *acceptsock; struct sock *sock; @@ -417,42 +422,52 @@ GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops); if (!sock) return NULL; - /* Try to accept(2). We can't be safe that this an already connected socket - * or that accept() is allowed on it. In those cases we will get -1/errno - * return. - */ - slen = sizeof(saddr); - acceptfd = accept(sock->obj.fd,&saddr,&slen); - if (acceptfd==-1) { - sock_set_error(); - release_object( sock ); - return NULL; - } - if (!(acceptsock = alloc_object( &sock_ops, -1 ))) - { - release_object( sock ); - return NULL; - } + if ( sock->deferred ) { + acceptsock = (struct sock*)get_handle_obj( current->process, sock->deferred, + GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops ); + *accept_handle = sock->deferred; + sock->deferred = 0; + } else { + + /* Try to accept(2). We can't be safe that this an already connected socket + * or that accept() is allowed on it. In those cases we will get -1/errno + * return. + */ + slen = sizeof(saddr); + acceptfd = accept(sock->obj.fd,&saddr,&slen); + if (acceptfd==-1) { + sock_set_error(); + release_object( sock ); + return NULL; + } + if (!(acceptsock = alloc_object( &sock_ops, -1 ))) + { + release_object( sock ); + return NULL; + } - /* newly created socket gets the same properties of the listening socket */ - fcntl(acceptfd, F_SETFL, O_NONBLOCK); /* make socket nonblocking */ - acceptsock->obj.fd = acceptfd; - acceptsock->state = FD_WINE_CONNECTED|FD_READ|FD_WRITE; - if (sock->state & FD_WINE_NONBLOCKING) - acceptsock->state |= FD_WINE_NONBLOCKING; - acceptsock->mask = sock->mask; - acceptsock->hmask = 0; - acceptsock->pmask = 0; - acceptsock->event = NULL; - acceptsock->window = sock->window; - acceptsock->message = sock->message; - acceptsock->wparam = 0; - if (sock->event) 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 ); + /* newly created socket gets the same properties of the listening socket */ + fcntl(acceptfd, F_SETFL, O_NONBLOCK); /* make socket nonblocking */ + acceptsock->obj.fd = acceptfd; + acceptsock->state = FD_WINE_CONNECTED|FD_READ|FD_WRITE; + if (sock->state & FD_WINE_NONBLOCKING) + acceptsock->state |= FD_WINE_NONBLOCKING; + acceptsock->mask = sock->mask; + acceptsock->hmask = 0; + acceptsock->pmask = 0; + acceptsock->event = NULL; + acceptsock->window = sock->window; + acceptsock->message = sock->message; + acceptsock->wparam = 0; + if (sock->event) acceptsock->event = (struct event *)grab_object( sock->event ); + acceptsock->flags = sock->flags; + acceptsock->deferred = 0; + if ( acceptsock->flags & WSA_FLAG_OVERLAPPED ) + { + init_async_queue ( &acceptsock->read_q ); + init_async_queue ( &acceptsock->write_q ); + } + *accept_handle = alloc_handle( current->process, &acceptsock->obj, access, inherit ); } clear_error(); @@ -552,9 +567,8 @@ struct sock *sock; reply->handle = 0; - if ((sock = accept_socket( req->lhandle )) != NULL) + if ( (sock = accept_socket( req->lhandle, &reply->handle, req->access, req->inherit )) != NULL ) { - reply->handle = alloc_handle( current->process, &sock->obj, req->access, req->inherit ); sock->wparam = reply->handle; /* wparam for message is the socket handle */ sock_reselect( sock ); release_object( &sock->obj ); @@ -645,4 +659,27 @@ sock->state &= ~req->cstate; sock_reselect( sock ); release_object( &sock->obj ); +} + +DECL_HANDLER(set_socket_deferred) +{ + struct sock *sock; + + sock=(struct sock*)get_handle_obj( current->process,req->handle, + GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE,&sock_ops ); + if (!sock) + { + set_error ( WSAENOTSOCK ); + return; + } + sock->deferred = req->deferred; + /* duplicate_handle ( current->process, req->deferred, current->process, + GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE, TRUE, 0 ); */ + if ( !sock->deferred ) + { + release_object ( sock ); + set_error ( WSAENOTSOCK ); + return; + } + release_object ( sock ); } diff -ruNX ignore TMP/wine/server/trace.c MW/wine/server/trace.c --- TMP/wine/server/trace.c Mon Apr 8 10:56:59 2002 +++ MW/wine/server/trace.c Fri Apr 12 14:16:35 2002 @@ -943,6 +943,12 @@ fprintf( stderr, " cstate=%08x", req->cstate ); } +static void dump_set_socket_deferred_request( const struct set_socket_deferred_request *req ) +{ + fprintf( stderr, " handle=%d,", req->handle ); + fprintf( stderr, " deferred=%d", req->deferred ); +} + static void dump_alloc_console_request( const struct alloc_console_request *req ) { fprintf( stderr, " access=%08x,", req->access ); @@ -2215,6 +2221,7 @@ (dump_func)dump_set_socket_event_request, (dump_func)dump_get_socket_event_request, (dump_func)dump_enable_socket_event_request, + (dump_func)dump_set_socket_deferred_request, (dump_func)dump_alloc_console_request, (dump_func)dump_free_console_request, (dump_func)dump_get_console_renderer_events_request, @@ -2372,6 +2379,7 @@ (dump_func)0, (dump_func)dump_get_socket_event_reply, (dump_func)0, + (dump_func)0, (dump_func)dump_alloc_console_reply, (dump_func)0, (dump_func)dump_get_console_renderer_events_reply, @@ -2529,6 +2537,7 @@ "set_socket_event", "get_socket_event", "enable_socket_event", + "set_socket_deferred", "alloc_console", "free_console", "get_console_renderer_events",

April 12, 2002

Patch: async-file.diff (4 in series)

by Martin Wilck

Patch: async-file.diff Some improvements to the async IO API. - Need a "cleanup" method. - calling the "call_completion" method unconditionally in finish_async (introduced by me) was wrong, because the thread may never be in an alertable wait state -> call it only if user completion function is present. - We need two constant "ops" objects, one with and one without call_completion method (the event field may NOT be used to determine whether the completion must be called or not). - STATUS_CANCELLED is correct for cancelled requests ( corresponds to ERROR_OPERATION_ABORTED ). Modified files: dlls/kernel: comm.c files: file.c include: async.h server: async.c diff -ruNX ignore TMP/wine/dlls/kernel/comm.c MW/wine/dlls/kernel/comm.c --- TMP/wine/dlls/kernel/comm.c Fri Apr 12 11:47:48 2002 +++ MW/wine/dlls/kernel/comm.c Fri Apr 12 12:27:07 2002 @@ -99,14 +99,15 @@ static DWORD commio_get_async_status (const async_private *ovp); static DWORD commio_get_async_count (const async_private *ovp); static void commio_set_async_status (async_private *ovp, const DWORD status); -static void CALLBACK commio_call_completion_func (ULONG_PTR data); +static void commio_async_cleanup (async_private *ovp); static async_ops commio_async_ops = { commio_get_async_status, /* get_status */ commio_set_async_status, /* set_status */ commio_get_async_count, /* get_count */ - commio_call_completion_func /* call_completion */ + NULL, /* call_completion */ + commio_async_cleanup /* cleanup */ }; typedef struct async_commio @@ -131,9 +132,9 @@ return 0; } -static void CALLBACK commio_call_completion_func (ULONG_PTR data) +static void commio_async_cleanup (async_private *ovp) { - HeapFree(GetProcessHeap(), 0, (void*) data); + HeapFree(GetProcessHeap(), 0, ovp ); } /***********************************************************************/ diff -ruNX ignore TMP/wine/files/file.c MW/wine/files/file.c --- TMP/wine/files/file.c Fri Apr 12 11:59:51 2002 +++ MW/wine/files/file.c Fri Apr 12 12:28:22 2002 @@ -88,13 +88,24 @@ static DWORD fileio_get_async_count (const async_private *ovp); static void fileio_set_async_status (async_private *ovp, const DWORD status); static void CALLBACK fileio_call_completion_func (ULONG_PTR data); +static void fileio_async_cleanup (async_private *ovp); static async_ops fileio_async_ops = { fileio_get_async_status, /* get_status */ fileio_set_async_status, /* set_status */ fileio_get_async_count, /* get_count */ - fileio_call_completion_func /* call_completion */ + fileio_call_completion_func, /* call_completion */ + fileio_async_cleanup /* cleanup */ +}; + +static async_ops fileio_nocomp_async_ops = +{ + fileio_get_async_status, /* get_status */ + fileio_set_async_status, /* set_status */ + fileio_get_async_count, /* get_count */ + NULL, /* call_completion */ + fileio_async_cleanup /* cleanup */ }; typedef struct async_fileio @@ -128,12 +139,16 @@ async_fileio *ovp = (async_fileio*) data; TRACE ("data: %p\n", ovp); - if (ovp->completion_func) - ovp->completion_func(ovp->lpOverlapped->Internal, - ovp->lpOverlapped->InternalHigh, - ovp->lpOverlapped); + ovp->completion_func( ovp->lpOverlapped->Internal, + ovp->lpOverlapped->InternalHigh, + ovp->lpOverlapped ); + + fileio_async_cleanup ( &ovp->async ); +} - HeapFree(GetProcessHeap(), 0, ovp); +static void fileio_async_cleanup ( struct async_private *ovp ) +{ + HeapFree ( GetProcessHeap(), 0, ovp ); } /*********************************************************************** @@ -1479,6 +1494,8 @@ { async_fileio *ovp; int fd; + int flags; + enum fd_type type; TRACE("file %d to buf %p num %ld %p func %p\n", hFile, buffer, bytesToRead, overlapped, lpCompletionRoutine); @@ -1490,10 +1507,11 @@ return FALSE; } - fd = FILE_GetUnixHandle( hFile, GENERIC_READ ); - if(fd<0) + fd = FILE_GetUnixHandleType ( hFile, GENERIC_READ, &type, &flags); + if ( fd < 0 ) { - TRACE("Couldn't get FD\n"); + WARN ( "Couldn't get FD\n" ); + SetLastError ( ERROR_INVALID_PARAMETER ); return FALSE; } @@ -1502,11 +1520,10 @@ { TRACE("HeapAlloc Failed\n"); SetLastError(ERROR_NOT_ENOUGH_MEMORY); - close(fd); - return FALSE; + goto error; } - ovp->async.ops = &fileio_async_ops; + ovp->async.ops = ( lpCompletionRoutine ? &fileio_async_ops : &fileio_nocomp_async_ops ); ovp->async.handle = hFile; ovp->async.fd = fd; ovp->async.type = ASYNC_TYPE_READ; @@ -1518,6 +1535,11 @@ ovp->buffer = buffer; return !register_new_async (&ovp->async); + +error: + close (fd); + return FALSE; + } /*********************************************************************** @@ -1691,6 +1713,8 @@ { async_fileio *ovp; int fd; + int flags; + enum fd_type type; TRACE("file %d to buf %p num %ld %p func %p stub\n", hFile, buffer, bytesToWrite, overlapped, lpCompletionRoutine); @@ -1701,7 +1725,7 @@ return FALSE; } - fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); + fd = FILE_GetUnixHandleType ( hFile, GENERIC_WRITE, &type, &flags ); if ( fd < 0 ) { TRACE( "Couldn't get FD\n" ); @@ -1713,8 +1737,7 @@ { TRACE("HeapAlloc Failed\n"); SetLastError(ERROR_NOT_ENOUGH_MEMORY); - close (fd); - return FALSE; + goto error; } ovp->async.ops = &fileio_async_ops; @@ -1729,6 +1752,10 @@ ovp->completion_func = lpCompletionRoutine; return !register_new_async (&ovp->async); + +error: + close (fd); + return FALSE; } /*********************************************************************** diff -ruNX ignore TMP/wine/include/async.h MW/wine/include/async.h --- TMP/wine/include/async.h Fri Apr 12 11:47:48 2002 +++ MW/wine/include/async.h Fri Apr 12 12:25:30 2002 @@ -35,6 +35,7 @@ typedef DWORD (*async_get_status)(const struct async_private *ovp); typedef DWORD (*async_get_count)(const struct async_private *ovp); typedef void (*async_set_status)(struct async_private *ovp, const DWORD status); +typedef void (*async_cleanup)(struct async_private *ovp); typedef struct async_ops { @@ -42,6 +43,7 @@ async_set_status set_status; async_get_count get_count; async_call_completion_func call_completion; + async_cleanup cleanup; } async_ops; typedef struct async_private @@ -74,7 +76,10 @@ if( ovp->event != INVALID_HANDLE_VALUE ) NtSetEvent( ovp->event, NULL ); - QueueUserAPC( ovp->ops->call_completion, GetCurrentThread(), (ULONG_PTR)ovp ); + if ( ovp->ops->call_completion ) + QueueUserAPC( ovp->ops->call_completion, GetCurrentThread(), (ULONG_PTR)ovp ); + else + ovp->ops->cleanup ( ovp ); } inline static BOOL __register_async( async_private *ovp, const DWORD status ) @@ -92,7 +97,11 @@ } SERVER_END_REQ; - if ( ret ) ovp->ops->set_status ( ovp, GetLastError() ); + if ( ret ) { + SetLastError( RtlNtStatusToDosError(ret) ); + ovp->ops->set_status ( ovp, ret ); + } + if ( ovp->ops->get_status (ovp) != STATUS_PENDING ) finish_async (ovp); diff -ruNX ignore TMP/wine/server/async.c MW/wine/server/async.c --- TMP/wine/server/async.c Fri Apr 12 11:47:48 2002 +++ MW/wine/server/async.c Fri Apr 12 12:23:56 2002 @@ -71,7 +71,7 @@ { while(q->head) { - async_notify(q->head, STATUS_HANDLES_CLOSED); + async_notify(q->head, STATUS_CANCELLED); destroy_async(q->head); } }

April 12, 2002

PATCH: winemaker.diff (3 in series)

by Martin Wilck

PATCH: winemaker.diff (identical to: http://www.winehq.com/hypermail/wine-devel/2002/04/0187.html) Fix winemaker-generated references to dlls that have changed their names in configure.ac. Patch against: Wine CVS 2002-04-12 Modified Files: tools: winemaker diff -ruNX ignore TMP/wine/tools/winemaker MW/wine/tools/winemaker --- TMP/wine/tools/winemaker Tue Apr 9 13:19:57 2002 +++ MW/wine/tools/winemaker Tue Apr 9 13:29:27 2002 @@ -2732,14 +2732,14 @@ WINE_DLL_ROOT="/lib:/lib/dlls:/usr/lib:/usr/lib/dlls:/usr/local/lib:/usr/local/lib/dlls" fi fi -AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.so],[ - AC_MSG_ERROR([Could not find the Wine dlls (libntdll.so)]) +AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.dll.so],[ + AC_MSG_ERROR([Could not find the Wine dlls (libntdll.dll.so)]) ],[$WINE_DLL_ROOT]) -AC_PATH_LIBRARY(WINE_DLL_ROOT,[-lntdll],[$WINE_LIBRARY_PATH -lwine -lwine_unicode],[ - AC_MSG_ERROR([Could not link with the Wine dlls (libntdll.so)]) +AC_PATH_LIBRARY(WINE_DLL_ROOT,[-lntdll.dll],[$WINE_LIBRARY_PATH -lwine -lwine_unicode],[ + AC_MSG_ERROR([Could not link with the Wine dlls (libntdll.dll.so)]) ],[$WINE_DLL_ROOT]) -WINE_DLL_PATH="-L$WINE_DLL_ROOT" +WINE_DLL_PATH="-L$WINE_DLL_ROOT/wine" if test -n "$LD_PATH" then

April 12, 2002

PATCH: sock-fd-type.diff (2 in series)

by Martin Wilck

PATCH: sock-fd-type.diff Patch against: Wine CVS 2002-04-12 Test status: Compiles (no errors/warnings). Modified Files: dlls/winsock : socket.c Log message: Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> _get_sock_fd_type : New function, retrieve fd type and flags like FILE_GetUnixHandleType(). WSASendTo() /WSARecvFrom(): Use _get_sock_fd_type(). diff -ruNX ignore TMP/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- TMP/wine/dlls/winsock/socket.c Tue Apr 9 13:27:56 2002 +++ MW/wine/dlls/winsock/socket.c Tue Apr 9 13:28:08 2002 @@ -246,6 +246,13 @@ return fd; } +inline static int _get_sock_fd_type( SOCKET s, enum fd_type *type, int *flags ) +{ + int fd; + if (set_error( wine_server_handle_to_fd( s, GENERIC_READ, &fd, type, flags ) )) return -1; + return fd; +} + static void _enable_event(SOCKET s, unsigned int event, unsigned int sstate, unsigned int cstate) { @@ -1976,15 +1983,16 @@ LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) { - int i, n, fd, err = WSAENOTSOCK; + int i, n, fd, err = WSAENOTSOCK, flags; struct iovec* iovec; struct msghdr msghdr; - + enum fd_type type; + TRACE ("socket %04x, wsabuf %p, nbufs %ld, flags %ld, to %p, tolen %d, ovl %p, func %p\n", s, lpBuffers, dwBufferCount, dwFlags, to, tolen, lpOverlapped, lpCompletionRoutine); - fd = _get_sock_fd(s); + fd = _get_sock_fd_type( s, &type, &flags ); if ( fd == -1 ) goto error; @@ -3269,14 +3277,15 @@ struct iovec* iovec; struct msghdr msghdr; - int fd, i, length, err = WSAENOTSOCK; + int fd, i, length, err = WSAENOTSOCK, flags; + enum fd_type type; 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); - fd = _get_sock_fd(s); + fd = _get_sock_fd_type( s, &type, &flags ); if (fd == -1) {

April 12, 2002

PATCH: async-immediate.diff (1 in series)

by Martin Wilck

PATCH: async-immediate.diff (Resubmission of http://www.winehq.com/hypermail/wine-patches/2002/04/0021.html) 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(). The implementation in current CVS is wrong for 2 reasons: 1. The overlapped event is not set, nor the completion routine called, if immediate completion succeeds. This breaks apps that do not check for immediate success. 2. If there are async requests currently in the queue, immediate completion will bypass the request ordering. This will lead to data corruption on FIFO-type files. The patch fixes this. Patch against: Wine CVS 2002-04-12 Test status: Compiles (no errors/warnings). Tested for regular file IO (ok). The 2002-01-15 patch has been tested for 16-bit serial IO by Lawson Whitney (ok). Modified Files: files : file.c Log message: Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> GetOverlappedResult(): Return ERROR_IO_INCOMPLETE if IO still pending (MSDN docs) ReadFile() / WriteFile(): Use GetOverlappedResult() to check for immediate completion. diff -ruNX ignore TMP/wine/files/file.c MW/wine/files/file.c --- TMP/wine/files/file.c Tue Apr 9 13:20:25 2002 +++ MW/wine/files/file.c Tue Apr 9 13:25:25 2002 @@ -1395,7 +1395,8 @@ if(lpTransferred) *lpTransferred = lpOverlapped->InternalHigh; - SetLastError(lpOverlapped->Internal); + SetLastError ( lpOverlapped->Internal == STATUS_PENDING ? + ERROR_IO_INCOMPLETE : lpOverlapped->Internal ); return (r==WAIT_OBJECT_0); } @@ -1576,41 +1577,21 @@ SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } - - /* see if we can read some data already (this shouldn't block) */ - result = pread( unix_handle, buffer, bytesToRead, OVERLAPPED_OFFSET(overlapped) ); - if ((result < 0) && (errno == ESPIPE)) - result = read( unix_handle, buffer, bytesToRead ); - close(unix_handle); - - if(result<0) - { - if( (errno!=EAGAIN) && (errno!=EINTR) && - ((errno != EFAULT) || IsBadWritePtr( buffer, bytesToRead )) ) - { - FILE_SetDosError(); - return FALSE; - } - else - result = 0; - } - /* if we read enough to keep the app happy, then return now */ - if(result>=bytesToRead) - { - *bytesRead = result; - return TRUE; - } - - /* at last resort, do an overlapped read */ - overlapped->InternalHigh = result; + close(unix_handle); + overlapped->InternalHigh = 0; if(!FILE_ReadFileEx(hFile, buffer, bytesToRead, overlapped, NULL, overlapped->hEvent)) return FALSE; - /* fail on return, with ERROR_IO_PENDING */ - SetLastError(ERROR_IO_PENDING); - return FALSE; + if ( !GetOverlappedResult (hFile, overlapped, bytesRead, FALSE) ) + { + if ( GetLastError() == ERROR_IO_INCOMPLETE ) + SetLastError ( ERROR_IO_PENDING ); + return FALSE; + } + + return TRUE; } if (flags & FD_FLAG_TIMEOUT) { @@ -1790,43 +1771,20 @@ return FALSE; } - /* see if we can write some data already (this shouldn't block) */ - - result = pwrite( unix_handle, buffer, bytesToWrite, OVERLAPPED_OFFSET (overlapped) ); - if ((result < 0) && (errno == ESPIPE)) - result = write( unix_handle, buffer, bytesToWrite ); - close(unix_handle); + overlapped->InternalHigh = 0; - if(result<0) - { - if( (errno!=EAGAIN) && (errno!=EINTR) && - ((errno != EFAULT) || IsBadReadPtr( buffer, bytesToWrite )) ) - { - FILE_SetDosError(); - return FALSE; - } - else - result = 0; - } + if(!FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, NULL, overlapped->hEvent)) + return FALSE; - /* if we wrote enough to keep the app happy, then return now */ - if(result>=bytesToWrite) + if ( !GetOverlappedResult (hFile, overlapped, bytesWritten, FALSE) ) { - *bytesWritten = result; - return TRUE; - } - - /* at last resort, do an overlapped read */ - overlapped->Internal = STATUS_PENDING; - overlapped->InternalHigh = result; - - if(!FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, NULL, overlapped->hEvent)) + if ( GetLastError() == ERROR_IO_INCOMPLETE ) + SetLastError ( ERROR_IO_PENDING ); return FALSE; + } - /* fail on return, with ERROR_IO_PENDING */ - SetLastError(ERROR_IO_PENDING); - return FALSE; + return TRUE; } switch(type)

April 12, 2002

Patch series for async socket IO & winsock2

by Martin Wilck

Hi, I will soon start submitting this week's work on async sockets. As I said in yesterday's "good news/bad news" posting, this is work in progress and far from being complete. However, I strongly need feedback and perhaps some testing by adventurous people. Anybody out there with an app that uses overlapped socket IO ?? However, the more basic parts can hardly break things, and do represent an improvement against the current CVS version. Even the other parts probably don't break apps, but I have not carried out extensive regression testing so far. Since the full thing would be too big, I have splitted it into functional pieces that are easier to read. I will forward those parts that I consider sufficiently robust to wine-patches. Of course the back side of splitting the patches is that the later ones depend (at least some) of the others. I have indicated these dependencies in the headers. That's not beutiful but probably better than one big chunk. I will be extremely grateful for any feedback. Nice weekend, Martin PS: As I indicated in my last posting, there is a lot of work outstanding to make all of the winsock2 code consistent with this async IO implementation. I see strange things in socket.c anyway, e.g. the select() call that simply disregards all the wait mechanisms that are provided in other places in wine. If any of the original authors of this code read this message, I'd be really happy to get in contact with you!! -- 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

April 12, 2002

Re: Make dumping more robust

by Uwe Bonnes

>>>>> "juergen" == juergen schmied <juergen.schmied(a)debitel.net> writes: juergen> I just rewrote the dumping of pidl's because the dumping itself juergen> produces lots of relay/snoop messages. So I made it not call juergen> any other functions. Will send it soon. Nice to hear :-) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 12, 2002

Re: Make dumping more robust

by juergen.schmied＠debitel.net

I just rewrote the dumping of pidl's because the dumping itself produces lots of relay/snoop messages. So I made it not call any other functions. Will send it soon. juergen

April 12, 2002

Expect Trouble

by Shachar Shemesh

Hi list, I am sorry if this is a baisc question. I have not been able to find anything about it in the docs. I am trying to run a small program I wrote and compiled with VC6 on Windows. I am getting the following error: Invoking /usr/bin/wine.bin HebTest.exe ... Warning: loading builtin kernel32.dll, but native version already present. Expect trouble. Warning: loading builtin user32.dll, but native version already present. Expect trouble. wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ("debugger/winedbg 134661992 32") (2) Read the Wine Developers Guide on how to set up winedbg or another debugger Wine failed with return code 5 I get the same error whether I am using my own CVS compiled version, or the nightly CVS for debian SID. I get this error regardless of whether I am using fake windows or real windows. I even tried removing the user32.dll file (0 bytes) completely from C:\Windows\System of the fake windows. Attached is the output when running wine with --debugmsg +all, and the binary I am using to run this program (it is a debug build). It's a tiny program of my writing, so unless I unwittedly stole it from somewhere, you hereby have my permission to use the binary as you see fit. Sources are available upon request. Thanks Shachar

April 12, 2002

WM_WINHELP, was: Re: Handling of messages above WM_USER in pack_message

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> I don't know if this global approach is valid, but at least it helped >> me to get winhlp32 working called with WinHelpA from an >> application. In what other way can we cope with user defined messages >> and their related structures in inter-process SendMessage? Alexandre> We can't. User messages cannot pass data around, WinHelpA Alexandre> will need to do that differently. The best way to find out Alexandre> how is probably to watch winhlp32 with a message spy under Alexandre> Windows. On Win95 OSR2 with Spy++ I could only see the Winhelp Message, nothing else special. Searching the web, I could find several approaches. However I think none of the required infrastructure is completly in place with wine yet - Allocate Remote memory The sending process allocates memory in the remote process with VirtualAlloxEx and copies the the local structure to that remote memory with WriteProcessMemory. Then the local process sends the WM_WINHELP message with the remote handle. This seems cleanest to me, but VirtualAllocEx is not yet implemented for remote processed. - Usage of shared memory (probably only on Win9X). Do we yet have shared memory? As we go the NT-way, this is probably depreciated. - Usage of SHAllocEx Probably requires support in the remote application to lock the passed handle, which is not the case for winhlp32.exe I could also see the possibility to inform the message-packer about the need to pack the WinHelp structure when RegisterWindowMessage is called. What other possibilities do other people see? Help and ideas appreciated. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 12, 2002

Re: update to regression testing framework

by Alexandre Julliard

Paul Millar <paulm(a)astro.gla.ac.uk> writes: > Here's the rationale: when a test result is displayed (currently only on > failure or success in a todo block) the file name and line number are > included. If the test file is altered then any tests after the edit will > have different line numbers. This makes these tests look like new ones: an > undesirable behaviour but not too big an issue. Explicitly naming tests is > a way of making the test results line-number independent. I think it's much more useful to have line numbers, it makes it much easier to find the offending test. Most tests scripts will contain thousands of individual tests and you won't be able to come up with meaningful names for them anyway. For the same reason, I don't think displaying every successful test is really useful. Traces are a much better way to see what's going on IMO. -- Alexandre Julliard julliard(a)winehq.com

April 12, 2002

Re: NT Status vs. Dos Error code in async operations

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > What we'd need would consequently be a errno->NT status converter to > set the overlapped status correctly from the error reported by read or > write. file_set_error() in server/file.c should do what you want. You can't call the function from the client but you can simply copy the code. -- Alexandre Julliard julliard(a)winehq.com

April 12, 2002

Async IO on sockets: good news and bad news

by Martin Wilck

Hi, The good news is: I have the basic mechanism for async IO on sockets running. Requests can be scheduled and waited for, just like for regular files. The bad news is: This is not enough for sockets. Problems occur especially when sockets are closed, because the signalling of socket events uses a completely independent mechanism. This leads to all sorts of strange behaviour, mostly to data loss because "FD_CLOSE" is signalled prematurely. Sadly, this means for me: - The whole event signalling mechanism needs to be reworked so that it is consistent with overlapped IO. - Probably the async IO mechanism, too. It seems that it would be good to have a single IO queue where all events are handled, rather than several ones. Unlike now, also things like "peer closed socket" would be scheduled in that queue. Well I need to think more. Currently, I am not even sure how exactly it _should_ work. 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

April 11, 2002

Re: update to regression testing framework

by Tels

-----BEGIN PGP SIGNED MESSAGE----- Moin, On 11-Apr-02 Francois Gouget carved into stone: > On Thu, 11 Apr 2002, Paul Millar wrote: > [...] >> > -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); >> > +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= >> > 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); >> >> Here's the rationale: when a test result is displayed (currently only on >> failure or success in a todo block) the file name and line number are >> included. If the test file is altered then any tests after the edit will >> have different line numbers. This makes these tests look like new ones: >> an >> undesirable behaviour but not too big an issue. Explicitly naming tests >> is >> a way of making the test results line-number independent. > > Ok, so the goal is to make it possible to automatically analyze the > test results. I see you point then. > > [...] >> meaning) and they may appear at an arbitrary point. A test name always >> appears in the same line as the test result, producing lines like: >> >> tests/atom.pl:Checking GlobalAddAtom[AW](i) i < 0xc0000: Test succeeded >> >> IMHO, this is a lot cleaner than using trace messages, although there's >> still the potential redundancy between a test's name and its error >> message. > > Yes, seems cleaner than test messages but there is the problem of > redundancy between the 'name' and the error message. Also, it seems that > for your purposes all tests should use named_ok otherwise you will not > be able to identify all tests. This means modifying all tests, and/or > just having ok. No? Just a quick hint: The perl core test frame work already has dealed (probably) with problems like this. Check out the Test, Test::More and Test::Harness modules. Maybe you can re-use the work done there? Thanx in advance, Tels - -- "Why do you go so slowly? Do you think this is some kind of game?" PGP key available on http://bloodgate.com/tels.asc or via email. perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"' dynamically utilize value-added technologies -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPLXrMHcLPEOTuEwVAQHJXgf+K/UeFqq4jnCu3jqAVDN7Wy657APhmWsG ql3lhSqfjDYklE1Lvck0qzir0Eiz+9UycdbYswo+EX4OQB5NV2ut0DbRjWAhPqzI hnWh8iuC8q7RZQUbPWMLoJaZI/P+v5sVzpMcp3YGXAoa3JZfMcF7XW5LfT2/twMu XIFD5Kfly018SdJL1K1xxCjgt1zLUjVXjeYwhCj8KqJEX2tuo8rxKpk5wGD2z584 EGkjIqItXgyT5LJX2JXOGbmWsenUOeR3w1sXoOuJ+05A22eHibp5w1veWWvuL9Hr vXpnSxWW1lqi/0IZ3UxPK+3XbxtViC4us9qLSluUVbSrUmlVMDVY0w== =HC8H -----END PGP SIGNATURE-----

April 11, 2002

Re: update to regression testing framework

by Francois Gouget

On Thu, 11 Apr 2002, Paul Millar wrote: [...] > > -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); > > +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= > > 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); > > Here's the rationale: when a test result is displayed (currently only on > failure or success in a todo block) the file name and line number are > included. If the test file is altered then any tests after the edit will > have different line numbers. This makes these tests look like new ones: an > undesirable behaviour but not too big an issue. Explicitly naming tests is > a way of making the test results line-number independent. Ok, so the goal is to make it possible to automatically analyze the test results. I see you point then. [...] > meaning) and they may appear at an arbitrary point. A test name always > appears in the same line as the test result, producing lines like: > > tests/atom.pl:Checking GlobalAddAtom[AW](i) i < 0xc0000: Test succeeded > > IMHO, this is a lot cleaner than using trace messages, although there's > still the potential redundancy between a test's name and its error > message. Yes, seems cleaner than test messages but there is the problem of redundancy between the 'name' and the error message. Also, it seems that for your purposes all tests should use named_ok otherwise you will not be able to identify all tests. This means modifying all tests, and/or just having ok. No? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

April 11, 2002

Re: update to regression testing framework

by Paul Millar

On Wed, 10 Apr 2002, Francois Gouget wrote: > > o If you set WINETEST_CONTINUE_ON_FAIL environment variable to 1, "make > This looks like it is equivalent to make -k. Oops, didn't know about that one :) I'll remove the WINETEST_CONTINUE_ON_FAIL code ... > > o The commands "named_ok", "set_name" and "unset_name" now exist (in C > > and Perl). You can use these to specify a name for tests either > > individually (via named_ok) or for a region (via set_name and > > unset_name) > > I'm not too sure about these: > > -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); > +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= > 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); Here's the rationale: when a test result is displayed (currently only on failure or success in a todo block) the file name and line number are included. If the test file is altered then any tests after the edit will have different line numbers. This makes these tests look like new ones: an undesirable behaviour but not too big an issue. Explicitly naming tests is a way of making the test results line-number independent. > Did you know that you can also do: > > ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err), > "could not find atom $name, atom=$atom, err=$wine::err" ); > This seems pretty similar and works in perl and C. Yep. But I'd say there's a difference between an error message and a test name: both describe what the test checks for, but labelling a successful test by the error message seems a bit ugly to me. (btw, naming test works under both Perl and C too :) > +set_name( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); > for ($i = 0x0001; ($i <= 0xbfff); $i += 27) > { > ok( GlobalAddAtomA($i) && !defined($wine::err) ); > ok( GlobalAddAtomW($i) && !defined($wine::err) ); > } > +unset_name(); > > would be better as: > > named_tests( "Checking GlobalAddAtom[AW](i) i < 0xbffff") { > for ($i = 0x0001; ($i <= 0xbfff); $i += 27) > { > ok( GlobalAddAtomA($i) && !defined($wine::err) ); > ok( GlobalAddAtomW($i) && !defined($wine::err) ); > } > } Agreed. > But I am not sure it adds that much to: > > trace( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); > for ($i = 0x0001; ($i <= 0xbfff); $i += 27) > { > ok( GlobalAddAtomA($i) && !defined($wine::err) ); > ok( GlobalAddAtomW($i) && !defined($wine::err) ); > } You could use trace, but IMHO there's a difference between using trace and named_tests. Trace messages have arbitrary content (and so arbitrary meaning) and they may appear at an arbitrary point. A test name always appears in the same line as the test result, producing lines like: tests/atom.pl:Checking GlobalAddAtom[AW](i) i < 0xc0000: Test succeeded IMHO, this is a lot cleaner than using trace messages, although there's still the potential redundancy between a test's name and its error message. Thoughts? ---- Paul Millar

April 11, 2002

Re: Handling of messages above WM_USER in pack_message

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > I don't know if this global approach is valid, but at least it helped me to > get winhlp32 working called with WinHelpA from an application. In what other > way can we cope with user defined messages and their related structures in > inter-process SendMessage? We can't. User messages cannot pass data around, WinHelpA will need to do that differently. The best way to find out how is probably to watch winhlp32 with a message spy under Windows. -- Alexandre Julliard julliard(a)winehq.com

April 11, 2002

16-bit apps starting and stopping notification

by Andriy Palamarchuk

I found an issue for a hang of 16-bit application (www.formdocs.com) installer. The app registers with NotifyRegister16 callback function and looks like it hangs while waiting for completion of child process. The last part of relay trace is attached. NotifyRegister16 function of ToolHelp dll is used to register handler for following events: NFY_UNKNOWN NFY_LOADSEG NFY_FREESEG NFY_STARTDLL NFY_STARTTASK NFY_EXITTASK NFY_DELMODULE NFY_RIP NFY_TASKIN NFY_TASKOUT NFY_INCHAR NFY_OUTSTRING NFY_LOGERROR NFY_LOGPARAMERROR Note, this works for 16-bit applications only. These events also used by debuggers to debug 16-bit applications. Can somebody give me a hint how is better to approach implementation of NFY_EXITTASK, NFY_STARTTASK events generation? How important do you think is to implement this functionality, since it is for 16-bit apps only? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 10, 2002

Re: Wine & ActiveX?

by Andriy Palamarchuk

--- Mark Lehrer <mark(a)knm.org> wrote: > Is there a document that can help us > with debugging > procedures? Obviously running Visual Studio is not > an option... but > what is the best way to start looking at what may be > going wrong? See http://www.wihehq.com/trouble Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 10, 2002

RE: update to regression testing framework

by Geoffrey Hausheer

> -----Original Message----- > From: Paul Millar paulm(a)astro.gla.ac.uk > Subject: update to regression testing framework > o The commands "named_ok", "set_name" and "unset_name" now > exist (in C > and Perl). You can use these to specify a name for tests either > individually (via named_ok) or for a region (via set_name and > unset_name) > What is the benefit of this? The current framework supports 'ok(test,printf-style string)' which seems to be fine for debugging in general, and 'trace' to just print out general purpose information about what the test is doing. Thanks, .Geoff

April 10, 2002

Re: update to regression testing framework

by Francois Gouget

On Wed, 10 Apr 2002, Paul Millar wrote: > Hi, > > The attached patch changes the way the regression testing works slightly. > The default behaviour should be the same, but there's some optional > "enhancements": > > o If you set WINETEST_REPORT_SUCCESS environment variable to 1, > successful tests are reported as well as unsuccessful ones. I don't know if this is really useful but why not. > o If you set WINETEST_CONTINUE_ON_FAIL environment variable to 1, "make > test" will run all tests from all modules, rather than failing on the > first failing module. This looks like it is equivalent to make -k. > o The commands "named_ok", "set_name" and "unset_name" now exist (in C > and Perl). You can use these to specify a name for tests either > individually (via named_ok) or for a region (via set_name and > unset_name) I'm not too sure about these: -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); Did you know that you can also do: ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err), "could not find atom $name, atom=$atom, err=$wine::err" ); This seems pretty similar and works in perl and C. Also about the following: +set_name( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); for ($i = 0x0001; ($i <= 0xbfff); $i += 27) { ok( GlobalAddAtomA($i) && !defined($wine::err) ); ok( GlobalAddAtomW($i) && !defined($wine::err) ); } +unset_name(); would be better as: named_tests( "Checking GlobalAddAtom[AW](i) i < 0xbffff") { for ($i = 0x0001; ($i <= 0xbfff); $i += 27) { ok( GlobalAddAtomA($i) && !defined($wine::err) ); ok( GlobalAddAtomW($i) && !defined($wine::err) ); } } This way one would not accidentally forget to unset the name. But I am not sure it adds that much to: trace( "Checking GlobalAddAtom[AW](i) i < 0xbffff"); for ($i = 0x0001; ($i <= 0xbfff); $i += 27) { ok( GlobalAddAtomA($i) && !defined($wine::err) ); ok( GlobalAddAtomW($i) && !defined($wine::err) ); } Traces are not printed by default but will be if you run the test as: runtest -v ... instead of runtest -q ... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

April 10, 2002

update to regression testing framework

by Paul Millar

Hi, The attached patch changes the way the regression testing works slightly. The default behaviour should be the same, but there's some optional "enhancements": o If you set WINETEST_REPORT_SUCCESS environment variable to 1, successful tests are reported as well as unsuccessful ones. o If you set WINETEST_CONTINUE_ON_FAIL environment variable to 1, "make test" will run all tests from all modules, rather than failing on the first failing module. o The commands "named_ok", "set_name" and "unset_name" now exist (in C and Perl). You can use these to specify a name for tests either individually (via named_ok) or for a region (via set_name and unset_name) The patch changes both the C and Perl frameworks. I'm pretty sure the Perl is right but someone who actually knows Perl ought to check it :) The second patch illustrates these by changing dlls/kernel/tests/atom.pl and dlls/kernel/tests/directory.c (apologies to Alexandre & Dmitry if I got the test semantics wrong). HTH ---- Paul Millar ChangeLog: Adding test names and some optional behaviour.

April 10, 2002

Re: Wine & ActiveX?

by Uwe Bonnes

>>>>> "Mark" == Mark Lehrer <mark(a)knm.org> writes: Mark> Hello! Mark> We are trying to make one of our applications work under Wine on Mark> Red Hat 7.2. We have a lot of talent here in both Linux and Mark> Windows, but no Wine experts (yet!). Mark> Unfortunately it only gets as far as showing the splash screen Mark> before it freezes. Is there a document that can help us with Mark> debugging procedures? Obviously running Visual Studio is not an Mark> option... but what is the best way to start looking at what may be Mark> going wrong? It uses ActiveX so perhaps that is the trouble. We Mark> took out all of the DCOM stuff already. The first thing to try is to enable debugmsg, perhaps try with --debugmsg +relay. When the program hangs, you can see whether it loops or hangs in one function. There are about 100 debugchanels available. Learn about them in the .spec files and the source. Hope this is a first start. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 10, 2002

Wine & ActiveX?

by Mark Lehrer

Hello! We are trying to make one of our applications work under Wine on Red Hat 7.2. We have a lot of talent here in both Linux and Windows, but no Wine experts (yet!). Unfortunately it only gets as far as showing the splash screen before it freezes. Is there a document that can help us with debugging procedures? Obviously running Visual Studio is not an option... but what is the best way to start looking at what may be going wrong? It uses ActiveX so perhaps that is the trouble. We took out all of the DCOM stuff already. Thanks! Mark

April 10, 2002