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

Re: We *really* need a development model change !
by Gerard Patel Jan. 9, 2002

Jan. 9, 2002

At 04:44 PM 08/01/2002 -0500, you wrote: <snip> >(Another Pythoner, cool :) ) This has given me an idea - while I don't expect it to be used in Wine, I will try to write my own test progs with it : use the *windows* python interpreter under Wine. >From the doc, it's possible to call any win32 api from it using a 'calldll' interface. If it works well, I won't need a 'test framework' - just use the standard, available tool. Gerard

4 4

Immediate IO in ReadFile / WriteFile
by Martin Wilck Jan. 9, 2002

Jan. 9, 2002

Hi Mike, I just had the following thought on the immediate IO in ReadFile() / WriteFile() that you implemented: Consider the following situation: 1. There is no data available for reading on some fd (serial port, pipe, socket). 2. An application calls ReadFile() in overlapped mode. since no data is there, an overlapped request is scheduled. 3. Data becomes available before the app issues a wait request of any kind. 4. The application starts another ReadFile() request. Now data is there, and will be read immediately. No async request is scheduled. 5. Eventually, more data will become available, and the async request first scheduled will also return. However, this basically destroys the order of the requests. I am unsure how Windows would behave in such a case, and it is certainly difficult to provide a test case for this situation. It can occur, though, and my guess is this is the wrong behaviour. Thus, probably before doing the immediate read it should be checked if there are asynchronous requests already scheduled for reading, and if yes, ReadFile() should _not_ try to read immediately but go pending. Of course, this check would require a server call. The same reasoning applies for writing, of course. Things become even more confusing if you think of several threads reading from the same file. A very simple workaround would be to go pending unconditonally for overlapped requests. Although not optimal, this would be certain not to corrupt data. What do you think? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 1

Re: wine/ files/file.c server/file.c
by Martin Wilck Jan. 9, 2002

Jan. 9, 2002

On 8 Jan 2002, Alexandre Julliard wrote: > I'm not sure 002 is a good idea. It seems to encourage doing > distinctions between file types where we should instead try to handle > them in a common way. The whole point of the FD_TYPE_XYZ distinction, as it currently is, is that at some places (actually, only in WriteFile() and ReadFile()), a distinction according to fd type _must_ be made. I am not sure if Windows allows overlapped IO on the console, for example, but if yes, this patch would be a prerequisite to implement that. I just wanted to make this distinction more logical. I think it is necessary to separate fd types and flags. The distinction between regular files, pipes, sockets, ... that the patch introduces is currently not needed, but doesn't hurt IMO. If you wish, I can strip the patch down to its essential part (have separate flags for overlapped and timeout flags). I guess I could also proceed entirely without this patch, if you seriously reject it as a whole, but I fear this will bring trouble sooner or later. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

Re: We *really* need a development model change !
by Andriy Palamarchuk Jan. 9, 2002

Jan. 9, 2002

Spent a couple of days trying to port my test to C unit testing framework "Check". Simple tests work fine. Problems start when I try to use multithreaded Wine tests. In one case the framework stucks on reading from pipe. Other code layouts have other issues. The cause may be in incorrect pipes handling, multi-process tests handling or interaction with Wine thread implementation. I remember I also had some problems with Perl multithreaded tests... I attached my unit test example, almost identical to the one I published before for Perl framework. There is also a whole working directory. If you want to play with the it, just unpack it to wine/programs directory. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

5 14

Re: Listview ctrl
by Gerard Patel Jan. 9, 2002

Jan. 9, 2002

At 09:31 AM 08/01/2002 -0500, you wrote: <snip> >So, after much work and no testing, here is a first try at doing that. The >good news is that it seems it compiles. The bad news is that I have no >idea how to test it. So any suggestions on how to test the listview >control, or any help with the testing is greatly appreciated, as well as >any comments on the patch itself. > I have tested it with some of my test apps and I see a few regressions. With rowlist.exe that comes with Vc++, using 'large icons' and 'full details' only the first character of the text is displayed. The little program found at www.timex.com (IIRC it installs correctly under Wine) displays another problem (maybe related) : columns other than the first can be not displayed in some cases. Gerard

1 0

Wine & non X86 processors
by Hetz Ben Hamo Jan. 9, 2002

Jan. 9, 2002

