wine-devel

wine-devel@winehq.org

84471 discussions

Re: Regression errors
by Gerard Patel 13 Nov '01

13 Nov '01

At 11:06 AM 10/11/2001 -0500, you wrote: > >Thanks Gerard. I will try it Tuesday. Going out of town till then. Well, I have advanced a bit this weekend. I noticed that one of my test app does indeed show this regression after the patch we are talking about. As the case is a lot more simple than the one I was trying to debug before for this problem, I have been able to understand better what is happening. The problem shows itself in the following case : - invalidating a window - hiding it - deleting it and after that the paint count is > 0. I can make the paint count change correctly with the following change : --- winpos.c.orig Thu Nov 8 01:57:34 2001 +++ winpos.c Mon Nov 12 09:47:08 2001 @@ -883,10 +883,10 @@ if (!(winpos->flags & SWP_SHOWWINDOW) && (winpos->flags & SWP_HIDEWINDOW)) { - WIN_SetStyle( winpos->hwnd, wndPtr->dwStyle & ~WS_VISIBLE ); /* clear the update region */ -// RedrawWindow( winpos->hwnd, NULL, 0, RDW_VALIDATE | RDW_NOFRAME | -// RDW_NOERASE | RDW_NOINTERNALPAINT | RDW_ALLCHILDREN ); + RedrawWindow( winpos->hwnd, NULL, 0, RDW_VALIDATE | RDW_NOFRAME | + RDW_NOERASE | RDW_NOINTERNALPAINT | RDW_ALLCHILDREN ); + WIN_SetStyle( winpos->hwnd, wndPtr->dwStyle & ~WS_VISIBLE ); } else if ((wndPtr->dwStyle & WS_VISIBLE) && !IsRectEmpty( &oldWindowRect ) && IsRectEmpty( &newWindowRect )) Now, I don't know why this RedrawWindow call was commented out :-/ Gerard

2 1

Re: Yet another async I/O issue: block devices
by Mike McCormack 13 Nov '01

13 Nov '01

Hi Martin, Probably better to get the ordered overlappeds working on sockets and serial ports first before trying to perfect block devices. That will bring Wine's feature set inline with Win9x overlapped I/O. I've never had anybody complain that overlapped I/O on block devices doesn't work for any program. Most programs avoid using features that only work on NT... you're likely to find that only NT services use those API calls.... and they won't work on Wine anyhow, seeing we don't support services properly yet. It seems like a good idea to try to make everything perfect from the start, but an incremental approach is usually better. Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi, > >I just discovered yet another problem that arises for overlapped >I/O on normal disk files, more correctly, for any file on a block device. > >Obviously IO requests on block devices on Linux are _always blocking_. >I wrote a very simple test program for reading from a floppy disk and >found exactly this behaviour, no matter if O_NONBLOCK was set or not. >"man 2 open" also says that O_NONBLOCK may or may not have any effect on >non-socket fd's and for block devices it clearly has none. > ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: x11ddraw fix
by Alexandre Julliard 12 Nov '01

12 Nov '01

geschrader <geschrader(a)mediaone.net> writes: > When X11DRV_XF86DGA2_CreatePalette( ) creates the palette > used by X11DRV_DDHAL_DestroyPalette( ) and > X11DRV_DDHAL_SetPalEntries( ), the display which is used is > returned by thread_display( ). This patch makes these two functions > also use thread_display( ) ( rather than gdi_display ). This bug was > causing a BadColor (i.e. invalid colormap) error in the X server > when X11DRV_DDHAL_SetPalEntries( ) was called, followed by > an application crash. I think it would be better to create the palette on the gdi_display, this way it can be manipulated by other threads too. Could you try if this works for you? Index: dlls/x11drv/dga2.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/x11drv/dga2.c,v retrieving revision 1.5 diff -u -r1.5 dga2.c --- dlls/x11drv/dga2.c 2001/09/11 00:32:33 1.5 +++ dlls/x11drv/dga2.c 2001/11/07 20:28:34 @@ -174,8 +174,8 @@ static DWORD PASCAL X11DRV_XF86DGA2_CreatePalette(LPDDHAL_CREATEPALETTEDATA data) { - Display *display = thread_display(); - data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(display, DefaultScreen(display), dga_dev, AllocAll); + data->lpDDPalette->u1.dwReserved1 = TSXDGACreateColormap(gdi_display, DefaultScreen(gdi_display), + dga_dev, AllocAll); if (data->lpColorTable) X11DRV_DDHAL_SetPalEntries(data->lpDDPalette->u1.dwReserved1, 0, 256, data->lpColorTable); @@ -199,10 +199,9 @@ static DWORD PASCAL X11DRV_XF86DGA2_SetPalette(LPDDHAL_SETPALETTEDATA data) { - Display *display = thread_display(); if ((data->lpDDSurface == X11DRV_DD_Primary) && data->lpDDPalette && data->lpDDPalette->u1.dwReserved1) { - TSXDGAInstallColormap(display, DefaultScreen(display), data->lpDDPalette->u1.dwReserved1); + TSXDGAInstallColormap(gdi_display, DefaultScreen(gdi_display), data->lpDDPalette->u1.dwReserved1); } data->ddRVal = DD_OK; return DDHAL_DRIVER_HANDLED; -- Alexandre Julliard julliard(a)winehq.com

3 2

[RFC]: Overlapped I/O implementation
by Martin Wilck 12 Nov '01

12 Nov '01

Hi, I'd like to summarize my thoughts about an implementation of overlapped I/O in Wine that will offer full Windows functionality. I havent't thought it through in all detail, but I have a clear enough picture to write an RFC. I regard the following points as crucial: 1 "Generic" routines like ReadFileEx() need to work with files of almost arbitrary type, i.e. normal files, pipes, sockets, comm ports, ... 2 Different file types imply different semantics for overlapped I/O. In particular: a Files that don't support positioning (i.e. FIFOs, or basically everything except regular files) need to be accessed sequentially, i.e. there may only be one reader and one writer at a time, and these must be scheduled in the same order in which they were submitted by the application. Otherwise, the data read or written will be potentially scrambled. For regular files, on the other hand, spawning several I/O requests in parallel may be beneficial. b Files on some devices (in particular, block devices on Linux) need to spawn a separate thread for the async I/O operation, because I/O on such devices is always blocking, which is undesirable. Neither the process itself nor the service thread should be blocked by a time-consuming floppy I/O operation, for example. 3 The semantics of individual asynchronous I/O requests depend on the function that was called by the application, e.g. ReadFile() or WSARecv(), which take different arguments. Such calls may be mixed by the application, although it's certainly not good programming practice to do so. Based on these arguments, I'd suggest the following: A) The generic functions need to find out what the properties of a file descriptor wrt asynch I/O are. The most general way to implement this is to have an element int (*get_async) (struct object*, struct file_async*) in the obj_ops array. For non-file objects, this element would be NULL or no_get_async(). For non-overlapped file descriptors, the function would assign NULL to the file_async* argument, and return an error, a valid pointer would be assigned to file_async* otherwise. struct file_async would contain per-file information about asynch I/O, e.g. struct file_async { struct async_private *readers; /* list of async read requests */ struct async_private *writers; /* list of async write requests */ int flags /* supports positioning? Is I/O blocking on host OS ? etc. */ int (*get_timeout) (struct object *obj, int type, int count); /* function that returns timeout for device, needed e.g. for serial comm */ } I currently see no need for other file-type dependedent functions; It should be possible to write generic routines that handle the requests correctly according to the flags variable. The Wine server API would containe a file_get_async() request that returns the file_async structure associated with the file by calling the get_async() element of obj_ops. The async_private struct would look pretty similar as it looks now, with a generic part and a part that depends on the function invoked for doing async I/O (e.g. for sockets, whether ReadFile() or WSARecv() was called on the socket fd). IMO the async_private should not contain file type-dependent information which is per-file. It should rather contain a pointer to the respective file_async struct. Most importantly, the async_private struct it carries a pointer to a function that does the actual I/O, and another function pointer that handles the termination of the request (invocation of user completion routine etc.) B) The check_async() function in synchro.c operates on file descriptors rather than async requests. Once an overlapped I/O request is issued by the application, it is queued either in the readers or writers list of the async object (which is obtained from the server). If both the readers and writers lists were NULL beforehand, the fd is inserted into the list for check_async to work on. check_async() activates the first element(s) of both the readers and writers lists (where activate means that the actual read/write call is triggered). For FIFOS, only one element would be activated; for regular files several requests up to a given limit (e.g. 4). If the file is on a device where normal I/O would be blocking, a new thread is created for each activated request to satisfy it. When the requests' I/O routine (separate thread or not) is completed, it activates an event that triggers the generic "finish" routine. The finish routine calls the finish routine of the request, cleans up, and activates a new request if there is one that was queued but not activated. If both the readers and writers queue are empty after finishing the request, the file descriptor is removed from the list of handles to check in check_async(). C) If CancelIo() is called or a file is closed, all pending IO requests are removed from the file's async readers and writers lists; potential subthreads are terminated. With this approach, the wineserver would only be needed for retreiving the file's async I/O properties. The biggest change to the wine core would be the addition of a new function to obj_ops. I am looking forward to comments. Regards, Martin PS. A minor remark: The above approach would make it unnecessary to check for the return value of xyz_get_info() to be FD_TYPE_OVERLAPPED when initiating overlapped I/O. Instead, one could simply check if the async object returned by get_async() is non-NULL. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: GetDlgItem16 - is id signed or not?
by Gerard Patel 12 Nov '01

12 Nov '01

At 07:07 PM 11/11/2001 -0500, you wrote: > >It hasn't gotten itself fixed in the ordinary way of progress, so I have >finally gotten around to a regression in juno-1.49. It crashes just >after getting back 0 from GetDlgItem16, so I added a little trace inside >GetDlgItem. Now I know why it crashes, but I don't know - is id really >unsigned, or is GetControl16 incorrectly failing to extend the sign? >I guess I could try it each way and see which one does least damage, but >probably several of you know which way it is meant to go. I'd cast id to unsigned in GetDlgItem16. Gerard

2 1

Re: Regression errors
by Eric Pouech 12 Nov '01

12 Nov '01

> At 11:06 AM 10/11/2001 -0500, you wrote: > > > >Thanks Gerard. I will try it Tuesday. Going out of town till then. > > Well, I have advanced a bit this weekend. I noticed that one of my > test app does indeed show this regression after the patch we are talking > about. > > As the case is a lot more simple than the one I was trying to debug > before for this problem, I have been able to understand better what > is happening. The problem shows itself in the following case : > > - invalidating a window > - hiding it > - deleting it IIRC, before the big window overhaul (when paint count was attached to each window), when a window was hidden, its paint count wasn't set to 0 (or when the window was actually shown, its paint count wasn't set to 1). This lead to some painting errors... I don't know if this is fully related (and I didn't follow closely the new window stuff), but it may be related... in case this helps... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Re: More overlapped I/O issues (important)
by Mike McCormack 12 Nov '01

