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

Re: wine/ files/file.c server/file.c

by Martin Wilck

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

Jan. 8, 2002

Re: Listview ctrl

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Alexandre, why is it that you want so badly to get rid of the HEAP_strdup > functions? I mean, in certain cases they are not needed, and they rather > signal that the code needs fixing, but in other places they _are_ needed > and they convey a heck of a lot better what we're trying to do then the > strange WideCharXXX function calls. The reason is very simple: WideCharXXX are Windows API, HEAP_strdupA/W are not. If you want an strdup to make the code more readable, you can declare a static one in the file where you need it; but of course this only makes sense if it is used a lot. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002

Re: struct async_private needs generalization for Winsock

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > There is nothing wrong with that, since File IO has been the only type of > async request supported so far. All I'm asking for is to make this > structure a little more generic so that I can implement async IO on > sockets without a festival of casts and ugly hacks in the winsock code. Sure, I'm all for making it more generic. What I objected to was that your idea of generic seemed to be doing something like: if (socket) do this else if (serial) do that else if (file) do this other thing which is just the opposite of generic IMO. But a truly generic interface is clearly needed. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2002

RFC: new async_private implementation

by Martin Wilck

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); */

Jan. 8, 2002

Patch: BUG in thread_queue_apc()

by Martin Wilck

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; }

Jan. 8, 2002

Listview ctrl

by Dimitrie O. Paun

Hi folks, While I looking for something _small_ to do, I discovered that listview.c had two of those HEAP_strdupXXX calls that Alexandre hates so much. I figured that's got to be a 2 minute job, but I was wrong -- it turns out that the listview control needed to get Unicode enabled. 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. Alexandre, why is it that you want so badly to get rid of the HEAP_strdup functions? I mean, in certain cases they are not needed, and they rather signal that the code needs fixing, but in other places they _are_ needed and they convey a heck of a lot better what we're trying to do then the strange WideCharXXX function calls. -- Dimi

Jan. 8, 2002

Re: We *really* need a development model change !

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > I frankly don't see the need of a complex > test harness to > launch tests and print reports. Maybe when we have > 1000 tests we will > want some of that complexity, but for now it's only > a waste of time. Almost all complexity you are talking about is already implemented for us. Usage of the framework is very simple, do not require from test writers anything. They are only required to correctly use Test::Simple (or Test::More). They don't need to remember about Test::Harness. There are reasons to use Test::Harness: 1) control of TODO tests - I really want to use this feature. 2) control of SKIP tests - very useful for Wine-specific tests, choosing behavior, depending on Windows versions, etc. I need this feature too. 3) we already need to manage the test output. I'd estimate number of checks for my existing SystemParametersInfo unit test as: 25 (number of implemented actions) * 10 (minimal number of checks for each action) = 250 - 350 tests We'll definitely have huge number of tests. Why not pick up scaleable approach from very beginning? > Let's not debate licenses again. Anything that is > included in the Wine > distribution has to be under the Wine license. If > you want a GPLed > test suite you'll have to distribute it separately > from Wine; but I > think that would be a mistake. IMHO you can distribute them together if these are 2 separate applications, right? I don't have big preferences about the license. Wine license will work fine. We spent a lot of our valuable time and resources on the issue. Lets finalize the decisions and start to work. Suggest decisions from the discussion: 1) unit tests are very important for the project 2) mixed C/Perl environment will be used for the tests development. Choosing the tool is a matter of personal preferences. Comment: Alexandre, basing on the discussion above I think we both came to this. Do I understand you correctly? TODO: - create support in the build process 3) Test::Harness will be used to compile report for test batches Comment - TODO: - fix problems in using Test::Harness (and some other modules, BTW) with winetest Perl framework - create simple framework for C to print report in format, suitable for Test::Harness. (I already started to work on this.) - change Test::Harness to run not only Perl scripts, but also other types of executables (can do this) 4) The unit test will be a separate application Comment: Alexandre, we explicitely did not agree on this decision yet. You preferred to have unit tests spreaded over the Wine directory tree. The main argument for this was possibility of running subsets of test. I suggest to change Test::Harness (or create new module, based on it) to use tree-like tests organization. If you need to test module wine/dll/foo, you request to run tests hierarchy "wine/dll/foo". TODO: - customize Test::Harness to use tree-like test suits structure (I can do this). 5) Existing Wine license will be used for the Unit test application Please, let me know if I missed something or your point of view is not reflected. Looking forward for your comments. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 8, 2002

Re: struct async_private needs generalization for Winsock

by Martin Wilck

Hi Mike, > 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. I believe it's simpler for sockets because I'll use separate async handler routines which simply behave differently. I am not sure if it'll be possible to mimic the Windows behaviour *exactly* ... I guess there'll always be some sort of randomness involved in how many bytes are received in a single recv(). I worry about the MSG_PARTIAL flag, which doesn't seem to have a one-to-one Unix equivalent. > 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 ;-) Don't worry. I'm already working on it. I assume you have (a) test program(s) for the serial code - I would be grateful if you could run that against my patch (coming soon). Btw I'd like to hear your optinion on the discussion between Alexandre and myself in this thread. Cheers, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 8, 2002

Re: struct async_private needs generalization for Winsock

by Mike McCormack

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

Jan. 8, 2002

Re: struct async_private needs generalization for Winsock

by Martin Wilck

On 7 Jan 2002, Alexandre Julliard wrote: > > Do you _really_ consider it "clean" to use the WSAOVERLAPPED fields for > > arbitrary, unrelated Wine-internal data? > > Not really, but this is apparently what Windows does. I just made a test run on Win NT. The "Internal" field is used for some status information, the "InternalHigh" field for the number of bytes received/sent. There is no indication that Windows uses the "Offset"/"OffsetHigh" fields. Thus, I think we could use Internal and InternalHigh as in File IO, but we'd better leave the Offset/OffsetHigh fields alone. > Another way is to have a completion_func inside of winsock that takes > 3 args and in turn calls the user-specified func that takes 4 > args. This way synchro.c does not need to know about it at all. I don't consider that very "clean", either. > The basic infrastructure has to be generic enough to support all kinds > of async I/O. If it cannot it should be improved, but we must not work > around the lack of generality by adding winsock-specific hacks in the > kernel layers. IMO synchro.c is for handling _async requests_. Currently it has a lot of information on ReadFileEx()-type async requests built in which is unnecessary to make async requests work and makes implementing async socket IO a lot harder than a true "generic" interface would be. There is nothing wrong with that, since File IO has been the only type of async request supported so far. All I'm asking for is to make this structure a little more generic so that I can implement async IO on sockets without a festival of casts and ugly hacks in the winsock code. IMO the synchro.c code ideally should know nothing about e.g. the number of arguments a completion function takes, neither for file nor socket IO. I have understood that you don't like the idea of case distinctions in synchro.c - fine. I was suggesting it primarily for performance reasons. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 8, 2002

Wine & non X86 processors

by Hetz Ben Hamo

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

Jan. 7, 2002

Re: We *really* need a development model change !

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > :-( I need more than one thread to catch message on system parameter > value change. Not really, if you create a window your winproc will be called even if it's in the same thread. But we need to make threading work in any case. > I really like memory protection which is provided by "fork()". We are > going to need it (e.g. for TODO tests) :-/ The framework can be used > in forkless mode, however we still need to remove that piping stuff. > > Can we have the same advantages by using two-stage launching process? > The first part coordinates everything and starts each test with > "exec". Such implementation is less efficient but much more portable. IMO that's what we want, and the next step is to recognize that a simple shell script and a couple of makefile rules can do the "exec" job just as well, without having to worry about pipes or fork or whatever. I frankly don't see the need of a complex test harness to launch tests and print reports. Maybe when we have 1000 tests we will want some of that complexity, but for now it's only a waste of time. > a) this is license not for Wine, but for Wine testing > application. From my point of view GPL is very appropriate in this > case. Any other OS projects, using the test application will have to > contribute the changes back. On other hand the license won't hurt any > commercial application because nobody will make business on it. Let's not debate licenses again. Anything that is included in the Wine distribution has to be under the Wine license. If you want a GPLed test suite you'll have to distribute it separately from Wine; but I think that would be a mistake. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2002

Re: struct async_private needs generalization for Winsock

by Alexandre Julliard

Martin Wilck <mwilck(a)freenet.de> writes: > Do you _really_ consider it "clean" to use the WSAOVERLAPPED fields for > arbitrary, unrelated Wine-internal data? Not really, but this is apparently what Windows does. And I consider it better than having kernel32 file I/O code know about winsock specifics any more than necessary. > The only way to avoid these (admittedly unelegant) constructs is to use > yet more function pointers, like > > ovl->call_completion_func (ovl); > > where ovl->call_completion_func would be a function that "knew" > the number of arguments to pass to te completion function. Another way is to have a completion_func inside of winsock that takes 3 args and in turn calls the user-specified func that takes 4 args. This way synchro.c does not need to know about it at all. > As I said in the last mail, since we are talking about only 2 > alternatives, the use of function pointers may be more elegant, > but a little exaggerated to my taste. The basic infrastructure has to be generic enough to support all kinds of async I/O. If it cannot it should be improved, but we must not work around the lack of generality by adding winsock-specific hacks in the kernel layers. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2002

Re: We *really* need a development model change !

by Andriy Palamarchuk

Hmm, I don't see my post in wine-devel. Alexandre, did I send the message directly to you? If yes, could you, please, forward to the mailing list? Thank you. Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > >>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'm not sure if this is what happens, but if two threads try to send > results down the same pipe you'll have problems. I think there is no competition for the pipe. New pipe is opened for each test. It looks like not all handles are closed to the write side of the pipe and read hangs. Can it happen because the handle is inherited to wineserver? > You need explicit > threading support in the framework if you want to create threads (the > Perl framework doesn't support threads either at this point, so if > your test works there it's by pure luck). :-( I need more than one thread to catch message on system parameter value change. > Another potential problem is that the fork() option of the framework > is going to cause major breakage. You cannot use fork inside a Winelib > app. I really like memory protection which is provided by "fork()". We are going to need it (e.g. for TODO tests) :-/ The framework can be used in forkless mode, however we still need to remove that piping stuff. Can we have the same advantages by using two-stage launching process? The first part coordinates everything and starts each test with "exec". Such implementation is less efficient but much more portable. > And in any case I don't think a GPLed framework is appropriate for Wine. a) this is license not for Wine, but for Wine testing application. From my point of view GPL is very appropriate in this case. Any other OS projects, using the test application will have to contribute the changes back. On other hand the license won't hurt any commercial application because nobody will make business on it. b) on the Check mailing list I saw request to change license to less restrictive one. The main developer of the framework took into account this request. I also asked for less restrictive license, posted a couple bug reports, but have not had any feedback yet. I have an idea for compromise - let's use both - Perl and C tests. Perl module Test::Harness can be used to manage both types of the tests. C test application can print feedback information in format Test::Harness needs. A library can be created for this. This gives all the advantages of both tools and choice, do not impose big constraints on developers. Test::Harness is very mature framework and has clearly defined interface. I'm still for keeping all the tests as separate application. It is very easy to create test hierarchy for tests application if you want to have subsets of the tests. Andriy Palamarchuk

Jan. 7, 2002

Re: We *really* need a development model change !

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > 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'm not sure if this is what happens, but if two threads try to send results down the same pipe you'll have problems. You need explicit threading support in the framework if you want to create threads (the Perl framework doesn't support threads either at this point, so if your test works there it's by pure luck). Another potential problem is that the fork() option of the framework is going to cause major breakage. You cannot use fork inside a Winelib app. And in any case I don't think a GPLed framework is appropriate for Wine. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2002

Re: Debugger on Solaris

by Waldek Hebisch

Patric sed a trace: open("/proc/11664", O_RDWR) = 3 ioctl(3, PIOCSTATUS, 0x081811E0) = 0 ioctl(3, PIOCOPENLWP, 0x080476C8) = 4 ioctl(4, PIOCSET, 0x080476C4) = 0 close(3) = 0 ioctl(4, PIOCGTRACE, 0x0818163C) = 0 ioctl(4, PIOCGHOLD, 0x08181614) = 0 ioctl(4, PIOCGFAULT, 0x08181628) = 0 .... That looks pretty clear. However manual in Solaris 2.6 says that one should open /proc/pid/ctl for writing and specifyes messages to perform debug actions. Manual also suggests that ptrace is a library function working with proc filesystem so the only question is wether to use ioctl on /proc/pid or write to /proc/pid/ctl. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

Jan. 7, 2002

Re: struct async_private needs generalization for Winsock

by Martin Wilck

On 7 Jan 2002, Alexandre Julliard wrote: > But in our case Wine would be considered the service provider, so we > can use the structure. I wondered about that ... A "service provider" in Winsock terminology is something that implements low-level protocols below the winsock layer. To my understanding the winsock layer itself may not use it (the OS TCP/IP stack could :-). However, this may be a misunderstanding or overinterpretation on my part. > It seems you should be able to use the existing > code by providing a different async_handler function, and storing the > needed information in the WSAOVERLAPPED structure. That would be > cleaner than having the low-level file I/O routines know about winsock > structures. Do you _really_ consider it "clean" to use the WSAOVERLAPPED fields for arbitrary, unrelated Wine-internal data? The code would have to be full of comments like /* Note: overlapped->OffsetHigh is the user-supplied struct sockaddr pointer */ I do not intend to make the low-level file I/O functions know anything about winsock. In the worst case i would have something like this in synchro.c (Pseudocode): struct async_private *ovl; if (ovl->type & ASYNC_TYPE_WINSOCK) { struct async_winsock *aws = (struct async_winsock*) ovl; aws->completion_func ( [4 arguments] ); } else { struct async_fileio *af = (struct async_fileio*) ovl; af->completion_func ( [3 arguments] ) } The only way to avoid these (admittedly unelegant) constructs is to use yet more function pointers, like ovl->call_completion_func (ovl); where ovl->call_completion_func would be a function that "knew" the number of arguments to pass to te completion function. As I said in the last mail, since we are talking about only 2 alternatives, the use of function pointers may be more elegant, but a little exaggerated to my taste. Martin -- Martin Wilck <mwilck(a)freenet.de> Physicist & Linux system engineer at FSC <Martin.Wilck(a)Fujitsu-Siemens.com>

Jan. 7, 2002

Re: Lindows screenshots

by Bill Medland

"Bang Jun-Young" <junyoung(a)mogua.com> wrote in message news:20020108023339.A5460(a)krishna... > On Fri, Jan 04, 2002 at 08:06:11AM -0800, Bill Medland wrote: > > I wouldn't hold my breath; why would they contribute the valuable stuff > > back? > > What do you think of people that have contributed their invaluable > time/money/energy/passion/etc to Wine for last years? :P Sorry you took offence. I am in awe of what the team have achieved since the early days and impressed at how rapidly things appear to be moving at present. I believe in what Wine is doing, which is part of the reason why I am one of the people working on it (although I don't do all that much). I also get an impression that much of the development is based on altruism rather than financial concerns (which I guess is your point). Wine is now getting to quite an advanced state and so begins to look attractive to a lot of people. We have just finished a major discussion of the license and are basically going to leave it as it stands; at least that's my understanding. (And I agree with that) Gavriel has been quite up-front about what TransGaming are doing, in a business sense. Basically when the company reaches the equivalent of about $1million a year they can consider that they are recouping their investment and can feel comfortable passing back significant code. This implies to me a sense of honesty tinged with realistic business sense. Lindows, to the best of my knowledge, have made no such business committment to Wine; they agree to abide by all licenses but, as we have just discussed, the license does not require them to publish their source code. Considering their marketing etc. and their target market.I expect them to hang onto the work they have done for quite a while before feeding it back to the Wine tree. Maybe I am wrong (and I hope I am) but what we have to recognise is that Wine is now getting to the stage at which big business gets interested. Bill NB These are my own personal views..

Jan. 7, 2002

RE: Debugger on Solaris

by Patrik Stridvall

[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).

Jan. 7, 2002

Re: We *really* need a development model change !

by Andriy Palamarchuk

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/

Jan. 7, 2002

Re: struct async_private needs generalization for Winsock

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > 2. Unlike File I/O, The WSAOVERLAPPED struct is *not* accessed in any > way, except for the hEvent field. The other fields do not carry useful > information and are, according to the Winsock2 specs, reserved to > service providers, i.e. we are not allowed to write to them. But in our case Wine would be considered the service provider, so we can use the structure. It seems you should be able to use the existing code by providing a different async_handler function, and storing the needed information in the WSAOVERLAPPED structure. That would be cleaner than having the low-level file I/O routines know about winsock structures. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2002

Re: Debugger on Solaris

by Alexandre Julliard

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. What happens when you do an attach in gdb? Does it do a ptrace? -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2002

Re: cups printing quicken

by Marcus Meissner

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

Jan. 7, 2002

Re: Changes regarding wnaspi32 layer ?

by Marcus Meissner

On Sun, Jan 06, 2002 at 11:17:59PM +0100, Martin Hoffmann wrote: > 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 ? I think it is trying to use its own VxDs, nerocd95 and BsUDF. Running VxDs natively is not supported under WINE, you would need to reimplement them, which is probably too hard for the 2 above. Ciao, Marcus

Jan. 7, 2002

Re: WinSpool Ordinal Addition

by Alexandre Julliard

"Mark G. Adams" <mgadams(a)sympatico.ca> writes: > In Windows 2000 (and I presume later), winspool.drv has some new functions. > The one this application is looking for turns out to be GetDefaultPrinter() > (ASCII version is ordinal 201, Unicode is 203). I've added the ASCII and > Unicode implementations of that function to winspool in the attached patch. > The ASCII version has been tested; I'd appreciate it if you could take a > glance at the Unicode version and see if I got the conversions correct. > > The application will now open the 'printer setup' dialog, instead of > returning an error. Exactly what error did you get before? And are you sure this is really an ordinal import? This seems the kind of things that Win95 does, but not so much Win2000. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2002