Hi, A friend of mine who uses sparc machine wants to write a pentium emulator & use wine with it to run some apps... His question is - are there any special notes about wine in big endian? does he need to make lots of changes? if so, in whats parts in general? Thanks, Hetz

3 2

Linux Today - Tonight Live: New Directions for a New Year. We talk about WINE >> on The Linux Show
by Jeremy White Jan. 8, 2002

Jan. 8, 2002

FYI, they're apparently going to be talking about Wine tonight. Jer <http://linuxtoday.com/news_story.php3?ltsn=2002-01-08-024-20-OP-CY>

1 0

RFC: NamedPipes emulation API
by Luke Kenneth Casson Leighton Jan. 8, 2002

Jan. 8, 2002

this is an RFC document describing an API that may be used to provide Windows NT Style "NamedPipe" functionality. it will be of interest to samba, wine, freedce and win32 developers wishing to port applications to unix (via the wine win32 implementation of NamedPipes). the functionality described in this document is equivalent to, if you have access to the MSDN, the following (incomplete list of) Win32 functions: - CreateNamedPipe (returns a file handle) - TransactNamedPipe - a read operation on the named pipe file handle, above - a write operation on the named pipe file handle, above - a close operation on the named pipe file handle, above - WaitNamedPipe there follows a list of function declarations. these are samba-specific functions that are only of use to SAMBA 3 developers. int named_pipe_create( connection_struct *connection, /* contains all info needed, e.g. user security context */ const char *pipe_name, /* e.g. \\server\PIPE\pipe_name or \\.\PIPE\pipe_name */ ); this function returns -1 on failure or an SMB file index (fnum) on success. it is called when an SMBopenX or NTcreateX is received. from memory, the access point is api_pipe_open(), in pipe.c or reply.c. STATUS named_pipe_transact(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */ int transact_data_length, /* zero or more bytes */ char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */ int *transact_receive_length); /* zero or more bytes */ this function returns an NT status code. if there is more data to be received, then the function must return ERROR_MORE_DATA. NT_STATUS_OK is returned on success. from memory, the access point is api_pipe_readwrite() or reply_trans2(), or maybe reply_pipe_trans(). i don't recall which. again, it'll be in pipe.c or reply.c. STATUS named_pipe_read(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */ int *transact_receive_length); /* zero or more bytes */ this function returns an NT status code. NT_STATUS_OK is returned on success. this one's to be called by pipe_read() (api_pipe_read()?) STATUS named_pipe_write(connection_struct *connection, int fnum, /* the SMB file index from the named_pipe_create */ const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */ int transact_data_length); /* zero or more bytes */ this function returns an NT status code. NT_STATUS_OK is returned on success. this one's to be called by pipe_write() (api_pipe_write()?) the use of this API is quite simple, and provides a clean "cut-off" point between samba and all NamedPipe transactions. lkcl

1 0

RFC: new async_private implementation
by Martin Wilck Jan. 8, 2002

Jan. 8, 2002

The patch below implements my ideas from the "struct async_private needs generalization for Winsock" thread. It's a patch against CVS 2002-01-08. The Winsock stuff is still missing, that's the next step. This is only a trivial recoding of the File IO (compiles, successfully tested with my async file IO test code), whith the "generic" fields in async_private and the "fileio-specific" fields in the rest of the async_fileio structure. Note: Since it seems agreeable to use the lpOverlapped in Winsock the same way as for file IO, I made lpOverlapped a "generic" field. Mike (or other people interested), if you can test this against your serial port code I'd be grateful. Martin Patch file: async_private.diff Purpose: New winsock-friendly async_private implementation Created: 2002-01-08 Applies: CVS 2002-01-08 ChangeLog: wine/include/file.h: struct async_private: - remove buffer, count, completion_func fields. - add call_completion field (callback function that calls the completion function). struct async_fileio: - "Derived" from async_private, contains. remove buffer, count, completion_func fields. wine/scheduler/synchro.c: call_completion_routine(): function removed. finish_async(): use ovp->completion_func instead of call_completion_routine. check_async_list(): Initialize ovp. wine/files/file.c: fileio_call_completion_func(): New function, FileIO-specific callback. FILE_AsyncReadService(): - use struct async_fileio for specific fields. FILE_AsyncWriteService(): - dito. FILE_ReadFileEx(): - use async_fileio struct for overlapped initialization. - initialize ovp->call_completion field. FILE_WriteFileEx(): - dito. dlls/kernel/comm.c: COMM_WaitCommEventService(): - use struct async_fileio for "buffer" field. COMM_WaitCommEvent(): - see FILE_ReadFileEx(). Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ruX diffignore CVS/wine/dlls/kernel/comm.c MW/wine/dlls/kernel/comm.c --- CVS/wine/dlls/kernel/comm.c Tue Jan 8 17:43:25 2002 +++ MW/wine/dlls/kernel/comm.c Tue Jan 8 17:47:41 2002 @@ -1515,11 +1515,12 @@ static void COMM_WaitCommEventService(async_private *ovp) { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; + async_fileio *fileio = (async_fileio*) ovp; TRACE("overlapped %p\n",lpOverlapped); /* FIXME: detect other events */ - *ovp->buffer = EV_RXCHAR; + *fileio->buffer = EV_RXCHAR; lpOverlapped->Internal = STATUS_SUCCESS; } @@ -1536,7 +1537,7 @@ LPOVERLAPPED lpOverlapped) /* [in/out] for Asynchronous waiting */ { int fd,ret; - async_private *ovp; + async_fileio *ovp; if(!lpOverlapped) { @@ -1556,26 +1557,27 @@ if(fd<0) return FALSE; - ovp = (async_private *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { close(fd); return FALSE; } - ovp->lpOverlapped = lpOverlapped; - ovp->func = COMM_WaitCommEventService; + ovp->async.handle = hFile; + ovp->async.fd = fd; + ovp->async.type = ASYNC_TYPE_WAIT; + ovp->async.lpOverlapped = lpOverlapped; + ovp->async.func = COMM_WaitCommEventService; + ovp->async.call_completion = NULL; ovp->buffer = (char *)lpdwEvents; - ovp->fd = fd; ovp->count = 0; ovp->completion_func = 0; - ovp->type = ASYNC_TYPE_WAIT; - ovp->handle = hFile; - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev=ovp; - NtCurrentTeb()->pending_list = ovp; + ovp->async.next = NtCurrentTeb()->pending_list; + ovp->async.prev = NULL; + if(ovp->async.next) + ovp->async.next->prev=&ovp->async; + NtCurrentTeb()->pending_list = &ovp->async; /* start an ASYNCHRONOUS WaitCommEvent */ SERVER_START_REQ( register_async ) diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Tue Jan 8 17:43:51 2002 +++ MW/wine/files/file.c Tue Jan 8 17:47:41 2002 @@ -1298,6 +1298,21 @@ } /*********************************************************************** + * fileio_call_completion_func (INTERNAL) + */ +void CALLBACK fileio_call_completion_func (ULONG_PTR data) +{ + async_fileio *ovp = (async_fileio*) data; + TRACE ("data: %p\n", ovp); + + ovp->completion_func(ovp->async.lpOverlapped->Internal, + ovp->async.lpOverlapped->InternalHigh, + ovp->async.lpOverlapped); + ovp->completion_func=NULL; + HeapFree(GetProcessHeap(), 0, ovp); +} + +/*********************************************************************** * FILE_AsyncReadService (INTERNAL) * * This function is called while the client is waiting on the @@ -1305,18 +1320,19 @@ */ static void FILE_AsyncReadService(async_private *ovp) { + async_fileio *fileio = (async_fileio*) ovp; LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; int already = lpOverlapped->InternalHigh; - TRACE("%p %p\n", lpOverlapped, ovp->buffer ); + TRACE("%p %p\n", lpOverlapped, fileio->buffer ); /* check to see if the data is ready (non-blocking) */ - result = pread (ovp->fd, &ovp->buffer[already], ovp->count - already, + result = pread (ovp->fd, &fileio->buffer[already], fileio->count - already, OVERLAPPED_OFFSET (lpOverlapped) + already); if ((result < 0) && (errno == ESPIPE)) - result = read (ovp->fd, &ovp->buffer[already], ovp->count - already); + result = read (ovp->fd, &fileio->buffer[already], fileio->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1336,7 +1352,7 @@ lpOverlapped->InternalHigh += result; TRACE("read %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,ovp->count); - if(lpOverlapped->InternalHigh < ovp->count) + if(lpOverlapped->InternalHigh < fileio->count) r = STATUS_PENDING; else r = STATUS_SUCCESS; @@ -1352,7 +1368,7 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - async_private *ovp; + async_fileio *ovp; int fd; TRACE("file %d to buf %p num %ld %p func %p\n", @@ -1372,7 +1388,7 @@ return FALSE; } - ovp = (async_private *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio *) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { TRACE("HeapAlloc Failed\n"); @@ -1380,21 +1396,23 @@ close(fd); return FALSE; } - ovp->lpOverlapped = overlapped; - ovp->count = bytesToRead; + + ovp->async.handle = hFile; + ovp->async.fd = fd; + ovp->async.type = ASYNC_TYPE_READ; + ovp->async.lpOverlapped = overlapped; + ovp->async.func = FILE_AsyncReadService; + ovp->async.call_completion = (lpCompletionRoutine ? fileio_call_completion_func : NULL); ovp->completion_func = lpCompletionRoutine; - ovp->func = FILE_AsyncReadService; ovp->buffer = buffer; - ovp->fd = fd; - ovp->type = ASYNC_TYPE_READ; - ovp->handle = hFile; + ovp->count = bytesToRead; /* hook this overlap into the pending async operation list */ - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev = ovp; - NtCurrentTeb()->pending_list = ovp; + ovp->async.next = NtCurrentTeb()->pending_list; + ovp->async.prev = NULL; + if(ovp->async.next) + ovp->async.next->prev = &ovp->async; + NtCurrentTeb()->pending_list = &ovp->async; if ( !FILE_StartAsync(hFile, overlapped, ASYNC_TYPE_READ, bytesToRead, STATUS_PENDING) ) { @@ -1550,18 +1568,19 @@ */ static void FILE_AsyncWriteService(struct async_private *ovp) { + async_fileio *fileio = (async_fileio *) ovp; LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; int already = lpOverlapped->InternalHigh; - TRACE("(%p %p)\n",lpOverlapped,ovp->buffer); + TRACE("(%p %p)\n",lpOverlapped,fileio->buffer); /* write some data (non-blocking) */ - result = pwrite(ovp->fd, &ovp->buffer[already], ovp->count - already, + result = pwrite(ovp->fd, &fileio->buffer[already], fileio->count - already, OVERLAPPED_OFFSET (lpOverlapped) + already); if ((result < 0) && (errno == ESPIPE)) - result = write(ovp->fd, &ovp->buffer[already], ovp->count - already); + result = write(ovp->fd, &fileio->buffer[already], fileio->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1578,9 +1597,9 @@ lpOverlapped->InternalHigh += result; - TRACE("wrote %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,ovp->count); + TRACE("wrote %d more bytes %ld/%d so far\n",result,lpOverlapped->InternalHigh,fileio->count); - if(lpOverlapped->InternalHigh < ovp->count) + if(lpOverlapped->InternalHigh < fileio->count) r = STATUS_PENDING; else r = STATUS_SUCCESS; @@ -1596,7 +1615,7 @@ LPOVERLAPPED overlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) { - async_private *ovp; + async_fileio *ovp; TRACE("file %d to buf %p num %ld %p func %p stub\n", hFile, buffer, bytesToWrite, overlapped, lpCompletionRoutine); @@ -1616,34 +1635,35 @@ return FALSE; } - ovp = (async_private*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_private)); + ovp = (async_fileio*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) { TRACE("HeapAlloc Failed\n"); SetLastError(ERROR_NOT_ENOUGH_MEMORY); return FALSE; } - ovp->lpOverlapped = overlapped; - ovp->func = FILE_AsyncWriteService; + ovp->async.handle = hFile; + ovp->async.fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); + ovp->async.type = ASYNC_TYPE_WRITE; + ovp->async.lpOverlapped = overlapped; + ovp->async.func = FILE_AsyncWriteService; + ovp->async.call_completion = (lpCompletionRoutine ? fileio_call_completion_func : NULL); ovp->buffer = (LPVOID) buffer; ovp->count = bytesToWrite; ovp->completion_func = lpCompletionRoutine; - ovp->fd = FILE_GetUnixHandle( hFile, GENERIC_WRITE ); - ovp->type = ASYNC_TYPE_WRITE; - ovp->handle = hFile; - if(ovp->fd <0) + if(ovp->async.fd <0) { HeapFree(GetProcessHeap(), 0, ovp); return FALSE; } /* hook this overlap into the pending async operation list */ - ovp->next = NtCurrentTeb()->pending_list; - ovp->prev = NULL; - if(ovp->next) - ovp->next->prev = ovp; - NtCurrentTeb()->pending_list = ovp; + ovp->async.next = NtCurrentTeb()->pending_list; + ovp->async.prev = NULL; + if(ovp->async.next) + ovp->async.next->prev = &ovp->async; + NtCurrentTeb()->pending_list = &ovp->async; return TRUE; } diff -ruX diffignore CVS/wine/include/file.h MW/wine/include/file.h --- CVS/wine/include/file.h Tue Jan 8 17:43:45 2002 +++ MW/wine/include/file.h Tue Jan 8 17:47:41 2002 @@ -33,20 +33,31 @@ /* overlapped private structure */ struct async_private; -typedef void (*async_handler)(struct async_private *ovp); + +typedef void (*async_handler) (struct async_private *ovp); +typedef void CALLBACK (*async_call_completion_func) (ULONG_PTR data); + +extern void CALLBACK fileio_call_completion_func (ULONG_PTR data); + typedef struct async_private { - LPOVERLAPPED lpOverlapped; - HANDLE handle; - int fd; - char *buffer; - async_handler func; - int count; - int type; - LPOVERLAPPED_COMPLETION_ROUTINE completion_func; - struct async_private *next; - struct async_private *prev; + HANDLE handle; + int fd; + int type; + LPOVERLAPPED lpOverlapped; + async_handler func; + async_call_completion_func call_completion; + struct async_private *next; + struct async_private *prev; } async_private; + +typedef struct async_fileio +{ + async_private async; + LPOVERLAPPED_COMPLETION_ROUTINE completion_func; + char *buffer; + int count; +} async_fileio; extern void WINAPI check_async_list(LPOVERLAPPED ov, DWORD status); extern void finish_async(struct async_private *ovp, DWORD status); diff -ruX diffignore CVS/wine/scheduler/synchro.c MW/wine/scheduler/synchro.c --- CVS/wine/scheduler/synchro.c Tue Jan 8 17:43:37 2002 +++ MW/wine/scheduler/synchro.c Tue Jan 8 17:47:41 2002 @@ -36,25 +36,14 @@ } } -static void CALLBACK call_completion_routine(ULONG_PTR data) -{ - async_private* ovp = (async_private*)data; - - ovp->completion_func(ovp->lpOverlapped->Internal, - ovp->lpOverlapped->InternalHigh, - ovp->lpOverlapped); - ovp->completion_func=NULL; - HeapFree(GetProcessHeap(), 0, ovp); -} - void finish_async(async_private *ovp, DWORD status) { ovp->lpOverlapped->Internal=status; - /* call ReadFileEx/WriteFileEx's overlapped completion function */ - if(ovp->completion_func) + /* call overlapped completion function */ + if(ovp->call_completion) { - QueueUserAPC(call_completion_routine,GetCurrentThread(),(ULONG_PTR)ovp); + QueueUserAPC(ovp->call_completion,GetCurrentThread(),(ULONG_PTR)ovp); } /* remove it from the active list */ @@ -70,7 +59,7 @@ ovp->prev=NULL; close(ovp->fd); - if(!ovp->completion_func) HeapFree(GetProcessHeap(), 0, ovp); + if(!ovp->call_completion) HeapFree(GetProcessHeap(), 0, ovp); } /*********************************************************************** @@ -80,7 +69,7 @@ */ void WINAPI check_async_list(LPOVERLAPPED overlapped, DWORD status) { - async_private *ovp; + async_private *ovp = NULL; /* fprintf(stderr,"overlapped %p status %x\n",overlapped,status); */

1 0

Patch: BUG in thread_queue_apc()
by Martin Wilck Jan. 8, 2002

Jan. 8, 2002

The patch below fixes a bug in server/thread.c that causes APCs to be "forgotten". The patch is against today's CVS (2002-01-08). I came across this by testing async file I/O. When submitting several async IO requests, the IO completion routine was called only once for the first submitted request. I cannot oversee if this can break anything elsewhere, but I strongly believe the behaviour with this patch is more sane than without. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy Index: server/thread.c =================================================================== RCS file: /home/wine/wine/server/thread.c,v retrieving revision 1.72 diff -u -r1.72 thread.c --- server/thread.c 2001/12/20 00:07:09 1.72 +++ server/thread.c 2002/01/08 13:35:17 @@ -562,6 +562,8 @@ queue->head = apc; wake_thread( thread ); } + else apc->prev->next = apc; + return 1; }

1 0