12 Nov '01

Hi Martin, You're right, i never considered multiple overlapped requests at the same time... To fix the problem correctly, you will need to move (some of) the overlapped code back to the wineserver, so that requests from different processes can be handled correctly. (i moved it out of the wineserver about a year ago for efficiency reasons.) Have a look at rev 1.7 of server/async.c to see how this worked. http://cvs.winehq.com/cvsweb/wine/server/async.c?rev=1.7&content-type= text/x-cvsweb-markup The current overlapped code (with the above exception) is similar to what win 9x supports, so it does not support overlapped on normal files, and file offsets in OVERLAPPED structures. If that could be implemented too, it would be good. i guess there is choice now... implement overlapped sockets with the existing structure, or make a rather large change to the wine architecture, which might take a while. Maybe a good first step is to back out my change which put overlapped operations into the client side code... Alexandre thought this could be done using POLLIO instead... Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi Mike, all, > >I see a severe problem with the current overlapped I/O implementation, >especially wrt extending it to Winsock2 overlapped I/O. > >The problem I see is with buffer ordering. > >For normal files, the file position from which to read is on the >OVERLAPPED struct. This was not in the Wine implementation, the patch in >my last email fixes it. > >For sockets and other FIFOs, this makes no sense. In this case Windows >specifies that buffers are read / written **in the same order they were >submitted**. This matters only if users spawn several asynchronous I/O >requests at the same time, but this is allowed and actually beneficial >for application performance (at least on Windows). > >Unless I oversee something essential, the current wine implementation >does not guarantee such behaviour. Actually, since new requests are >inserted at the head of the NtCurrentTeb() list, they will be considered >first in subsequent asynchronous reads - i.e. the order will be reversed. >If I/O requests don't complete in a single read() or write() call, the >ordering will be basically random. > >IMO this implies that for sockets, asynchronous reads and writes must >be scheduled such that only one request for a given socket is actually >reading at a time, and all others are blocked until this request is >finished. Again, this holds only for FIFO-type files. > >With the current structure, it seems to be very complex to sort this out. >One could recheck the fd list in check_async and remove duplicate fds. >One could also try to "lock" the fd somehow. Still it would be necessary >to ascertain that the correct request gets the lock first. > >With this min mind, it seems more natural for me to organize the >asynchronous requests in the "file" data structure itself. One would >have a reader's and a writers's list there, and make sure that for FIFOS >only the first list element can actually issue a read(), write(), send(), >or recv() system call. For normal files all elements in the lists could be >doing IO at the same time, question is if that makes sense or not. > >As I see it, this would mean both the readers and writers lists must >be stored in the file data structure in the wine server. >This would of course strongly affect the current implementation. > >Note that with Winsock2 overlapped I/O in place, it must >be possible to use also ReadFile(), ReadFileEx() etc. on >overlapped sockets, and get correct behaviour. >Thus the ReadFile() etc. code must be able to deal with both sockets >and ordinary files, and it makes no sense to intriduce a different >approach for sockets only. > >Please give me your opinion on these issues ASAP. > >Regards >Martin > >-- >Martin Wilck Phone: +49 5251 8 15113 >Fujitsu Siemens Computers Fax: +49 5251 8 20409 >Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com >D-33106 Paderborn http://www.fujitsu-siemens.com/primergy ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Loop (and other) problem in audio.c 1.45 located
by Simon Britnell 12 Nov '01

12 Nov '01

The problem is that I advance to the next wavehdr automatically in FeedDSP, which skips the first wavehdr sent to the wodPlayer. Doh! A patch will follow to fix this (which will be built on top of the race condition fix patch). __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

1 0

Re: Winsock2 & overlapped IO
by Mike McCormack 12 Nov '01

12 Nov '01

Hi Martin, Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> >I have taken a closer look at this code. I believe a very similar approach >is possible for Winsock. However, there are a few problems: Good to see you are a man of action, not just words! >typedef struct async_private .. >What do you think about this? > >It would be cleaner to define a "general" async structure >containing either a type-specific union or a pointer to >type-specific data, and using void* for pointers. However, that would >require even more changes in the async file I/O code, which I'd like to >avoid at the moment. i agree with you it would be better to use a union... i'll have a go at making a patch to do this. i'll probably understand the mess i've created in files/file.c more easily ;-) >Another difference is that the overlapped Winsock routines cause >asynchronous success notification (i.e. calling the completion routine or >signalling the lpOverlapped->hEvent) even if they are immediately >successful, which seems not to be the case for asynchronous file I/O. > >That would require a minor change in the check_async_list() routine. Cool, go for it. >Please tell me your opinion! > >Regards, >Martin i wrote a longer reply with a union definition in it, but accidently resized my Netscape window an lost it when the page reloaded :-( Could be about time to give up on this web-based email thing. Mike btw. in the patch in your other mail, you have: -typedef struct _OVERLAPPED * LPWSAOVERLAPPED; typedef HANDLE WSAEVENT; + +typedef struct _WSAOVERLAPPED { + DWORD Internal; + DWORD InternalHigh; + DWORD Offset; + DWORD OffsetHigh; + WSAEVENT hEvent; +} WSAOVERLAPPED, *LPWSAOVERLAPPED; + can you just use the following? typedef OVERLAPPED WSAOVERLAPPED; typedef LPOVERLAPPED LPWSAOVERLAPPED; typedef HANDLE WSAEVENT; or even #define... ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

3 3

GetDlgItem16 - is id signed or not?
by lawson_whitney＠juno.com 12 Nov '01

12 Nov '01

Good day! It hasn't gotten itself fixed in the ordinary way of progress, so I have finally gotten around to a regression in juno-1.49. It crashes just after getting back 0 from GetDlgItem16, so I added a little trace inside GetDlgItem. Now I know why it crashes, but I don't know - is id really unsigned, or is GetControl16 incorrectly failing to extend the sign? I guess I could try it each way and see which one does least damage, but probably several of you know which way it is meant to go. trace:dialog:DIALOG_CreateControls BEGIN trace:dialog:DIALOG_GetControl16 STATIC '' 1164, 12, 4, 232, 45, 50020000, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Get and Send Mail' 1162, 10, 55, 56, 28, 5003000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Just Get Mail' 1163, 70, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON 'Cancel' 1161, 130, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_GetControl16 BUTTON '&Help' 57669, 190, 55, 56, 28, 5001000b, 00000000 trace:dialog:DIALOG_CreateControls END trace:dialog:GetDlgItem GWL_ID 48c id 48a trace:dialog:GetDlgItem GWL_ID 48a id 48a trace:dialog:GetDlgItem GWL_ID 48c id 48b trace:dialog:GetDlgItem GWL_ID 48a id 48b trace:dialog:GetDlgItem GWL_ID 48b id 48b trace:dialog:GetDlgItem GWL_ID 48c id 489 trace:dialog:GetDlgItem GWL_ID 48a id 489 trace:dialog:GetDlgItem GWL_ID 48b id 489 trace:dialog:GetDlgItem GWL_ID 489 id 489 trace:dialog:GetDlgItem GWL_ID 48c id ffffe145 trace:dialog:GetDlgItem GWL_ID 48a id ffffe145 trace:dialog:GetDlgItem GWL_ID 48b id ffffe145 trace:dialog:GetDlgItem GWL_ID 489 id ffffe145 trace:dialog:GetDlgItem GWL_ID e145 id ffffe145 wine: Unhandled exception, starting debugger... Regards, Lawson The Devil finds work for idle minds.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel