- wine-devel - winehq.org

[RFC] Async I/O patch: server code + ReadFileEx()
by Martin Wilck 04 Dec '01

04 Dec '01

Hi, here is a patch that fixes some of the issues with the async IO implementation in Wine that we discussed previously. My work on this was delayed by other duties, sorry. To make matters worse, I'll be out of office for the next 4 weeks (vacation :-) THIS PATCH IS NOT FOR PRODUCTION USE. I am submitting it as a RFC to show the basic concepts I am aiming at. Most important is the server-side code (server/async.h, server/async.c) that demonstrates the basic mechanism I am suggesting. As an example, I recoded ReadFileEx() to use the new approach. Basic testing with disk file I/O works as expected. The code no longer messes up the order of requests. Please have a look at this code and tell me if you consider it a reasonable basis for further development. The patch is against today's (04/12/2001) CVS version. Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy diff -ruN -X diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Mon Dec 3 13:08:10 2001 +++ MW/wine/files/file.c Tue Dec 4 22:10:16 2001 @@ -57,6 +57,19 @@ static HANDLE dos_handles[DOS_TABLE_SIZE]; +typedef struct file_async_request { + int fd; + HANDLE request_handle; + LPOVERLAPPED ovl; + LPOVERLAPPED_COMPLETION_ROUTINE completion_func; + LPVOID buffer; + unsigned int count; + mode_t flags; +} file_async_request; + +/* A trick to avoid clash with S_IFMT */ +#define _FILE_ASYNC_CANSEEK S_IXOTH +#define FILE_ASYNC_CANSEEK(as_req) ((as_req)->flags & _FILE_ASYNC_CANSEEK) /*********************************************************************** * FILE_ConvertOFMode @@ -1256,6 +1269,231 @@ return FALSE; } +static void FILE_AsyncIoFinish (struct file_async_request* as) +{ + LPOVERLAPPED ovl = as->ovl; + + NtSetEvent (ovl->hEvent, NULL); + + /* This will dequeue the request in the server */ + CloseHandle (as->request_handle); + close (as->fd); + + HeapFree (GetProcessHeap(), 0, as); + SetLastError (ovl->Internal); /* FIXME: correct ?? */ +} + +/*********************************************************************** + * FILE_AsyncIoFinish (INTERNAL) + * + */ +static void CALLBACK FILE_AsyncIoCallCompletion (ULONG_PTR data) +{ + struct file_async_request *as = (struct file_async_request*) data; + LPOVERLAPPED ovl = as->ovl; + + TRACE ("as %p, ovl %p, func %p, status %lx, transferred %ld\n", + as, ovl, as->completion_func, ovl->Internal, ovl->InternalHigh); + + as->completion_func (ovl->Internal, ovl->InternalHigh, ovl); + + FILE_AsyncIoFinish (as); + +} + +/*********************************************************************** + * FILE_ReadFile_APC (INTERNAL) + * + */ +static void FILE_ReadFile_APC (struct file_async_request *as, int events) +{ + int r; + int already; + LPOVERLAPPED ovl = as->ovl; + + TRACE ("events: %x, request: %p\n", events, as); + + if (ovl->Internal != STATUS_PENDING) + { + ERR ("status is %lx, should be %x\n", ovl->Internal, STATUS_PENDING); + r = STATUS_UNSUCCESSFUL; + goto apc_end; + } + + if (events & (POLLHUP | POLLERR | POLLNVAL)) + { + TRACE ("poll error condition for fd %d in async request %p\n", as->fd, as); + r = STATUS_UNSUCCESSFUL; + goto apc_end; + } + + if (!events) + { + TRACE ("read timed out\n"); + r = STATUS_TIMEOUT; + goto apc_end; + } + + already = ovl->InternalHigh; + + if (FILE_ASYNC_CANSEEK (as)) + { + off_t ofs = already + ovl->Offset + ((off_t) ovl->OffsetHigh << 32); + r = pread (as->fd, as->buffer + already, as->count - already, ofs); + } + else + r = read (as->fd, as->buffer + already, as->count - already); + + if (r < 0) + { + int err = errno; + TRACE ("read returned errno %d\n", err); + r = (err == EAGAIN || err == EINTR ? STATUS_PENDING : STATUS_UNSUCCESSFUL); + goto apc_end; + } + + else if (!r) + { + r = STATUS_END_OF_FILE; + goto apc_end; + } + + TRACE ("read %d bytes, cumul: %d, requested: %d\n", r, already + r, as->count); + ovl->InternalHigh += r; + + /* FIXME: is this correct behaviour ? */ + /* If less then count (but > 0) bytes were read, we return success for FIFOs */ + /* For regular files, this should only happen at EOF */ + + if (ovl->InternalHigh >= as->count || !S_ISREG (as->flags)) + r = STATUS_SUCCESS; + else + r = STATUS_END_OF_FILE; + +apc_end: + + ovl->Internal = r; + + if (r == STATUS_PENDING) + { + + TRACE ("rescheduling request\n"); + SERVER_START_REQ (requeue_async_request) + { + req->handle = as->request_handle; + r = wine_server_call_err (req); + } + SERVER_END_REQ; + + if (r) + ovl->Internal = RtlNtStatusToDosError (r); + else + return; + } + + TRACE ("request finished, status: %x\n", r); + + if (as->completion_func) + QueueUserAPC (FILE_AsyncIoCallCompletion, GetCurrentThread(), (ULONG_PTR) as); + else + FILE_AsyncIoFinish (as); +} + +/*********************************************************************** + * FILE_ReadFileEx (INTERNAL) + */ +static BOOL FILE_ReadFileEx (HANDLE hFile, LPVOID buffer, DWORD bytesToRead, + LPOVERLAPPED overlapped, + LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) +{ + struct file_async_request *as; + int fd, r, err; + struct stat st; + + TRACE ("file %d to buf %p num %ld %p func %p\n", + hFile, buffer, bytesToRead, overlapped, lpCompletionRoutine); + + /* check that there is an overlapped struct with an event flag */ + if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) + { + TRACE ("Overlapped not specified or invalid event flag\n"); + err = ERROR_INVALID_PARAMETER; + goto out_err; + } + + fd = FILE_GetUnixHandle( hFile, GENERIC_READ ); + if(fd < 0) + { + TRACE ("Cannot get fd\n"); + err = ERROR_INVALID_HANDLE; + goto out_err; + } + + as = (struct file_async_request*) + HeapAlloc (GetProcessHeap(), 0, sizeof (struct file_async_request)); + + if(!as) + { + TRACE ("HeapAlloc Failed\n"); + err = ERROR_NOT_ENOUGH_MEMORY; + goto out_close; + } + + overlapped->InternalHigh = 0; + overlapped->Internal = STATUS_PENDING; + + as->fd = fd; + as->ovl = overlapped; + as->completion_func = lpCompletionRoutine; + as->buffer = buffer; + + if (fstat (fd, &st) == -1) + { + TRACE ("cannot fstat fd %d\n", fd); + err = ERROR_FILE_INVALID; + goto out_free; + } + + as->flags = st.st_mode & S_IFMT; + if (lseek (fd, 0, SEEK_CUR) != -1) + as->flags |= _FILE_ASYNC_CANSEEK; + + SERVER_START_REQ (create_async_request) + { + req->type = ASYNC_TYPE_READ; + req->io_handle = hFile; + req->count = as->count = bytesToRead; + req->func = FILE_ReadFile_APC; + req->data = as; + r = wine_server_call_err (req); + if (!r) + as->request_handle = reply->handle; + } + SERVER_END_REQ; + + if (r) + { + TRACE ("Couldn't create request: %lx\n", GetLastError()); + err = RtlNtStatusToDosError (r); + goto out_free; + } + + TRACE ("success\n"); + return TRUE; + +out_free: + HeapFree (GetProcessHeap(), 0, as); + +out_close: + close (fd); + +out_err: + SetLastError (err); + return FALSE; + +} + + /*********************************************************************** * FILE_AsyncReadService (INTERNAL) * @@ -1354,7 +1592,7 @@ /*********************************************************************** * FILE_ReadFileEx (INTERNAL) */ -static BOOL FILE_ReadFileEx(HANDLE hFile, LPVOID buffer, DWORD bytesToRead, +static BOOL FILE_ReadFileExOLD(HANDLE hFile, LPVOID buffer, DWORD bytesToRead, LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { @@ -1456,27 +1694,32 @@ } /* see if we can read some data already (this shouldn't block) */ - result = read( unix_handle, buffer, bytesToRead ); - close(unix_handle); - if(result<0) - { - FILE_SetDosError(); - return FALSE; - } +/* !! MW: commented out immediate reading for testing purposes (test overlapped IO) !! */ + + result = 0; + +/* result = read( unix_handle, buffer, bytesToRead ); */ +/* close(unix_handle); */ + +/* if(result<0) */ +/* { */ +/* FILE_SetDosError(); */ +/* return FALSE; */ +/* } */ /* if we read enough to keep the app happy, then return now */ - if(result>=bytesToRead) - { - *bytesRead = result; - return TRUE; - } +/* if(result>=bytesToRead) */ +/* { */ +/* *bytesRead = result; */ +/* return TRUE; */ +/* } */ /* at last resort, do an overlapped read */ overlapped->Internal = STATUS_PENDING; overlapped->InternalHigh = result; - if(!FILE_ReadFileEx(hFile, buffer, bytesToRead, overlapped, NULL)) + if(!FILE_ReadFileEx (hFile, buffer, bytesToRead, overlapped, NULL)) return FALSE; /* fail on return, with ERROR_IO_PENDING */ diff -ruN -X diffignore CVS/wine/server/async.c MW/wine/server/async.c --- CVS/wine/server/async.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/async.c Tue Dec 4 22:05:19 2001 @@ -3,20 +3,477 @@ * * Copyright (C) 1998 Alexandre Julliard * Copyright (C) 2000 Mike McCormack + * Copyright (C) 2001 Martin Wilck * */ #include "config.h" #include <assert.h> +#include <stdio.h> #include <string.h> #include <stdlib.h> #include <unistd.h> +#include <sys/poll.h> #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" +/* This is a wine server object only because we need a client handle for later reference */ +struct async_request +{ + struct object obj; + struct async_request *next; /* Linked list of requests */ + struct async_request *prev; + struct thread *thread; /* Thread or process that issued this request */ + struct object *io_obj; /* The object that represents the IO in the server */ + unsigned int events; /* Events this request is interested in */ + unsigned int flags; /* Request type, misc flags */ + struct timeout_user *timeout; /* For timeout requests */ + struct timeval tv; /* Time at which request times out */ + int count; /* Number of bytes to transfer, needed for setup */ + int result; /* Async IO result - FIXME: do we need this ? */ + async_io_handler_t func; /* Client handler function */ + void *data; /* Client handler data */ +}; + +static void async_request_dump (struct object *, int); +static void async_request_destroy (struct object *obj ); +static const struct object_ops async_request_ops = +{ + sizeof (struct async_request), /* size */ + async_request_dump, /* dump */ + no_add_queue, /* add_queue */ + NULL, /* remove_queue */ + NULL, /* signaled */ + NULL, /* satisfied */ + NULL, /* get_poll_events */ + NULL, /* poll_event */ + no_get_fd, /* get_fd */ + no_flush, /* flush */ + no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ + async_request_destroy /* destroy */ +}; + +static void +async_request_dump (struct object *obj, int verbose) +{ + struct async_request *r = (struct async_request*) obj; + + assert (obj->ops == &async_request_ops); + + fprintf (stderr, "async_request: io_obj: %p events: %x, flags: %x\n", + r->io_obj, r->events, r->flags); + if (!verbose) + return; + fprintf (stderr, " %s" + " func: %p, data: %p\n", + (r->timeout ? "with timeout\n" : ""), + r->func, r->data); +} + +struct async* +alloc_async (struct object *obj) +{ + struct async *async = NULL; + async = mem_alloc (sizeof (struct async)); + if (async) { + async->readers = async->writers = async->others = NULL; + async->flags = 0U; + async->wait.obj = obj; + async->poll_event = async_poll_event_1; + async->get_poll_events = async_get_poll_events_1; + async->setup_request = async_setup_request; + } + return async; +} + +static inline struct async_request** +get_async_queue (struct async* async, struct async_request* request) +{ + switch (ASYNC_REQUEST_TYPE (request)) + { + case ASYNC_TYPE_READ: + return &async->readers; + case ASYNC_TYPE_WRITE: + return &async->writers; + default: + return &async->others; + } +} + +static void +queue_async_request (struct object *obj, struct async* async, struct async_request* req) +{ + struct async_request **queue = get_async_queue (async, req); + int must_add = (! (async->readers || async->writers || async->others)); + + if (!(*queue)) + *queue = req->prev = req->next = req; + else + { + struct async_request *last = (*queue)->prev; + last->next = req; + req->next = *queue; + req->prev = last; + (*queue)->prev = req; + } + + if (must_add) + obj->ops->add_queue (obj, &async->wait); +} + +static void +dequeue_async_request (struct object* obj, struct async_request* req) +{ + struct async *async; + struct async_request **queue; + + obj->ops->get_async (obj, &async); + + if (!async) + { + fprintf (stderr, "dequeue_async_request: invalid IO object\n"); + goto do_req; + } + + queue = get_async_queue (async, req); + + if (!(*queue)) + { + fprintf (stderr, "dequeue_async_request: no queue\n"); + goto do_req; + } + + if (!(req->next && req->prev)) + { + fprintf (stderr, "dequeue_async_request: request isn't queued\n"); + goto do_req; + } + + if (req->next == req) /* One-element-list */ + { + if (*queue == req) + { + *queue = NULL; + + /* remove the IO object from poll wait queue if all request queues are empty */ + if (! (async->readers || async->writers || async->others)) + obj->ops->remove_queue (obj, &async->wait); + } + else /* One element lists must be queue heads */ + { + fprintf (stderr, "dequeue_async_request: invalid request\n"); + goto do_req; + } + } + else + { + req->next->prev = req->prev; + req->prev->next = req->next; + if (*queue == req) + *queue = req->next; + } + + /* The event set may have changed after we removed this request */ + set_select_events (obj, obj->ops->get_poll_events (obj)); + +do_req: + /* After handling the queues, carry out the necessary steps for this request */ + + if (req->timeout) + { + remove_timeout_user (req->timeout); + req->timeout = NULL; + } + + req->next = req->prev = NULL; + return; +} + +static void +async_request_destroy (struct object *obj ) +{ + struct async_request *r = (struct async_request*) obj; + struct object *io; + + assert (obj->ops == &async_request_ops); + + io = r->io_obj; + grab_object (io); + dequeue_async_request (io, r); + release_object (io); +} + +static inline int +queue_async_apc (struct async_request *request, int event) +{ + if (ASYNC_REQUEST_APC_QUEUED (request)) + return 0; + + request->flags |= _ASYNC_REQUEST_APC_QUEUED; + + if (request->timeout) /* Not a timeout */ + { + remove_timeout_user (request->timeout); + request->timeout = NULL; + } + + thread_queue_apc (request->thread, + NULL, /* no owner - don't dequeue other APCs */ + request->func, + APC_ASYNC, + 1, /* use system queue */ + 2, /* number of arguments */ + request->data, /* client data */ + event); + return 1; +} + +static void +async_timeout (void* private) +{ + struct async_request *r = (struct async_request*) private; + r->timeout = NULL; + queue_async_apc (r, 0); +} + +static void +async_queue_all (struct async_request* queue, int event) +{ + struct async_request* r; + + if (!queue) + return; + + r = queue; + + queue_async_apc (r, event); + for (r = r->next; r != queue; r = r->next) + queue_async_apc (r, event); +} + +static void +async_queue_all_matching (struct async_request* queue, int event) +{ + struct async_request* r; + + if (!queue) + return; + + r = queue; + if (r->events & event) + queue_async_apc (r, event); + for (r = r->next; r != queue; r = r->next) + if (r->events & event) + queue_async_apc (r, event); +} + +/* This function never dequeues anything. Requests are only + taken off the queue(s) if the client side signals they have finished. */ +/* This variant queues only the first reader / writer. */ +/* Other variations may follow that queue more than a single request at a time + for objects that support it. */ +/* Note that objects that implement async IO may use their own function instead, + which should provide similar functionality . */ +void +async_poll_event_1 (struct object* obj, int event) +{ + struct async *async; + struct async_request *request; + obj->ops->get_async (obj, &async); + + if (!async) + { + fprintf (stderr, "aync_poll_event: invalid object\n"); + return; + } + + if ((request = async->readers) && (event & POLLIN) && queue_async_apc (request, event)) + event &= ~POLLIN; /* FIXME: is this correct ? */ + + if ((request = async->writers) && (event & POLLOUT) && queue_async_apc (request, event)) + event &= ~POLLOUT; /* FIXME: is this correct ? */ + + async_queue_all_matching (async->others, event); + + /* Queue everything unconditionally if we got errors - client side must cancel the requests */ + if (event & (POLLHUP | POLLERR | POLLNVAL)) + { + async_queue_all (async->readers, event); + async_queue_all (async->writers, event); + async_queue_all (async->others, event); + } + + /* re-check the event list we listen to */ + set_select_events (obj, obj->ops->get_poll_events (obj)); + return; +} + +/* Requests that are already queued do not take part in polling anymore */ +/* This variant assumes only one reader / writer can receive events */ +/* Note that objects that implement async IO may use their own function instead, + which should provide similar functionality . */ +int +async_get_poll_events_1 (struct object* obj) +{ + struct async *as = NULL; + int ret = POLLHUP | POLLERR | POLLNVAL; /* catch errors */ + + obj->ops->get_async (obj, &as); + + if (!as) + return -1; + + if (as->readers && !ASYNC_REQUEST_APC_QUEUED(as->readers)) + ret |= POLLIN; + + if (as->writers && !ASYNC_REQUEST_APC_QUEUED(as->writers)) + ret |= POLLOUT; + + if (as->others) + { + struct async_request *r = as->others; + if (!ASYNC_REQUEST_APC_QUEUED(r)) + ret |= r->events; + for (r = r->next; r != as->others; r = r->next) + if (!ASYNC_REQUEST_APC_QUEUED(r)) + ret |= r->events; + } + + return ret; +} + +/* Default (dummy) setup function. Supports only read and write, and disables timeouts. */ +/* This will be overwritten e.g. by the serial port implementation. */ +int +async_setup_request (struct async* async, struct async_request* request) +{ + request->tv.tv_usec = request->tv.tv_sec = 0; + + request->events = 0; + switch (ASYNC_REQUEST_TYPE (request)) + { + case ASYNC_TYPE_READ: + request->events |= POLLIN; + break; + case ASYNC_TYPE_WRITE: + request->events |= POLLOUT; + break; + default: + fprintf (stderr, "async_setup_request: unsupported request type\n"); + return -1; + }; + return 0; +} + +static struct async_request* +alloc_async_request (struct object *obj) +{ + struct async_request* r = NULL; + r = alloc_object (&async_request_ops, -1); + if (r) + { + r->io_obj = obj; + r->thread = current; + r->prev = r->next = NULL; + r->timeout = NULL; + r->result = 0; + } + return r; +} + +DECL_HANDLER (create_async_request) +{ + struct object *obj; + struct async *async; + struct async_request *request; + int err = STATUS_INVALID_HANDLE; + + if (!(obj = get_handle_obj( current->process, req->io_handle, 0, NULL ))) + goto out; + + if ((err = obj->ops->get_async (obj, &async)) != STATUS_SUCCESS) + goto error; + + request = alloc_async_request (obj); + + if (!request) + { + err = STATUS_NO_MEMORY; + goto error; + } + + /* FIXME: flags other than type ? */ + request->flags = req->type & (~_ASYNC_REQUEST_APC_QUEUED & ASYNC_REQUEST_TYPE_MASK); + request->count = req->count; + request->func = req->func; + request->data = req->data; + + if (async->setup_request (async, request) < 0) + { + err = STATUS_UNSUCCESSFUL; + goto free; + } + + if (ASYNC_USES_TIMEOUT (async)) + request->timeout = add_timeout_user (&request->tv, async_timeout, request); + + queue_async_request (obj, async, request); + + reply->handle = alloc_handle (current->process, request, GENERIC_READ|GENERIC_WRITE, 0); + set_error (STATUS_SUCCESS); /* FIXME - is that necessary ?? */ + + release_object (request); + release_object (obj); /* FIXME: should we skip this release_object to prevent + the io-object to be freed while there are async requests around, + or should the destroy routine of the object handle that ?? */ + + return; + +free: + release_object (request); + +error: + release_object (obj); + +out: + reply->handle = 0; + set_error (err); + return; +} + +/* This is called when an APC does not finish */ +DECL_HANDLER(requeue_async_request) +{ + struct async_request *request; + int err = STATUS_INVALID_HANDLE; + struct object *io; + + if (!(request = (struct async_request*) get_handle_obj (current->process, req->handle, 0, NULL)) + || request->obj.ops != &async_request_ops + || !ASYNC_REQUEST_APC_QUEUED (request)) + goto out; + + io = request->io_obj; + grab_object (io); + + request->flags &= ~_ASYNC_REQUEST_APC_QUEUED; + set_select_events (io, io->ops->get_poll_events (io)); + + release_object (io); + err = STATUS_SUCCESS; + +out: + set_error (err); + return; +} + + +/* The current CVS code, in order not to break Wine */ DECL_HANDLER(create_async) { @@ -32,3 +489,4 @@ release_object(obj); } + diff -ruN -X diffignore CVS/wine/server/async.h MW/wine/server/async.h --- CVS/wine/server/async.h Thu Jan 1 01:00:00 1970 +++ MW/wine/server/async.h Tue Dec 4 16:19:54 2001 @@ -0,0 +1,48 @@ +/* + * Wine server async I/O support + * + * Copyright (C) 2001 Martin Wilck + */ + +#ifndef __WINE_SERVER_ASYNC_H +#define __WINE_SERVER_ASYNC_H + +#include "object.h" + +#define _ASYNC_USES_TIMEOUT 0x01U +#define ASYNC_USES_TIMEOUT(async) ((async)->flags & _ASYNC_USES_TIMEOUT) + +#define ASYNC_REQUEST_TYPE_MASK 0xffU +#define ASYNC_REQUEST_TYPE(req) ((req)->flags & ASYNC_REQUEST_TYPE_MASK) +#define _ASYNC_REQUEST_APC_QUEUED 0x100U +#define ASYNC_REQUEST_APC_QUEUED(req) ((req)->flags & _ASYNC_REQUEST_APC_QUEUED) + +struct async_request; +typedef int (*async_get_poll_events_t) (struct object*); +typedef void (*async_poll_event_t) (struct object*, int); +typedef int (*async_setup_request_t) (struct async*, struct async_request*); +typedef void (*async_io_handler_t) (void*, int); + +/* This struct contains information about async IO features + of a given I/O object (file, comm port, socket ...) */ +struct async +{ + struct async_request *readers; /* List of read requests */ + struct async_request *writers; /* List of write requests */ + struct async_request *others; /* List of requests that dont't read or write */ + unsigned int flags; /* Misc flags */ + struct wait_queue_entry wait; /* wait queue entry */ + async_poll_event_t poll_event; /* Function: react on poll event */ + async_get_poll_events_t get_poll_events; /* Function: get events to react on */ + async_setup_request_t setup_request; /* Function: Setup an event (timeout, events) at queue time */ +}; + +/* Default handlers, can be overwritten */ +int async_get_poll_events_1 (struct object*); +void async_poll_event_1 (struct object*, int); +int async_setup_request (struct async*, struct async_request*); + +/* Utility functions */ +struct async* alloc_async (struct object*); + +#endif /* #ifndef __WINE_SERVER_ASYNC_H */ diff -ruN -X diffignore CVS/wine/server/atom.c MW/wine/server/atom.c --- CVS/wine/server/atom.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/atom.c Mon Dec 3 13:09:03 2001 @@ -59,6 +59,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ atom_table_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/change.c MW/wine/server/change.c --- CVS/wine/server/change.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/change.c Mon Dec 3 13:09:03 2001 @@ -37,6 +37,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/console.c MW/wine/server/console.c --- CVS/wine/server/console.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/console.c Mon Dec 3 13:43:50 2001 @@ -40,6 +40,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ console_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ console_input_destroy /* destroy */ }; @@ -68,6 +69,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ console_input_events_destroy /* destroy */ }; @@ -108,6 +110,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ console_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ screen_buffer_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/debugger.c MW/wine/server/debugger.c --- CVS/wine/server/debugger.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/debugger.c Mon Dec 3 13:09:04 2001 @@ -58,6 +58,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ debug_event_destroy /* destroy */ }; @@ -78,6 +79,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ debug_ctx_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/device.c MW/wine/server/device.c --- CVS/wine/server/device.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/device.c Mon Dec 3 13:09:04 2001 @@ -44,6 +44,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ device_get_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/event.c MW/wine/server/event.c --- CVS/wine/server/event.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/event.c Mon Dec 3 13:09:04 2001 @@ -38,6 +38,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/file.c Tue Dec 4 17:57:22 2001 @@ -29,6 +29,7 @@ #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" struct file { @@ -39,6 +40,7 @@ unsigned int flags; /* flags (FILE_FLAG_*) */ unsigned int sharing; /* file sharing mode */ int drive_type; /* type of drive the file is on */ + struct async *async; /* Control structure for async IO */ }; #define NAME_HASH_SIZE 37 @@ -47,10 +49,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 *,int); 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 int file_get_async(struct object *,struct async **); static const struct object_ops file_ops = { @@ -61,10 +65,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 */ + file_get_async, /* get_async */ file_destroy /* destroy */ }; @@ -115,6 +120,7 @@ file->flags = attrs; file->sharing = sharing; file->drive_type = drive_type; + file->async = NULL; } return file; } @@ -247,11 +253,27 @@ struct file *file = (struct file *)obj; int events = 0; assert( obj->ops == &file_ops ); + + if (file->flags & FILE_FLAG_OVERLAPPED && file->async) + return async_get_poll_events_1 (obj); + if (file->access & GENERIC_READ) events |= POLLIN; if (file->access & GENERIC_WRITE) events |= POLLOUT; return events; } +static void file_poll_event(struct object *obj, int events) +{ + struct file *file = (struct file *)obj; + assert( obj->ops == &file_ops ); + + if (file->flags & FILE_FLAG_OVERLAPPED && file->async) + /* FIXME: Could we have non-async requests waiting for input also ? */ + async_poll_event_1 (obj, events); + else + default_poll_event (obj, events); +} + static int file_get_fd( struct object *obj ) { struct file *file = (struct file *)obj; @@ -307,7 +329,23 @@ 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 int file_get_async(struct object *obj,struct async **pasync) +{ + struct file *file = (struct file *)obj; + assert (obj->ops == &file_ops); + if (!file->async) + { + file->async = alloc_async (obj); + } + *pasync = file->async; + return (file->async ? 0 : STATUS_NO_MEMORY); } static void file_destroy( struct object *obj ) diff -ruN -X diffignore CVS/wine/server/handle.c MW/wine/server/handle.c --- CVS/wine/server/handle.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/handle.c Mon Dec 3 13:09:04 2001 @@ -92,6 +92,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ handle_table_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/mapping.c MW/wine/server/mapping.c --- CVS/wine/server/mapping.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/mapping.c Mon Dec 3 13:09:04 2001 @@ -51,6 +51,7 @@ mapping_get_fd, /* get_fd */ no_flush, /* flush */ mapping_get_info, /* get_file_info */ + no_get_async, /* get_async */ mapping_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/mutex.c MW/wine/server/mutex.c --- CVS/wine/server/mutex.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/mutex.c Mon Dec 3 13:09:04 2001 @@ -42,6 +42,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ mutex_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/named_pipe.c MW/wine/server/named_pipe.c --- CVS/wine/server/named_pipe.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/named_pipe.c Mon Dec 3 13:09:04 2001 @@ -80,6 +80,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ named_pipe_destroy /* destroy */ }; @@ -101,6 +102,7 @@ pipe_user_get_fd, /* get_fd */ no_flush, /* flush */ pipe_user_get_info, /* get_file_info */ + no_get_async, /* get_async */ pipe_user_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/object.c MW/wine/server/object.c --- CVS/wine/server/object.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/object.c Mon Dec 3 13:09:04 2001 @@ -269,6 +269,13 @@ return FD_TYPE_INVALID; } +int no_get_async(struct object *obj,struct async **as) +{ + if (as) + *as = NULL; + return STATUS_OBJECT_TYPE_MISMATCH; +} + void no_destroy( struct object *obj ) { } diff -ruN -X diffignore CVS/wine/server/object.h MW/wine/server/object.h --- CVS/wine/server/object.h Mon Dec 3 13:08:11 2001 +++ MW/wine/server/object.h Mon Dec 3 13:16:09 2001 @@ -48,6 +48,8 @@ int (*flush)(struct object *); /* get file information */ int (*get_file_info)(struct object *,struct get_file_info_reply *); + /* fill in object-type specific async information */ + int (*get_async)(struct object *,struct async **); /* destroy on refcount == 0 */ void (*destroy)(struct object *); }; @@ -90,6 +92,7 @@ extern int no_get_fd( struct object *obj ); extern int no_flush( struct object *obj ); extern int no_get_file_info( struct object *obj, struct get_file_info_reply *info ); +extern int no_get_async(struct object *,struct async **); extern void no_destroy( struct object *obj ); extern int default_poll_add_queue( struct object *obj, struct wait_queue_entry *entry ); extern void default_poll_remove_queue( struct object *obj, struct wait_queue_entry *entry ); diff -ruN -X diffignore CVS/wine/server/pipe.c MW/wine/server/pipe.c --- CVS/wine/server/pipe.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/pipe.c Mon Dec 3 13:09:04 2001 @@ -53,6 +53,7 @@ pipe_get_fd, /* get_fd */ no_flush, /* flush */ pipe_get_info, /* get_file_info */ + no_get_async, /* get_async */ pipe_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/process.c MW/wine/server/process.c --- CVS/wine/server/process.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/process.c Mon Dec 3 13:09:06 2001 @@ -53,6 +53,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ process_destroy /* destroy */ }; @@ -92,6 +93,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ startup_info_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Mon Dec 3 13:08:11 2001 +++ MW/wine/server/protocol.def Tue Dec 4 13:54:13 2001 @@ -1541,6 +1541,21 @@ #define ASYNC_TYPE_WRITE 0x02 #define ASYNC_TYPE_WAIT 0x03 +/* Schedule an ansync I/O request */ +@REQ(create_async_request) + handle_t io_handle; /* Handle to IO object that is capable of async IO */ + unsigned int type; /* READ / WRITE / WAIT */ + int count; /* Number of bytes to transfer, -1 if unknown */ + void* func; /* IO handler function */ + void* data; /* pointer to arbitrary data object, handled by func */ +@REPLY + handle_t handle; /* handle to request object for later use */ +@END + +/* Reschedule an unfinished async I/O request */ +@REQ(requeue_async_request) + handle_t handle; /* handle to the request object to be rescheduled */ +@END /* Create a named pipe */ @REQ(create_named_pipe) diff -ruN -X diffignore CVS/wine/server/queue.c MW/wine/server/queue.c --- CVS/wine/server/queue.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/queue.c Mon Dec 3 13:09:08 2001 @@ -112,6 +112,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ msg_queue_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/registry.c MW/wine/server/registry.c --- CVS/wine/server/registry.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/registry.c Mon Dec 3 13:09:09 2001 @@ -142,6 +142,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ key_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/request.c MW/wine/server/request.c --- CVS/wine/server/request.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/request.c Mon Dec 3 13:09:09 2001 @@ -66,6 +66,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ master_socket_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/request.h MW/wine/server/request.h --- CVS/wine/server/request.h Mon Dec 3 13:08:11 2001 +++ MW/wine/server/request.h Tue Dec 4 16:20:02 2001 @@ -210,6 +210,8 @@ DECL_HANDLER(get_serial_info); DECL_HANDLER(set_serial_info); DECL_HANDLER(create_async); +DECL_HANDLER(create_async_request); +DECL_HANDLER(requeue_async_request); DECL_HANDLER(create_named_pipe); DECL_HANDLER(open_named_pipe); DECL_HANDLER(connect_named_pipe); @@ -364,6 +366,8 @@ (req_handler)req_get_serial_info, (req_handler)req_set_serial_info, (req_handler)req_create_async, + (req_handler)req_create_async_request, + (req_handler)req_requeue_async_request, (req_handler)req_create_named_pipe, (req_handler)req_open_named_pipe, (req_handler)req_connect_named_pipe, diff -ruN -X diffignore CVS/wine/server/semaphore.c MW/wine/server/semaphore.c --- CVS/wine/server/semaphore.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/semaphore.c Mon Dec 3 13:09:09 2001 @@ -38,6 +38,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/serial.c MW/wine/server/serial.c --- CVS/wine/server/serial.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/serial.c Mon Dec 3 13:09:09 2001 @@ -74,6 +74,7 @@ serial_get_fd, /* get_fd */ no_flush, /* flush */ serial_get_info, /* get_file_info */ + no_get_async, /* get_async */ no_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/snapshot.c MW/wine/server/snapshot.c --- CVS/wine/server/snapshot.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/snapshot.c Mon Dec 3 13:09:09 2001 @@ -50,6 +50,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ snapshot_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/sock.c Mon Dec 3 13:09:09 2001 @@ -77,6 +77,7 @@ sock_get_fd, /* get_fd */ no_flush, /* flush */ sock_get_info, /* get_file_info */ + no_get_async, /* get_async */ sock_destroy /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/thread.c MW/wine/server/thread.c --- CVS/wine/server/thread.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/thread.c Mon Dec 3 13:09:09 2001 @@ -76,6 +76,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ destroy_thread /* destroy */ }; diff -ruN -X diffignore CVS/wine/server/timer.c MW/wine/server/timer.c --- CVS/wine/server/timer.c Mon Dec 3 13:08:11 2001 +++ MW/wine/server/timer.c Mon Dec 3 13:09:09 2001 @@ -45,6 +45,7 @@ no_get_fd, /* get_fd */ no_flush, /* flush */ no_get_file_info, /* get_file_info */ + no_get_async, /* get_async */ timer_destroy /* destroy */ };

1 0

thread safing dlls
by Michael Zayats 04 Dec '01

04 Dec '01

this might be off topic, but let's try: I have a dll that is not thread safe (i.e. has many global variables, about 500). I have the sources for the dll. The target is to make it thread safe. Moving all the variables to thread specific storage is very complicated. Making it thread safe on ansi C level is very, very complicated too. I guess that you thoroughly deal with PE format. Is there a way to play with executable sections, such that every thread will use it's own copy of the data? I know one guy, that claimed that he has achieved this with 20 lines of code by directly modifying smth in executable, he doesn't want to tell me what he has done :( I also heard of __attribute((section... in gcc that should do the work (I am generally talking about windoze platform only), can you explain me what does it do in gcc? thank you in advance, Michael Zayats

2 1

Re:[PATCH] Horrid wineoss hack
by Eric Pouech 03 Dec '01

03 Dec '01

this is not the correct fix. there are several problems in the OSS driver (at least I know 3 of them, but didn't have time to fix them all yet in a proper way) this is not correct either (it's just a workaround) A+ > I have found that since a few weeks my Eudora was hanging > with current Cvs when I tried to get a new message off the server. > This occurred exactly when it was trying to play a sound to > warn about the new message. > > I have found that playing any sound using PlaySound is > triggering the new problem. On my older computer, the problem > just does not exist. After investigation, the older computer has a > true sound card (a sound blaster) while the new has just a Via > chip on the mother board (via82cxx_audio) > > This is the reason : the Via wineoss driver seems to be buggy, > when a sound is finished, the available space never goes back > to the total available. > > This problem did not happen with versions of audio.c < 1.45, > where the Wine code has been made to rely on this feature. > > ChangeLog: > > * dlls/winmm/wineoss/audio.c > Works around a bug in Via wineoss driver > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Re: Win XP installation support?
by Hetz Ben-Hamo 03 Dec '01

03 Dec '01

Yes, that helps, could you commit it to the CVS please? Thanks, Hetz On Monday 03 December 2001 19:27 pm, you wrote: > At 05:57 PM 03/12/2001 +0200, you wrote: > >It doesn't patches currectly, got rejection (which is enclosed). > > Try with -l option > > Gerard

1 0

Re: Proposed solution for mouse capture problems
by Alexandre Julliard 03 Dec '01

03 Dec '01

Jukka Heinonen <jhei(a)iki.fi> writes: > 1. Function process_raw_mouse_message should only determine which > window was under mouse and resend message to that window as > a cooked message. Everything else (especially separating normal > messages from nonclient messages and handling mouse captures) > should be moved to process_cooked_mouse_message. Actually, > I fail to see why raw messages are needed at all, since function > SendInput could do this as well. No, processing raw messages requires sending messages to the app (mainly WM_NCHITTEST) and you cannot do this from anywhere. Also if you separate the window determination from the rest you'll have to send two WM_NCHITTEST for every message which is clearly wrong. Maybe what we should do is when the cooked message is rejected by the message filter it should be queued back as a raw message and processed again next time around. > 3. Supporting multi-threaded capture is actually the easiest part, > although it might be quite useless (Does any application really > require it?). When mouse button is pressed in capturing window, > process_cooked_mouse_message sets process-wide flag that states > that global capture is in effect. After that, either > process_raw_mouse_message or SendInput sees that this flag is > set and resends all mouse messages to capturing window until > button release message is received, which clears the flag. I'm not sure what you are trying to fix here. This should already work fine, X takes care of sending messages to the right thread when mouse is captured. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Win XP installation support?
by Gerard Patel 03 Dec '01

03 Dec '01

At 04:47 AM 03/12/2001 +0200, you wrote: >I thought about that too, but it's not - here is the line from my /etc/fstab > >/dev/hda5 /mnt/win vfat defaults 0 0 >/dev/hda3 /mnt/dosc vfat defaults 0 0 > Try to apply the following patch to wineconf : --- wineconf.orig Thu Jun 7 22:25:06 2001 +++ wineconf Mon Dec 3 08:40:42 2001 @@ -146,6 +146,7 @@ my(@FATD)=@::FatDrives; my(@wininis) = (); my ($winini); + my ($ThisDrive); if (!$::opt_windir && !$::opt_fast && !$::opt_thorough) { $::opt_thorough++; @@ -161,8 +162,7 @@ } elsif ($::opt_thorough) { if ($::opt_debug) { print STDERR "DEBUG: Num FATD = ", $#FATD+1, "\n"; } - foreach(@FATD) { - my $ThisDrive = shift(@FATD); + foreach $ThisDrive (@FATD) { my $MntPoint = $ThisDrive->[1]; push(@wininis, `find $MntPoint -iname win.ini -print`); }¨\ Gerard

1 0

Win XP installation support?
by Hetz Ben-Hamo 03 Dec '01

03 Dec '01

Hi, I have installed wine cvs and I have here on this machine Windows XP pro installed.. now - the partition is fat32 and I can access it with /mnt/win without any problem. However, the tools/wineinstall script simply doesn't recognize my windows partition: windows]$ ls -l win* -rwxrwxrwx 1 root root 256192 Aug 23 13:00 winhelp.exe -rwxrwxrwx 1 root root 266752 Aug 23 13:00 winhlp32.exe -rwxrwxrwx 1 root root 504 Dec 1 22:25 win.ini -rwxrwxrwx 1 root root 48680 Aug 23 15:00 winnt256.bmp -rwxrwxrwx 1 root root 48680 Aug 23 15:00 winnt.bmp [hetz@witch windows]$ pwd /mnt/win/windows Now - running tools/wineinstall gives me this: wine]$ tools/wineinstall WINE Installer v0.7 Warning !! wine binary (still) found, which may indicate a (conflicting) previous installation. You might want to abort and uninstall Wine first. I see that WINE has already been configured, so I'll skip that. Hmm, looks like WINE is already compiled. I'll skip that too, I guess. You aren't root, so I'll skip the make install. NOTE! To run Wine without installing, you must set the environment variable LD_LIBRARY_PATH to /home/hetz/wine:/home/hetz/wine/dlls in your logon scripts. Create local config file ~/.wine/config? (yes/no) yes Found existing /home/hetz/.wine/config, if you continue this file will be overwritten. Continue running wineinstall? (yes/no) yes Searching for an existing Windows installation... not found. (no matching /etc/fstab mount entry found) Windows was not found on your system, so I assume you want a Wine-only installation. Am I correct? (yes/no) No, it's not correct. Any suggestions? (sorry if the email doesn't belong to this list) Thanks, -- Hetz Ben Hamo

2 3

Re: Include only needed headers in programs/winhelp
by Francois Gouget 03 Dec '01

03 Dec '01

On Sun, 2 Dec 2001, James Juran wrote: > James Juran <jamesjuran(a)alumni.psu.edu> > Only include the necessary files to avoid conflicts in gethostname > prototypes between winsock.h and unistd.h 'unistd.h' does not exist on Windows. Since this is a Winelib application it would be good to try to make it compile on Windows too. So I would rather be in favor of removing the 'unistd.h' #include directive unless something prevents that. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

2 4

gethostname prototypes [was: Re: wine's winhelp doesn't compile]
by James Juran 02 Dec '01

02 Dec '01

[taken to wine-devel, thread originally started in newsgroup] gerard patel wrote: > > >james[1]%rpm -qf /usr/include/unistd.h > >glibc-devel-2.2.4-19 > > glibc-devel-2.2.2-4mdk > > >james[2]%grep gethostname /usr/include/unistd.h > >extern int gethostname (char *__name, size_t __len) __THROW; > > extern int gethostname (char *__name, socklen_t __len) __THROW; > > ./include/bits/types.h:typedef unsigned int __socklen_t; This could be a problem. According to the glibc CVS, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/include/unistd.h.diff?r1=…, the type of the 2nd argument changed from int to size_t on 2001/3/21. According to the CVS tags, this change was first released in glibc-2.2.3. We were able to work around this problem in programs/winhelp by not including winsock.h, but could this problem crop up anyplace else? It seems that it is currently impossible to include unistd.h and winsock.h on a machine with glibc >= 2.2.3. -- James Juran jamesjuran(a)alumni.psu.edu

2 1

Re: compatible DC/Bitmap fixes
by Ove Kaaven 02 Dec '01

02 Dec '01

On Sat, 1 Dec 2001, eric pouech wrote: > as Marcus reported, the console was only working in black & white > the cause of the error comes from the following flow > > 1/ GetDC (physical and/or display) > 2/ CreateCompatibleDC (on DC gotten from 1/) > 3/ CreateCompatibleBitmap (on DC gotten from 2/) What you *should* do is to call CreateCompatibleBitmap on the DC you got from GetDC. That's what all the Windows code I know of does. > the trouble is as follows : > - when a mem DC is created, its bits per pixel is always set to 1 Yes, that's documented Windows behaviour. You need to select a bitmap into it to change it. No Windows code expects otherwise.

1 0

DOS issue
by Johan Gill 01 Dec '01

01 Dec '01

Trying Monkey Island 1 & 2 with wine, I get very slow animation and a lot of err:module:DOSVM_Wait dosvm wait error=5. It seems to be wineserver related, so I'd rather not dig too deep without some feedback. There is a brief trace without any special flags at http://www.lysator.liu.se/~johane/monkey2_brief.txt. I ended the execution with Ctrl-C. A trace with +server,+module,+relay is available as http://www.lysator.liu.se/~johane/monkey2_zoom.txt. I've cut everything after the second occurence of the error. /Johan Gill, johane(a)lysator.liu.se

1 0

Re: Access Control Functions
by Mike McCormack 01 Dec '01

01 Dec '01

Hi Karl, > Everything works okay until we get to the access control functions. > advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a > stub. Did you try different -winver flags? it OpenProcessToken shouldn't be used in Win98.... That being said, it would be a very good thing to have a better security framework. Maybe we can even use it to integrate with samba-tng one day. i think you'd be looking to make a "token" object in the server. > I also am having trouble finding documentation on the make_requests tool. Well, run it after modifying server/protocol.def to propagate you changes to server/trace.c and include/wine/server.h. The format of the protocol.def file should be self explanatory... if i remember correctly, there are some small quirks like "void* xxx" works, but "void *xxx" doesn't. Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Access Control Functions
by Karl Bielefeldt 01 Dec '01

01 Dec '01

I am new to open source development and to the wine project so please forgive me for sounding like a newbie. I think wine is great and the key to the growth of Linux in the desktop market. I decided to begin my efforts by debugging the installation of MS Money 2001 (my wife's must-have MS program) on a completely non-windows box. This led to needing to install the msiexec installer (instmsia.exe, available from MS website). Everything works okay until we get to the access control functions. advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a stub. Now, as far as I can tell, the stubs default to the least restrictive set of permissions, which I believe is fine for our purposes. The problem comes when the program calls kernel32.CloseHandle on the non-existent handle that was returned by the OpenProcessToken stub. Somebody please stop me if there is an easier way of solving this problem. It looks like we at least need to create some sort of dummy handle that can be removed by kernel32.CloseHandle without causing an error. To do this we would need to add an open_process_token request handler to the wineserver (perhaps in a new file server/access.c). Another alternative would be to create an open_dummy_handle request handler in server/handle.c that could be used for any generic dummy handle. The advantage of the first method is that if someone decides to implement all the access control functions properly, the framework is already in place. Probably some combination of the two is best. I am willing to do the coding myself, but I'm unsure of the procedures for open source development. How do you decide what changes are to be made, how do you submit your changes, how do you make sure you don't undo what someone else did, and things like that? I also am having trouble finding documentation on the make_requests tool. Thanks for tolerating my newbieness. I'm looking forward to being able to start contributing to this great project. --Karl Bielefeldt kbielefe(a)hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

3 2

Re: Is there a good reason why we ...
by Alexandre Julliard 30 Nov '01

30 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > Is there a good reason why we have to specify the full correct path to a dll > in the dll overrides section if it isn't in the windows system? Because you can have multiple versions of the same dll in different directories, and we need a way of distinguishing them. For instance an app may include its own version of shell32 in its private directory, and you want to be able to switch this one to builtin without impacting other apps using the standard shell32. There may be better ways to provide this feature though, suggestions are welcome. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PROBLEM REPORT] Focus problem for mdi children
by Gerard Patel 30 Nov '01

30 Nov '01

At 09:35 PM 29/11/2001 -0800, you wrote: >*Doesn't this fix the problem in Word where if you have multiple >documents open and you switch between them, you can't use the menu bar >any longer?* Sorry, I don't know. I doubt it, since in mdi code it is stated that Word does not use MDI. Of course the comment has been here for a long time and could be obsolete, but I doubt that Ms could have switched Word to use MDI since they have obsoleted MDI since a long time. Gerard

1 0

Re: [PROBLEM REPORT] Focus problem for mdi children
by Michael Cardenas 30 Nov '01

30 Nov '01

*Doesn't this fix the problem in Word where if you have multiple documents open and you switch between them, you can't use the menu bar any longer?* ------------------------------------------------------------------------------- * From:* Alexandre Julliard (/ julliard(a)winehq.com/ <mailto:julliard@winehq.com?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E> ) *Date:* Wed Nov 07 2001 - 19:46:37 EST * ** Gerard Patel <gerard.patel(a)nerim.net <mailto:gerard.patel@nerim.net?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E>> writes: > Using this patch : > --- winpos.c.orig Wed Nov 7 10:41:32 2001 > +++ winpos.c Thu Nov 8 00:44:29 2001 > @@ -955,7 +955,20 @@ > ShowCaret(winpos->hwnd); > } > > - if (!(winpos->flags & SWP_NOACTIVATE)) SetActiveWindow( winpos->hwnd ); > + if (!(winpos->flags & SWP_NOACTIVATE)) > + { > + SetActiveWindow( winpos->hwnd ); > + if (!(wndPtr = WIN_FindWndPtr(winpos->hwnd))) return FALSE; > + > + /* child windows get WM_CHILDACTIVATE message */ > + if( (wndPtr->dwStyle & (WS_CHILD | WS_POPUP)) == WS_CHILD ) > + { > + WIN_ReleaseWndPtr(wndPtr); > + SendMessageA(winpos->hwnd, WM_CHILDACTIVATE, 0, 0L); > + } > + else > + WIN_ReleaseWndPtr(wndPtr); > + } > > /* And last, send the WM_WINDOWPOSCHANGED message */ > > > seems to fix the problem. It may be too simple though :-) No actually it's pretty much the right thing. I have applied a slightly simplified version of your patch, thanks for the report. -- Alexandre Julliard julliard(a)winehq.com <mailto:julliard@winehq.com?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%3C87wv129jiq.fsf@mail.wine.dyndns.org%3E> -- //------------------------------------------ Michael Cardenas Software Engineer Lindows.com, Inc. http://www.lindows.com 858-410-5950 619-972-8153 //------------------------------------------- --

1 0

Is there a good reason why we ...
by Bill Medland 29 Nov '01

29 Nov '01

I've just tripped over this again which reminded me to ask why we do it. Is there a good reason why we have to specify the full correct path to a dll in the dll overrides section if it isn't in the windows system? A program runs at some location on the path. It uses a dll which is in the same directory. I want explicitly to use a winelib builtin "dll" instead of it. I can't simply say "a4wwine"="builtin"; I have to use the full path. That would cause problems if the exe and dll moved. Is there a good reason for this behaviour? (i.e. would it be a waste of my time changing the dll override stuff?) Bill

1 0

FoxPro 5 Applications
by Rick Romero 29 Nov '01

29 Nov '01

Hello, I've been attempting to get Foxpro 5 applications running for a while now. Actually, I just download from cvs randomly, and see what happens. It's been a while, but I decided to try again in October. At that time, there was an OLE error, but the only other strange occurance was a 'locking' of the screen on a print preview. Since then, this 'locking' is the only issue (though I havn't yet attempted to print). The apps I'm trying are my own, basically just a form is called, the user puts in a date range, and a report is run. You can view the report in the print preview window, close the window, use the scroll button on the mouse to change pages, etc. BUT, if you click on the preview itself, and attempt to scroll down to the bottom of the page, a 'lockup' appears to happen. I've just been waiting around hoping for it to be fixed. Today, for giggles, I decided to run the whole Visual Foxpro development environment. It ran! (BTW, I'm trying to do this all with fake windows, and all I've added is the VFP 5 runtime) BUT, anytime I click in an edit Window, MDI interface, the program acts as if I'm holding the shift key down, and as I move my mouse, all the text gets highlighted. I can't 'turn it off', so if there wasn't any text there, it surely would appear locked. I've changed the config from the fake_windows, to point to my Win2k install, but the behavior is the same. I'm actually getting kind of excited now, because we're a small company, and all we run is Fox5 apps (SBT / Skyline -- well, and a couple Fox2.6 win), and Office 2k. If I can run the development environment in Linux, I can take a real look at using linux desktops, either directly, or via LTSP. I don't get any debug info when the 'shift' occurs, and I'm not sure how to dump enough information to see the 'shift keypress' happen (assuming I could fix the problem myself in a way that doesn't interfere with the programming standards..), can someone point me in the right direction? Thanks for your time. Rick Romero

1 0

Proposed solution for mouse capture problems
by Jukka Heinonen 29 Nov '01

29 Nov '01

Okay, here is my proposal about how to fix broken message handling when mouse capturing is in effect. I would like to get some comments so that I can see that I haven't missed anything essential and because I would like to know whether someone is already working on this... Proposal has three parts, but part number one is the most important one, other two parts just show what would need to be done to make capturing work like described in MSDN documentation. 1. Function process_raw_mouse_message should only determine which window was under mouse and resend message to that window as a cooked message. Everything else (especially separating normal messages from nonclient messages and handling mouse captures) should be moved to process_cooked_mouse_message. Actually, I fail to see why raw messages are needed at all, since function SendInput could do this as well. 2. When requesting queued messages from wineserver, the request should also include the window that is capturing mouse input in the current thread - or this could be stored in the wineserver. If there are queued cooked mouse messages, wineserver considers them as if all child windows of capturing window had the handle of the capturing window. This should prevent problems if application requests messages about a single window. 3. Supporting multi-threaded capture is actually the easiest part, although it might be quite useless (Does any application really require it?). When mouse button is pressed in capturing window, process_cooked_mouse_message sets process-wide flag that states that global capture is in effect. After that, either process_raw_mouse_message or SendInput sees that this flag is set and resends all mouse messages to capturing window until button release message is received, which clears the flag. Function process_cooked_mouse_message needs to eat these messages if target window was not capturing window anymore. Proper locking should make sure that no important messages are lost (mouse move events are not important; we might lose button release event, but only if capture has been stopped manually before that and in that case not delivering button release is likely the best thing to do). -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: [patch] Winsock fixes
by Ove Kaaven 29 Nov '01

29 Nov '01

On Wed, 28 Nov 2001, Paul Rupe wrote: > I have found two bugs in dlls/winsock/socket.c. One I posted about a > few days ago in wine.devel. WS_accept calls WS_getpeername but passes > it the Unix file descriptor rather than the Windows socket handle. A > simple one-line change takes care of that. That's Francois's fault, when he split out the sockaddr_xxx conversions. > The second problem is more subtle, and I'm not sure if my solution is > enough. In WINSOCK_DoAsyncEvent there is a loop that dispatches all > events currently available on the socket. The problem is the order, it > simply calls them in increasing order by FD_xxx values. Since FD_READ > is numerically smaller than FD_CONNECT, a socket that has both events > will fire the read event before the connect. When that happens, the app > gets a read event before it thinks it's connected and ignores it. > Ideally, the loop should post them in the order in which they occurred, > but does wine keep track of that? Instead, I changed the loop so that > it checks FD_CONNECT and FD_CLOSE before FD_READ and FD_WRITE. I'm not > sure if the order I chose is the optimal one, but the app I was testing > (Xnews) works every time now. It'd seem to me that FD_CLOSE should be dispatched last, not first... Anyway, now that Alexandre moved the window message queues away from the wine clients and into the wineserver, these event message dispatches could also be done in the wineserver (where the winsock events are generated), instead of using the service thread callback WINSOCK_DoAsyncEvent. Alexandre wants to phase out the service thread anyway, so he probably won't oppose this. Any volunteers for that?

1 0

New Idea
by Matt Q 29 Nov '01

29 Nov '01

I don't know if this is the right news group for this but what the heck... This is a new idea I had. It strikes me that it would be better if wine some how customised it's self to a single users software/configuration... I'd heard that sometimes when one thing is fixed it sometimes breaks another... This wouldn't be a problem if the thing that would hypothetically get broken wasn't installed on the end users machine... so theoretically if you had some way of sending a patch to an end user which corrected the problem at hand it would be good... so what if every time wine crashed it popped up a window and if the user wished it it would send it's very verbose out put to some kind of a bug reporting system (repository)... and in return search the repository for a patch for this particular problem... (using the verbose output).... there is a chance that the patch might break something else but in that case there is a chance that it might find another patch to fix the whole situation... they have a system like this under M$ Win and netscape except that they rely on periodic updates to take care of the problem... but who is to say that every computer is built the Same and has the Same sofware so that the Same super patch will fix every one's computer... Note 1... If M$ screws anyone on rights to this idea they can claim next logical step kind of like one step shopping... Note 2... Basically the only two weakness of the system would be One the inablility to match the output with a patch... but with a decent database program should that be problem? and Two having enough programers to right mini patches..... I'm writing from memory but I think there are 300 developers.... wouldn't that be enough..... just a thought though so take it with a grain of salt... p.s. what brought this to mind back when I was following the wine project much more closely, 2-3 years ago, when it was almost the only way to run windows programs under linux, I'd heard that many of the problems could be fixed by just a tweak here or there and mabey a few lines of code changed... still don't know much C so I doubt I'll be much help as a developer if you want to get back with me over this : ) ICQ# 135184436 turtleislow

1 0

Re: x11ddraw fix
by Glenn Schrader 28 Nov '01

28 Nov '01

Ove Kaaven wrote: > On Mon, 12 Nov 2001, geschrader wrote: > > Your reasoning makes sense but with your patch I get the following error: > > > > X Error of failed request: XF86DGADirectNotActivated > > Major opcode of failed request: 138 (XFree86-DGA) > > Minor opcode of failed request: 26 (XDGACreateColormap) > > Serial number of failed request: 3691 > > Current serial number in output stream: 3951 > > > > I'm not sure how to interpret this. Documentation for DGA seems to be > > pretty non-existant. Is this complaining that the CreateColormap failed > > because DGA wasn't activated or that DGA wasn't activated because > > of the colormap failure? > It's probably the former. I'm guessing that you need to create the > colormap on the same display that XDGAOpenFrameBuffer and XDGASetMode was > done on (those are currently done on thread_display(), you'll probably > have to change them too, then?) The two attached patches seem to do the job. Thanks for the hints. --- Glenn Schrader ------------------------------------------------------------------------ Index: dga2.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/dga2.c,v retrieving revision 1.5 diff -u -r1.5 dga2.c --- dga2.c 2001/09/11 00:32:33 1.5 +++ dga2.c 2001/11/20 22:13:32 @@ -102,7 +102,7 @@ { LPDDRAWI_DIRECTDRAW_LCL ddlocal = data->lpDD->lpExclusiveOwner; DWORD vram; - Display *display = thread_display(); + Display *display = gdi_display; data->ddRVal = DD_OK; if (data->dwModeIndex) { @@ -174,7 +174,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_CreatePalette(LPDDHAL_CREATEPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(display, DefaultScreen(display), dga_dev, AllocAll); if (data->lpColorTable) X11DRV_DDHAL_SetPalEntries(data->lpDDPalette->u1.dwReserved1, 0, 256, @@ -185,7 +185,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_Flip(LPDDHAL_FLIPDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if (data->lpSurfCurr == X11DRV_DD_Primary) { DWORD ofs = data->lpSurfCurr->lpGbl->fpVidMem - dga_mem.fpStart; TSXDGASetViewport(display, DefaultScreen(display), @@ -199,7 +199,7 @@ static DWORD PASCAL X11DRV_XF86DGA2_SetPalette(LPDDHAL_SETPALETTEDATA data) { - Display *display = thread_display(); + Display *display = gdi_display; if ((data->lpDDSurface == X11DRV_DD_Primary) && data->lpDDPalette && data->lpDDPalette->u1.dwReserved1) { TSXDGAInstallColormap(display, DefaultScreen(display), data->lpDDPalette->u1.dwReserved1); Index: x11ddraw.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11ddraw.c,v retrieving revision 1.12 diff -u -r1.12 x11ddraw.c --- x11ddraw.c 2001/08/27 19:04:18 1.12 +++ x11ddraw.c 2001/11/20 22:13:42 @@ -49,7 +49,7 @@ static LRESULT WINAPI GrabWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { - Display *display = thread_display(); + Display *display = gdi_display; if(message != X11DRV_DD_GrabMessage) return CallWindowProcA(X11DRV_DD_GrabOldProcedure, hWnd, message, wParam, lParam); @@ -81,7 +81,7 @@ if(grab) { Window window = X11DRV_get_whole_window(GetFocus()); if(window) - XSetInputFocus(thread_display(), window, RevertToParent, CurrentTime); + XSetInputFocus(gdi_display, window, RevertToParent, CurrentTime); } if(!X11DRV_DD_GrabMessage)

2 4

Re: PATCH: xterm support for wineconsole
by eric pouech 28 Nov '01

28 Nov '01

Marcus Meissner wrote: > > Hi, > > This patch adds a XTERM backend to wineconsole. > > Some problems: > - In full screen text applications (like IDA), the cursor shows sometimes > up in the wrong spot. > - Scrolling does not work yet (so winedbg doesn't really work). > - Uses config.h. I still have some questions... from a technical point of view, what didn't you use an ncurse (for example) lib to handle the TERM issues ? the old code you grabbed doesn't work correctly for all TERM configurations... rewriting everythind isn't the solution IMO from a more usage point of view, it seemed that TERM support for wineconsole was more intended for supporting an existing UNIX console (like when starting a command line tool and use the current TERM for interacting with it), which would mean in wineconsole case passing to wineconsole the handles of current TERM. furthermore, how to you plan to choose, when starting wineconsole, from the Win32 and the xterm backend ? in other words, I'm more in favor of : - Win32 backend for normal usage - reusing current UNIX console when run in TERM mode (and not xterm), and with the support of text mode lib (like ncurses) A+

2 2

(no subject)
by Ryan C. Stallings 28 Nov '01

28 Nov '01

Hello all, I am new to the wine scene and would like to try my hand at a little wine hacking. Are there any bugs out there that would be easy for a newbie to fix while letting me learn a bit about the inner workings of wine? I have read all the material about getting started developing, but I am just lacking a bit of direction on what to work on :) Thanks for your help, ryan

4 3

fix triggers crash
by Michael Stefaniuc 28 Nov '01

28 Nov '01

Hello! I found a bug in ImageList_Merge (the count of the images in the imagelist wasn't set) and the trivial fix Index: imagelist.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.43 diff -u -r1.43 imagelist.c --- imagelist.c 2001/09/10 23:09:04 1.43 +++ imagelist.c 2001/11/26 22:37:31 @@ -1918,6 +1918,7 @@ DeleteDC (hdcSrcImage); DeleteDC (hdcDstImage); + himlDst->cCurImage = 1; } return himlDst; =================================================================== triggers with FreeSolitaire (got it from tucows.com) following error (with crash): X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 19761 Current serial number in output stream: 19852 This happens with the cvs code from today and I'm pretty shure that it worked perfectly with the cvs code from two days before. And without the patch above the error dosn't get triggered. This seems strange because the error seems to occur in x11drv.StretchBlt and ImageList_Merge dosn't call StretchBlt. To reproduce the crash start FreeSolitaire with the patch above applied, select a solitaire game and start dragging a card around and wine will crash. With --debugmsg +relay it takes sometimes longer to trigger the bug, just release the card I try dragging an other card (i never needed to release the second card yet, wine crashed before). I've attached the last 1000 lines of relay output, hope that helps. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 1

Re: Another pack4 issue (fwd)
by Francois Gouget 27 Nov '01

27 Nov '01

On Thu, 22 Nov 2001, Dmitry Timoshkov wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > > After the recent patch sent by Dmitry Timoshkov I checked for other > > similar issues. AFAICS, at this time there is only one place where a > > pack4 is really necessary. > > Well, I don't know why you are so sure. My testing revealed the following > differences in structure sizes between Wine and Windows: Well, I had just performed a search on 'pshpck4.h' and checked that against Wine's headers to see whether there would be a difference. Your method seems much more thorough. I am a bit surprised that we have so many differences. We should see tons of crashes... (maybe that's good news) [...] > What is really fun, that usage of FILETIME instead of LARGE_INTEGER leads > to differences in size of structures. That's very strange. It would be good to understand why because this should not happen. diff -u cvs/hq/wine/dlls/advapi32/registry.c wine/dlls/advapi32/registry.c --- cvs/hq/wine/dlls/advapi32/registry.c Mon Jul 23 22:19:41 2001 +++ wine/dlls/advapi32/registry.c Thu Nov 22 17:52:05 2001 @@ -287,7 +287,7 @@ DWORD len = info->NameLength / sizeof(WCHAR); DWORD cls_len = info->ClassLength / sizeof(WCHAR); - if (ft) *ft = info->LastWriteTime; + if (ft) *ft = *(FILETIME *)&info->LastWriteTime; This cast should not be necessary. Both sides are FILETIMEs. --- cvs/hq/wine/dlls/ntdll/reg.c Thu Nov 8 16:15:30 2001 +++ wine/dlls/ntdll/reg.c Thu Nov 22 17:45:36 2001 @@ -161,9 +161,9 @@ WCHAR *class_ptr = (WCHAR *)((char *)name_ptr + name_size); int class_size = server_data_size(req) - sizeof(WCHAR) - name_size; int fixed_size; - FILETIME modif; + LARGE_INTEGER modif; - RtlSecondsSince1970ToTime( req->modif, &modif ); + RtlSecondsSince1970ToTime( req->modif, (FILETIME *)&modif ); Here I don't understant why you changed modif to a LARGE_INTEGER since RtlSecondsSince1970ToTime takes a FILETIME* switch(info_class) { diff -u cvs/hq/wine/include/commctrl.h wine/include/commctrl.h --- cvs/hq/wine/include/commctrl.h Wed Aug 8 17:37:12 2001 +++ wine/include/commctrl.h Thu Nov 22 16:50:13 2001 @@ -744,6 +744,8 @@ LPARAM lParam; INT iImage; INT iOrder; + UINT type; + LPVOID pvFilter; } HDITEMA, *LPHDITEMA; I don't see these two fields on Windows. Same thing for the W version. That's with the VC 6 headers. @@ -2959,9 +2958,11 @@ typedef struct { DWORD cb; - BYTE DeviceName[32]; - BYTE DeviceString[128]; + CHAR DeviceName[32]; + CHAR DeviceString[128]; DWORD StateFlags; + CHAR DeviceID[128]; + CHAR DeviceKey[128]; } DISPLAY_DEVICEA,*PDISPLAY_DEVICEA,*LPDISPLAY_DEVICEA; Hmm, no. It is 'BYTE' on Windows. And I don't see the two extra fields either. diff -u cvs/hq/wine/include/winnt.h wine/include/winnt.h --- cvs/hq/wine/include/winnt.h Mon Aug 13 00:51:56 2001 +++ wine/include/winnt.h Thu Nov 22 18:00:57 2001 @@ -396,8 +396,6 @@ typedef a *P##a, *LP##a #endif /*STRICT*/ - -#include "pshpack1.h" /* Defines */ /* Argument 1 passed to the DllEntryProc. */ @@ -576,6 +574,8 @@ DWORD Cr0NpxState; } FLOATING_SAVE_AREA, *PFLOATING_SAVE_AREA; +#define MAXIMUM_SUPPORTED_EXTENSION 512 + typedef struct _CONTEXT86 { DWORD ContextFlags; @@ -612,6 +612,8 @@ DWORD EFlags; DWORD Esp; DWORD SegSs; + + BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION]; } CONTEXT86; I don't have this field in CONTEXT86, but it is there in CONTEXT. It seems that it's our definition of CONTEXT which is wrong: typedef CONTEXT86 CONTEXT; @@ -2923,11 +2923,15 @@ WORD Reserved; } IMAGE_BOUND_FORWARDER_REF, *PIMAGE_BOUND_FORWARDER_REF; +#include "pshpack2.h" + typedef struct _IMAGE_BASE_RELOCATION { DWORD VirtualAddress; DWORD SizeOfBlock; +#ifdef __WINE__ WORD TypeOffset[1]; +#endif } IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION; Do we handle this correctly in the code? I.e. is there APIs where the application gives us a pointer to a struct without the field and we write to it? I wonder how this is supposed to work. +#include "pshpack4.h" typedef struct _LUID_AND_ATTRIBUTES { LUID Luid; DWORD Attributes; } LUID_AND_ATTRIBUTES; +#include "poppack.h" Is this really necessary? LUID is 8 bytes so the DWORD should be aligned just fine with or without the pack4... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

3 4

SetActiveWindow problem
by bperkins＠netspace.org 27 Nov '01

27 Nov '01

Sorry, I'm new to wine hacking, so bear with me. I was playing around a bit the other day trying to see if the tahni deskmate worked at all. I tried to run the installer (tahnisetup.exe available at tahni.com). It would run, and then crash with a stack overflow. I've attached the sequence in a backtrace that was repeated many times at the bottom. It's wine-20011108, BTW. Since I don't have the source to tahnisetup it made things a bit tricky to decipher. My guess was(is) that the program is trying to the window as active, which sends a message to the program. It sees that it's not active, so it again tries to set it as be active, which eventually causes a stack overflow. My awful hack was to just put a sanity counter in SetActiveWindow and return true after being called a certain number of times. This seems to work, as in it causes to program to get farther (it gets stuck on something else). Presumably one could check if it was being called recursively. I realize that this isn't really useful info, but I was curious to see if I was right about this, or if anyone had an insight. Am I right or did I just get lucky with the hack? 25246 0x0040266f (tahnisetup.exe..text+0x166f in E:\tahnisetup.exe) (ebp=437e6444) 25247 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6468) 25248 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6498) 25249 0x407c95ca (CallWindowProcA+0x4a(func=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2623] in libuser32.so) (ebp=437e64cc) 25250 0x4097b54c (FILEDLG_CallWindowProc+0x54(lfs=0x40400dbc, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:294] in libcomdlg32.so) (ebp=437e64f4) 25251 0x4097d944 (FileOpenDlgProc+0x78(hWnd=0x1002f, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:1440] in libcomdlg32.so) (ebp=437e651c) 25252 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6540) 25253 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6570) 25254 0x407c91f4 (WINPROC_CallProc32WTo32A+0x80(func=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2435] in libuser32.so) (ebp=437e6598) 25255 0x407c972b (CallWindowProcW+0xab(func=0x430c0984, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2675] in libuser32.so) (ebp=437e65cc) 25256 0x4079f744 (DefDlgProcW+0x48(hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [defdlg.c:389] in libuser32.so) (ebp=437e65f8) 25257 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e661c) 25258 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e664c) 25259 0x407c9152 (WINPROC_CallProc32ATo32W+0x7e(func=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2412] in libuser32.so) (ebp=437e6674) 25260 0x407c9647 (CallWindowProcA+0xc7(func=0x430c0259, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2643] in libuser32.so) (ebp=437e66a8) 25261 0x4076957e (call_window_proc+0xf2(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, unicode=0x0) [message.c:1146] in libuser32.so) (ebp=437e6704) 25262 0x4076a1af (SendMessageTimeoutA+0xdf(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, flags=0x0, timeout=0xffffffff, res_ptr=0x437e6788) [message.c:1577] in libuser32.so) (ebp=437e6764) 25263 0x4076a317 (SendMessageA+0x37(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026) [message.c:1622] in libuser32.so) (ebp=437e6798) 25264 0x407c2e92 (WINPOS_SetActiveWindow+0x196(hWnd=0x10026, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in libuser32.so) (ebp=437e67f0) 25265 0x407c229a (SetForegroundWindow+0x7a(hwnd=0x10026) [winpos.c:781] in libuser32.so) (ebp=437e680c) -- "Only CmdrTaco can save us now" -- The Register Brian Perkins bperkins(a)netspace.org

1 0

winedbg error
by Dave Hawkes 26 Nov '01

26 Nov '01

Hi all, I keep getting an assertion in winedbg, before I try and find out the cause does anyone know the possible reason for this? winedbg: types.c:573: DEBUG_CopyFieldList: Assertion 'dt->type == dt2->type && ((dt->type == DT_STRUCT) || (dt->type == DT_ENUM))' failed. It looks like its an issue with parsing the debug info, but the windows application debugs just fine with MS Developer Studio 6. Thanks, Dave Hawkes

3 10

ITypeInfo_fnGetContainingTypeLib
by lawson_whitney＠juno.com 25 Nov '01

25 Nov '01

Good day! Anyone like to take a swat at this? I don't normally shy from a page fault, but frankly, ICOM confuses me. Anyway, maybe Ove can spot it in a second. If I have to do it it may take weeks. Backtrace attached. Wineconsole seems to be working nicely, as long as the resolution is good and high. I wanted to include a typelib trace, but that crashes at an earlier spot. I haven't really looked at that one yet; I can send it along if anyone is interested. At least Wine is starting to get its teeth into InstallSh**** and its confounded IKernel.exe. Regards Lawson ---oof---

3 5

Re: Crashing menus, event handling broken?
by Alexandre Julliard 25 Nov '01

25 Nov '01

Jukka Heinonen <jhei(a)iki.fi> writes: > The reason for this is that raw hardware messages get processed > before menu event loop starts. Raw event processing turns raw events > into cooked events and because menu event loop has not started yet, > game window is not capturing events and thus clicks on menu bar > are turned into nonclient messages. These cooked messages are > put back into message queue. Raw messages are not supposed to get processed while there is a cooked message in the queue. Is the app filtering messages in GetMessage? Could you please do a +server trace showing the problem? -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: ttydrv fix (adds missing ShowWindow function)
by lawson_whitney＠juno.com 25 Nov '01

25 Nov '01

On Thu, 22 Nov 2001, Eric Laforest wrote: > tydrv/ttydrv.spec > =================================================================== > RCS file: /cvsroot/winex/wine/dlls/ttydrv/ttydrv.spec,v > retrieving revision 1.1.1.8 > diff -r1.1.1.8 ttydrv.spec > 71a72 > > @ cdecl ShowWindow(long long) TTYDRV_ShowWindow > Index: dlls/ttydrv/wnd.c > =================================================================== > RCS file: /cvsroot/winex/wine/dlls/ttydrv/wnd.c,v > retrieving revision 1.1.1.10 > diff -r1.1.1.10 wnd.c > 648a649,809 > > I think it is worth reading <wine>/README all the way to the end, where you will see: If you add something, or fix a bug, please send a patch ('diff -u' format preferred) to julliard(a)winehq.com or to the wine-patches(a)winehq.com mailing list for inclusion in the next release. -- Alexandre Julliard julliard(a)winehq.com Is it asking too much to use diff -u? Would you like to get patches from all over the world against who knows which version of wine in random formats? I think -u is the only format suitable for an open-source project. Regards, Lawson ---oof---

1 1

Re: wineconsole compile error
by Gerard Patel 24 Nov '01

24 Nov '01

At 06:59 PM 24/11/2001 +0100, you wrote: >make[1]: Entre dans le répertoire `/home/wine/programs/wineconsole' >gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DUNICODE -D_REENTRANT -I/usr/X11R6/include -o >dialog.o dialog.c >dialog.c: In function `WCUSER_GetProperties': >dialog.c:492: structure has no member named `u' <snip> Yes, me too. Does the patch posted on Wine-patches by Chris Green not fix it for you ? Gerard

3 2

Re: mmsystem should be loaded at startup
by eric pouech 24 Nov '01

24 Nov '01

Joshua Thielen wrote: > > Note: I'm not sure if I should have called ExitProcess if mmsystem.dll > can't be loaded not needed, if it couldn't be loaded, then no need to free it > and if I needed to call FreeLibrary. I just took the > LoadLibrary("user32") as an example. well, error reporting for 16 bit DLL is a bit different (see below) > + if(!(mmsystem = LoadLibrary16("mmsystem.dll"))) the correct test should be > + if((mmsystem = LoadLibrary16("mmsystem.dll")) < 32) (the other values (< 32) are the error codes) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

mmsystem should be loaded at startup
by Joshua Thielen 24 Nov '01

24 Nov '01

Hello everybody, Finale expects mmsystem to be present without having to call LoadLibrary on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm extensions are available. I checked out windows 95, and it has mmsystem and winmm loaded when no apps are runing besides the desktop / explorer. This patch links wine with winmm andmakes winmm load mmsystem on init. Finale gets by this ok now. I don't know if this the correct approach, though. Could someone (Eric or Alexandre?) please take a look at it before I send it to wine-patches? TIA, Josh Thielen Index: wine/miscemu/wine.spec =================================================================== RCS file: /home/wine/wine/miscemu/wine.spec,v retrieving revision 1.3 diff -u -r1.3 wine.spec --- wine/miscemu/wine.spec 2000/12/15 03:38:11 1.3 +++ wine/miscemu/wine.spec 2001/11/23 19:11:47 @@ -4,3 +4,4 @@ init wine_initial_task import ntdll.dll +import winmm.dll Index: wine/dlls/winmm/mmsystem.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.46 diff -u -r1.46 mmsystem.c --- wine/dlls/winmm/mmsystem.c 2001/11/13 21:58:32 1.46 +++ wine/dlls/winmm/mmsystem.c 2001/11/23 19:11:59 @@ -114,6 +114,7 @@ */ BOOL WINAPI WINMM_LibMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID fImpLoad) { + HINSTANCE16 mmsys16; TRACE("0x%x 0x%lx %p\n", hInstDLL, fdwReason, fImpLoad); switch (fdwReason) { @@ -124,9 +125,15 @@ MULTIMEDIA_DeleteIData(); return FALSE; } + mmsys16 = LoadLibrary16("mmsystem.dll"); + if (!mmsys16) { + ERR("Could not load sibling mmsystem.dll\n"); + return FALSE; + } break; case DLL_PROCESS_DETACH: MULTIMEDIA_DeleteIData(); + if(mmsys16) FreeLibrary16(mmsys16); break; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: @@ -2549,7 +2556,7 @@ TRACE("(%d, %p, %d);\n", uDeviceID, lpCaps, uSize); if ((wmld = MMDRV_Get(uDeviceID, MMDRV_MIDIIN, TRUE)) == NULL) - return MMSYSERR_INVALHANDLE; + return MMSYSERR_BADDEVICEID; return MMDRV_Message(wmld, MIDM_GETDEVCAPS, (DWORD)lpCaps, uSize, TRUE); }

3 3

Re: mmsystem should be loaded at startup
by Alexandre Julliard 24 Nov '01

24 Nov '01

Joshua Thielen <thielen(a)netprince.net> writes: > Finale expects mmsystem to be present without having to call LoadLibrary > on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm > extensions are available. I checked out windows 95, and it has mmsystem > and winmm loaded when no apps are runing besides the desktop / > explorer. This patch links wine with winmm andmakes winmm load mmsystem > on init. Finale gets by this ok now. I don't know if this the correct > approach, though. Could someone (Eric or Alexandre?) please take a look > at it before I send it to wine-patches? It would be better to do the LoadLibrary16("mmsystem") in wine_initial_task, this way it only impacts 16-bit applications. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wineconsole compile error
by Alexandre Julliard 24 Nov '01

24 Nov '01

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > dialog.o dialog.c > dialog.c: In function `WCUSER_GetProperties': > dialog.c:492: structure has no member named `u' > dialog.c:496: structure has no member named `u' > dialog.c:500: structure has no member named `u' > dialog.c:509: structure has no member named `u3' > > This is happening on gcc 3.0.2 (nameless union support, I suppose). It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

1 0

wineconsole compile error
by Andreas Mohr 24 Nov '01

24 Nov '01

Hi all, people get make[1]: Entre dans le répertoire `/home/wine/programs/wineconsole' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DUNICODE -D_REENTRANT -I/usr/X11R6/include -o dialog.o dialog.c dialog.c: In function `WCUSER_GetProperties': dialog.c:492: structure has no member named `u' dialog.c:496: structure has no member named `u' dialog.c:500: structure has no member named `u' dialog.c:509: structure has no member named `u3' This is happening on gcc 3.0.2 (nameless union support, I suppose). On my system, this file compiles painlessly: root@andi:/root# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20010902 (Debian prerelease) (no nameless union support, I suppose) I told this guy to replace .u. and .u3. in dialog.c with DUMMYUNIONNAME and DUMMYUNIONNAME3, respectively. This caused: dialog.c:492: parse error before `.' dialog.c:496: parse error before `.' dialog.c:500: parse error before `.' dialog.c:509: parse error before `.' I thought that this particular error was caused by a missing #include "winnt.h", but adding this didn't help either. Please fix this "mess" ASAP (in an appropriate way, one that I seem to not be able to find out :-\). Thank you ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany "Point is, nothing here is unfamiliar or unexpected. How long does it take before there's general recognition that Microsoft software has no business on the Internet? - Dennis E. Powell re: Code Red

1 0

Re: Where are we going on multiuser?
by Alexandre Julliard 24 Nov '01

24 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > What is our vision on support for multiple users on a single computer? > > I know that WINEPREFIX allows us to use something other than $HOME/.wine for > the base of everything but as far as I can see the whole design still > requires a different WINEPREFIX for each user. (e.g. the socket is in > wine-server-<hostname> and there is no apparent support for the system.reg, > user.reg and userdef.reg being in different places). You need one WINEPREFIX per user yes. You can use global registry files by creating symlinks to global files in the user WINEPREFIX. The usual way is to wrap your app in a shell script that will populate the user's WINEPREFIX if it doesn't exist yet. There are plans for splitting registry files into separate sections with some kind of include mechanism, but nothing implemented yet. -- Alexandre Julliard julliard(a)winehq.com

1 0

Where are we going on multiuser?
by Bill Medland 23 Nov '01

23 Nov '01

What is our vision on support for multiple users on a single computer? I know that WINEPREFIX allows us to use something other than $HOME/.wine for the base of everything but as far as I can see the whole design still requires a different WINEPREFIX for each user. (e.g. the socket is in wine-server-<hostname> and there is no apparent support for the system.reg, user.reg and userdef.reg being in different places). Bill

1 0

Re: fix documentation compilation error
by Andreas Mohr 23 Nov '01

23 Nov '01

On Fri, Nov 23, 2001 at 01:35:14AM +0100, Michael Stefaniuc wrote: > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Add missing </para> in documentation/packaging.sgml Ouch ! Hmm, better make an actual compile next time :-\ Sorry !! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

A window painting problem.
by Duane Clark 23 Nov '01

23 Nov '01

Howdy, Perhaps this is one of those things that is in work. But this patch causes one of the (sub)windows in the app Xilinx fpga_editor (commercial) to never get painted. The app has several windows within a window, including a scrolled window, which after the patch I can zoom in and out and move the scrollbars just fine. But the contents never get painted, no matter what I do, including hiding and reshowing, etc. All the other pieces and windows are painted fine. http://cvs.winehq.com/patch.py?id=1005773317852080273907632 Log message: Moved WIN_FindWinToRepaint functionality to the server. Duane

1 0

Re: Which is correct? listview or treeview?
by Gerard Patel 22 Nov '01

22 Nov '01

At 01:58 PM 21/11/2001 -0800, you wrote: >With regard to my problem that I was getting infinite redraws in my listview >following Alexandre's change to server/user/message.c: > >I eventually tracked it down to the fact our code used >SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be >demonstrated easily on e.g. the MFC RowList sample with a two-line change). >Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and >then RedrawWindow. >In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's >data. > >Which is (more) correct? I have seen the same problem with the plain listbox I have an app (Eudora) that is using WM_SETREDRAW on a listbox and found that it was not possible to reproduce the app's behaviour without doing directly a RedrawWindow. Andi commented it was ugly and unefficient (IIRC) and Alexandre Julliard ignored the patch anyway. So I intended at some point to look at Listview and Treeview (with the nasty intent to prove that I am right and they are wrong of course :-)) If you find that doing an explicit RedrawWindow is the right way (TM) I am all for it. OTOH, I have myself - at least ;-( - one regression pending for this patch. The attached hack (on dlls/x11drv/winpos.c) fixes it, maybe with a lot of luck it could fix your problem too ? I'm not too hopeful as it does not seem related but you never know. Gerard --- winpos.c.orig Tue Nov 13 23:02:20 2001 +++ winpos.c Thu Nov 22 00:24:35 2001 @@ -1464,6 +1464,14 @@ /*********************************************************************** * X11DRV_ConfigureNotify */ + +Bool predicate(Display *display, XEvent *event, char *arg) +{ + Window w = *((Window *) arg); + return ((event->type == ConfigureNotify) && + (event->xany.window == w)); +} + void X11DRV_ConfigureNotify( HWND hwnd, XConfigureEvent *event ) { HWND oldInsertAfter; @@ -1472,8 +1480,20 @@ RECT rect; WINDOWPOS winpos; int x = event->x, y = event->y; + XConfigureEvent ev; if (!(win = WIN_GetPtr( hwnd ))) return; + + while (XCheckIfEvent(event->display, (XEvent *)&ev, + predicate, (XPointer)&event->window)) + { + event->x = ev.x; + event->y = ev.y; + event->width = ev.width; + event->height = ev.height; + event->above = ev.above; + event->send_event = ev.send_event; + } data = win->pDriverData; /* Get geometry */

2 1

thanksgiving prayer
by lee 22 Nov '01

22 Nov '01

...wishing everyone a special thanksgiving filled with great joy, special friends and loved ones as we move forward to a brighter tomorrow, carrying with us the best of yesterday and the promise of today- lee

1 0

Crashing menus, event handling broken?
by Jukka Heinonen 22 Nov '01

22 Nov '01

While playing Civilization 2, I noticed that Wine crashes if I click menu bar twice while the game is thinking. The reason for this is that raw hardware messages get processed before menu event loop starts. Raw event processing turns raw events into cooked events and because menu event loop has not started yet, game window is not capturing events and thus clicks on menu bar are turned into nonclient messages. These cooked messages are put back into message queue. When menu event loop starts, it receives the second nonclient button press event and passes it to DispatchMessage. Default window procedure creates a new menu event loop and since the nonclient message was still in the event queue (it would have been removed if DispatchMessage had returned), we get a nice stack overflow. The real problem is not in menu event loop but in the fact that Wine event handling forgets that we can't determine whether a mouse event is nonclient event or not unless we have already called window procedure for all previous mouse events. This is because one of those calls might have for example captured mouse input after which we no longer report nonclient events. Since event handling is quite complicated and this flaw looks more like a design error than coding bug, I would like to get some discussion about what should be done to fix this problem. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: Packing in mmsystem16 and supporting broken GetWindowLong use cases
by Joshua Thielen 21 Nov '01

21 Nov '01

Jukka Heinonen wrote: >The second patch is because Wine mmsystem16 header does not use >correct packing which results into 48 byte structure taking >52 bytes and overwriting a pointer. This makes Civilization 2 >quite unhappy. Took almost a day to debug the game and >find out that the bugger who messes the pointer is really >waveOutGetDevCaps16... > Yessss! Thanks for finding this bug! It would have taken me ages to find it. Finale was choking awfully after calling midiInGetDevCaps. It would go into an endless loop, trashing my hard-drive and forcing me to do a hard reset on my box. Your patch fixes the problem. Cheers! Josh Thielen

1 0

Which is correct? listview or treeview?
by Bill Medland 21 Nov '01

21 Nov '01

With regard to my problem that I was getting infinite redraws in my listview following Alexandre's change to server/user/message.c: I eventually tracked it down to the fact our code used SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be demonstrated easily on e.g. the MFC RowList sample with a two-line change). Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and then RedrawWindow. In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's data. Which is (more) correct? (And how does calling RedrawWindow once result in the repeated repainting of the treeview anyway?) I'm prepared to do the fix if no-one else can but I must admit that I am not really up on the details of the invalidation/paint etc Bill

1 0

New level of Shlwapi (parts 1 & 2)
by Guy L. Albertelli 21 Nov '01

21 Nov '01

Most of the shlwapi upgrades have been driven by my desire to be able to run Outlook Express under Wine. (I know that there are other mail packages, but the rest of the home uses Windows - anyway it is a great test vehicle, uses everything ever implemented). The current status is as follows: With V4 or IE and OE - with builtin shlwapi,commctrl,comctl32 . IE displays page, can even do www.cnn.com, even runs javascript. + Certain menu popups either fail to display, or bomb. + Needs work in comctl32 rebar for extra space. . OE seems to basicly work. + Can display messages, change folders, and create messages. + Cannot invoke address book, but can request address list when creating new message. V5 of OE - requires native commctrl, comctl32: . With builtin comctl32 + OE fails to startup . With native commctrl, comctl32: + OE comes up but is mostly non-functional. Bombs on shutdown due to shlwapi.208 and shlwapi.210 V5 of IE - Does not start up yet. Requires native shlwapi . With native shlwapi, builtin comctl32 + IE has black toolbars with white lines. Menu line real small. . With native shlwapi and comctl32: + IE has black bitmaps for button bar. Mostly functional, however cannot access dropdown arrow for address bar. <sarcasm> I really appreciate the MS developer that decided to implement menus in OE5 with objects and put some of his "common" code in shlwapi. </sarcasm> Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: Improving DIB support for SHM
by Gavriel State 21 Nov '01

21 Nov '01

Doh! I guess we've been too lax about integrating some of our non D3D work back into WineHQ. We did this in WineX some time ago, but with a couple of differences: 1) We don't restrict using XShmGetImage to the whole-screen case and 2) We save and restore the XImage mask fields around the call to XShmGetImage, which seems to like to write over those fields to no useful purpose. IE: /* We must save and restore the bmpImage's masks in order * to preserve them across the call to XShmGetImage, which * decides to eliminate them since it doesn't happen to know * what the format of the image is supposed to be, even though * we do. */ saveRed = bmpImage->red_mask; saveBlue= bmpImage->blue_mask; saveGreen = bmpImage->green_mask; XShmGetImage( gdi_display, descr->drawable, bmpImage, descr->xSrc, descr->ySrc, AllPlanes); bmpImage->red_mask = saveRed; bmpImage->blue_mask = saveBlue; bmpImage->green_mask = saveGreen; We'll probably get around to doing some merging back into WineHQ after our next release. -Gav Jukka Heinonen wrote: > > The following patch halves the time it takes to move units > from one square to another in Civilization 2. If SHM is supported, > the patch uses XShmGetImage instead of XGetSubImage when filling > the whole XImage (which is probably way too careful since SHM is > much faster than the alternative...). Hopefully this > version is paranoid enough to work with older XFree86 servers > where XShmGetImage might change the underlying XImage format > into XYPixmap. > > Changelog: > Try to use XShmGetImage instead of XGetSubImage if SHM is supported. > Do a sanity check before using XShmPutImage. > > Index: wine/graphics/x11drv/dib.c > =================================================================== > RCS file: /home/wine/wine/graphics/x11drv/dib.c,v > retrieving revision 1.82 > diff -u -r1.82 dib.c > --- wine/graphics/x11drv/dib.c 2001/11/05 23:52:18 1.82 > +++ wine/graphics/x11drv/dib.c 2001/11/21 12:39:42 > @@ -4473,7 +4473,7 @@ > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > descr->width, descr->height); > #ifdef HAVE_LIBXXSHM > - if (descr->useShm) > + if (descr->useShm && descr->image) > { > XShmPutImage( gdi_display, descr->drawable, descr->gc, bmpImage, > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > @@ -4519,9 +4519,26 @@ > TRACE("XGetSubImage(%ld,%d,%d,%d,%d,%ld,%d,%p,%d,%d)\n", > descr->drawable, descr->xSrc, descr->ySrc, descr->width, > lines, AllPlanes, ZPixmap, bmpImage, descr->xDest, descr->yDest); > - XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > - descr->width, lines, AllPlanes, ZPixmap, > - bmpImage, descr->xDest, descr->yDest ); > + > +#ifdef HAVE_LIBXXSHM > + if (descr->useShm && descr->image && > + descr->xDest == 0 && descr->yDest == 0 && > + descr->width == bmpImage->width && > + lines == bmpImage->height && > + XShmPixmapFormat( gdi_display ) == ZPixmap) > + { > + XShmGetImage( gdi_display, descr->drawable, bmpImage, > + descr->xSrc, descr->ySrc, AllPlanes ); > + if (bmpImage->format != ZPixmap) > + ERR( "XShmGetImage changed image format!\n" ); > + } > + else > +#endif > + { > + XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > + descr->width, lines, AllPlanes, ZPixmap, > + bmpImage, descr->xDest, descr->yDest ); > + } > > TRACE("Dib: depth=%2d r=%lx g=%lx b=%lx\n", > descr->infoBpp,descr->rMask,descr->gMask,descr->bMask); > > -- > Jukka Heinonen <http://www.iki.fi/jhei/> -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

cleaning up pthreads implementation - ABI problem
by Peter Hunnisett 21 Nov '01

21 Nov '01

Howdy, I was just looking at cleaning up the pthreads implementation but I don't think that it's possible to have our pthreads implementation without providing binary compatibility with the pthread implementation we're hijacking. The reason is that the mutex and rwlock objects are supposed to be opaque to the programmer but in fact they are not opaque to the compiler. According to the standard, one doesn't have to call pthread_{mutex,rwlock}_init before using a {mutex,rwlock} as would be required with a totally opaque type. The standard allows for static initialization of the mutex and rwlock using PTHREAD_{MUTEX,RWLOCK}_INITIALIZER if you don't want any special attributes. libc does just this with its rwlock for gettext's global data. If you look at the ream of FIXME:pthread_rwlock_{rd,un}lock that sometimes come out starting wine you'll see that there's no call to pthread_rwlock_init. Of course, this stuff is safe because there's generally no writers wanting the pthread_rwlock_wrlock. So our current pthreads mutex implementation works in Linux by the skin of its teeth, becuase the first field in the mutex is reserved and initialized to 0 (in both the static and pthread_mutex_init cases), provided the version of LinuxThreads is new enough and a pointer is the same size as an int. Now I assume that this would mean it fails curiously for things that don't use LinuxThreads. This would also seem to mean, since we need binary compatibility, that things could even fail if someone upgrades their libc :( BTW, our check is presently basically only on __GLIBC__. Flavour me ignorant, and lazy, but I would assume that this not a Linux only symbol. So in fact the wine pthreads implementation might be already used incorrectly. Reader/Writer locks can be made to work the same way, as the mutex, since there are several fields which are initialized to NULL and we can then HeapAlloc our own structure off that field. We can then come up with weird and wonderful exceptions for the wonky cases that are sure to exist in some implementation of pthreads. Can anyone see a nice way out of this that I'm remaining ignorant to? I can't even think of a runtime way of detecting if our implementation is going to work. All in all I'm not too enthusiatic about the potential maintenance nightmare that this may provide but it would seem the only way is to have different mutex and rwlock structures depending on the pthreads implementation we're hijacking. Some code if people are more interested in details: >From glibc 2.2.4 /* Mutexes (not abstract because of PTHREAD_MUTEX_INITIALIZER). */ /* (The layout is unnatural to maintain binary compatibility with earlier releases of LinuxThreads.) */ typedef struct { int __m_reserved; /* Reserved for future use */ int __m_count; /* Depth of recursive locking */ _pthread_descr __m_owner; /* Owner thread (if recursive or errcheck) */ int __m_kind; /* Mutex kind: fast, recursive or errcheck */ struct _pthread_fastlock __m_lock; /* Underlying fast lock */ } pthread_mutex_t; #define PTHREAD_MUTEX_INITIALIZER \ {0, 0, 0, PTHREAD_MUTEX_TIMED_NP, __LOCK_INITIALIZER} What WINE uses (scheduler/pthread.c): /* assume that pthread_mutex_t has room for at least one pointer, * and hope that the users of pthread_mutex_t considers it opaque * (never checks what's in it) */ typedef struct { CRITICAL_SECTION *critsect; } *wine_mutex; rwlocks on the other hand are not so lucky as there's no unused bits: >From glibc-2.2.4 /* Read-write locks. */ typedef struct _pthread_rwlock_t { struct _pthread_fastlock __rw_lock; /* Lock to guarantee mutual exclusion */ int __rw_readers; /* Number of readers */ _pthread_descr __rw_writer; /* Identity of writer, or NULL if none */ _pthread_descr __rw_read_waiting; /* Threads waiting for reading */ _pthread_descr __rw_write_waiting; /* Threads waiting for writing */ int __rw_kind; /* Reader/Writer preference selection */ int __rw_pshared; /* Shared between processes or not */ } pthread_rwlock_t; # define PTHREAD_RWLOCK_INITIALIZER \ { __LOCK_INITIALIZER, 0, NULL, NULL, NULL, \ PTHREAD_RWLOCK_DEFAULT_NP, PTHREAD_PROCESS_PRIVATE } Ciao, Peter hunnise(a)yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

2 1

Re: _dev_t for MSVCRT
by Marcus Meissner 21 Nov '01

21 Nov '01

On Tue, Nov 20, 2001 at 10:16:14PM +0100, Uwe Bonnes wrote: > Changelog: > include/msvcrt/sys/types: > _dev_t in a unsigned integer > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > Index: wine/include/msvcrt/sys/types.h > =================================================================== > RCS file: /home/wine/wine/include/msvcrt/sys/types.h,v > retrieving revision 1.2 > diff -u -r1.2 types.h > --- wine/include/msvcrt/sys/types.h 2001/10/22 18:59:24 1.2 > +++ wine/include/msvcrt/sys/types.h 2001/11/20 19:44:21 > @@ -15,7 +15,7 @@ > #endif > > > -typedef unsigned short _dev_t; > +typedef unsigned _dev_t; Dann sollte da aber 'unsigned int' stehen ;) Ciao, Marcus

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel