- Wine-devel - list.winehq.org

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

08 Jan '02

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 08 Jan '02

08 Jan '02

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 08 Jan '02

08 Jan '02

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 08 Jan '02

08 Jan '02

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

Re: struct async_private needs generalization for Winsock
by Mike McCormack 08 Jan '02

08 Jan '02

Hi Martin, That's pretty quick and thorough work! >I try to summarize the differences between the two request types here: > >1. Winsock async requests have a WSAOVERLAPPED struct rather than > OVERLAPPED. Unlike File I/O, the routines complete if any > positive number of bytes is read (there's no such thing as > BytesToRead). That case is similar to serial I/O when timeouts are (interval=-1,const=0,total=0), isn't it? The file I/O code doesn't really handle it properly yet either, as it just falls into a busy loop in the original ReadFile... hmmm. >2. Unlike File I/O, The WSAOVERLAPPED struct is *not* accessed in any Looks like you sorted this out in the other thread. i'd suggest you use the WSAOVERLAPPED fields in the same way as OVERLAPPED where ever possible, or not use them at all. i think you need the completion status in the Internal member... HasOverlappedCompleted is a macro that checks there. >[These are the differences I've come across so far, there may be more.] The way i've done the serial overlapped code so far is to implement what i *think* should be done, then wait for people to complain about their programs not working. You won't have to wait too long... >I'd therefore recommend the following, similar to the treatment of >"struct object" and derived types in the server code: > >struct async_private; >typedef void (*async_handler)(struct async_private *ovp); .. That looks OK to me. i'm not going to complain about it too much if i'm not doing the work to implement it ;-) Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

RE: Debugger on Solaris
by Patrik Stridvall 07 Jan '02

07 Jan '02

[I'm not sure what you are doing but...] > Robert Lunnon <bobNoSpaM(a)yarrabee.net.au> writes: > > > Here is what the Sun man page says about Ptrace, with > apologies to sun, you > > can find this page at docs.sun.com. Not the comment for > call 0 (TRACEME) and > > ESRCH in the error section > > But there has to be some way to attach to a running process. Yes, ptrace(PTRACE_ATTACH, ...) should work I believe. Haven't tried though. > What > happens when you do an attach in gdb? Does it do a ptrace? I'm not sure. Here is a trace of gdb trying to attach to a bash process (pid 11664).

2 1

Re: Debugger on Solaris
by Robert Lunnon 07 Jan '02

07 Jan '02

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

2 1

Re: cups printing quicken
by Marcus Meissner 07 Jan '02

07 Jan '02

On Sun, Jan 06, 2002 at 08:06:33AM +0000, Alex Newman wrote: > Hello wine people, this is my first posting here. I am using the gimp > printing ppd,cups and lpr on a hpdj842c. Wine release 20011226. On Debian > woody with 2.4.17. Everything rocks so far except whenever i try to print > in quicken either 2002 or version 6 which seem to printing with the same > program. wine freaks out and dies. > > wine --debugmsg +winspool .wine/fake_windows/Program\ Files/QUICKENW/QW.EXE > was sent to > http://www.wuli.nu/users/dolemite/winedebugmsg > my .wine/config is at > http://www.wuli.nu/users/dolemite/wineconfig > > I have printed with other progs in wine and normally and it works fine. Difficult. Try running it within winedbg, so it triggers at the time the exception appears and we can see the backtrace. (Just replace 'wine' by 'winedbg' in the commandline, type 'cont' to start the program.) Ciao, Marcus

1 0

Changes regarding wnaspi32 layer ?
by ma.hoff＠t-online.de 07 Jan '02

07 Jan '02

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

2 1

implement Cancelio (updated), WriteFile update, comm16 update
by l_whitney＠juno.com 07 Jan '02

07 Jan '02

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

1 0