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

Re: wine/ dlls/winsock/socket.c dlls/winsock/ws2_3 ...

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > -static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum > fd_type *type, int *flags ) > +static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum > fd_type *type, int *flags_ptr ) > { > - int ret, fd = -1; > + int ret, flags, fd = -1; > > - ret = wine_server_handle_to_fd( handle, access, &fd, type, flags ); > + ret = wine_server_handle_to_fd( handle, access, &fd, type, &flags ); > + if (flags_ptr) *flags_ptr = flags; > > This is of course the most robust solution - but because > FILE_GetUnixHandleType is internal, you might as well require all > functions calling it to pass a valid flags pointer, and let > FILE_GetUnixHandle call wine_server_handle_to_fd directly, at a minimum > performance gain. My concern with that approach is that functions using FILE_GetUnixHandle wouldn't handle the shutdown flags correctly. The alternative would be to retire FILE_GetUnixHandle, or maybe move the shutdown flags handling into wine_server_handle_to_fd. -- Alexandre Julliard julliard(a)winehq.com

April 26, 2002

Re: bug in wine install

by Francois Gouget

On Fri, 26 Apr 2002, Yannick Fillatrau wrote: > I just have downloaded the source of wine v. 20020411, I launched ./tools/wineinstall as a normal user and I was told to enter the root password, the install crashed. > Here is a sample of stdout: > > Wine build complete. > --- > Performing 'make install' as root to install binaries, enter root password > Mot de passe: > /bin/bash: - : unrecognized option According to many past emails, this is caused by a missing space in a line that currently looks something like: su -c"... Add a space between c and ", and you should be ok. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

April 26, 2002

Re: dragging trillian's window causes the X server to crash

by Hetz Ben Hamo

> from /etc/X11/XF86Config-4: > > Section "Device" > Identifier "Device1" > Driver "vesa" > EndSection WHAT??? why do you use the vesa driver and not nvidia's own driver? Here's the same section on my Geforce 2 with nvidia binary only drivers Section "Device" # no known options Identifier "NVIDIA GeForce 2 GTS (generic)" Driver "nvidia" VendorName "NVIDIA GeForce 2 GTS (generic)" BoardName "NVIDIA GeForce 2 GTS (generic)" EndSelection Please read the README which comes with the drivers (there are 2 drivers - the GLX part and the kernel part) for the other modifications you'll need to do... The "Vesa" driver is only good for XFree86 free driver install (I think the new "nv" driver in XFree86 CVS already support GeForce 4, but only 2D) http://www.nvidia.com/view.asp?PAGE=linux Hetz

April 26, 2002

FD_CLOSE, again

by Martin Wilck

I still have problems with FD_CLOSE signalling. AFAICS FD_CLOSE must be signalled when either of the three following conditions hold: 1 Network error (Linux signals POLLERR) 2 Graceful close by the peer (Linux signals POLLHUP) 3 shutdown (SD_SEND) by the peer (Linux signals POLLIN with 0 bytes to read). ** Condition 3 will only be noticed if we tell poll() we're interested ** ** in POLLIN. ** In that case, if 1 or 2 occurs, POLLIN will also be signalled, whether or not there are still data to be read. However, we cannot simply activate POLLIN always, because if there _is_ data to be read on a normal connection and the app does not read it immediately, the server would busy-loop. We can take advantage of the fact that after every recv(), winsock will notify the server and try to re-enable FD_READ. (This does not hold for ReadFile() operations, as I pointed out in my recent "RFC..." posting). Thus what we could do is enable polling for POLLIN whenever FD_READ is re-enabled, even if then app has not registered for FD_READ notification, and disable it when POLLIN is received. Furthermore, finishing an asynchronous read request would also reenable POLLIN, whether or not there are more requests in read queue. Only an app that uses synchronous ReadFile() calls would never see FD_CLOSE. Does that seem correct, or am I again overlooking something?? It is a completely different story _at what time_ FD_CLOSE should be signalled when one ove the above 3 conditions is actually encountered. The Winsock2 spec says different things: In docs of WSAEventSelect: "FD_CLOSE should only be posted after all data is read from a socket, but an application should check for remaining data upon receipt of FD_CLOSE to avoid any possibility of losing data". This suggests that we could signal FD_CLOSE if POLLHUP is received, even if there is still data to be read, although we "should" not. In docs of WSAAsyncSelect: "[FD_CLOSE is posted] after remote system initiated graceful close, when no data currently available to receive (note: if data has been received and is waiting to be read when the remote system initiates a graceful close, the FD_CLOSE is not delivered until all pending data has been read)" This suggests the opposite - signal FD_CLOSE only after the app has read all data, even if this is far later than the actual POLLHUP. Actually this suggests that FD_CLOSE is _equivalent_ with condition 3 above, regardless if 1 or 2 are in effect. This is the behaviour I have tried to implement in my latest patches. Again, am I overlooking something? 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

April 26, 2002

Re: RFC: How should ReadFile() on sockets behave ??

by Martin Wilck

Hi Mike, > Hmmm. MSDN says that FD_READ is only re-enabled on recv, recvfrom, > WSARecv and WSARecvFrom. Maybe you should verify that ReadFile doesn't > re-enable FD_READ on a windows platform or two? You're absolutely right. Unfortunately this will take some time. The problem is that FD_READ has some really awkward connection with FD_CLOSE events, pretty hard to explain shortly. The discussion I had with Ove lately ("Urgent need for advice...") may give you some insight. > ReadFile in asynchronous mode already reports completion of reads to the > wineserver... Are you talking about finish_async() ? > why not make it always work like FILE_TimeoutRead in > files/file.c for sockets? I have been thinking about that, but it means adding some overhead for non-overlapped operations (doing an overlapped request this way requires more than just one server call). This hardly matters for slow comm ports, but it may matter if you communicate over a Gbit ethernet network socket. I like the idea, though, of getting rid of the distinction between overlapped and non-overlapped IO by just making everything overlapped and immediately waiting for the results in the synchronous case. (Basically the same code we're already using now in order to check if an overlapped operation can be completed immediately, just with bWait=TRUE). It would also have the benefit that you could mix asynchronous and synchronous calls to an overlapped fd without corrupting your data (I don't know if there are apps out there which do that, nor what Windows would do - the ReadFile() docs forbid it, but the WSARecv() docs don't). Of course this would also mean that all server objects that can be addressed with ReadFile() and WriteFile() must support asynchronous IO (wine-internally). I'll wait for other people's opinions. 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

April 26, 2002

Re: file.c:FILE_ReadFileEx - fd is not overlapped

by Martin Wilck

On Fri, 26 Apr 2002, Marcelo Welter wrote: > I upgrade my wine sources today with CVS and more advantages are in this new code (i'm very happy) but > with one printer i receive the messages: > trace:file:fd is not overlapped Allright, another bug of mine :( I wasn't aware that FILE_ReadFileEx can be called on non-overlapped file descriptors. The lines you deleted were basically a double-check, removing them should do no harm. So here we are: --- files/file.c.orig Fri Apr 26 18:48:40 2002 +++ files/file.c Fri Apr 26 18:50:41 2002 @@ -1562,11 +1562,6 @@ WARN ( "Couldn't get FD\n" ); return FALSE; } - if ( ! (flags & FD_FLAG_OVERLAPPED) ) { - WARN ( "fd is not overlapped\n" ); - SetLastError ( ERROR_INVALID_PARAMETER ); - goto error; - } ovp = (async_fileio*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio)); if(!ovp) @@ -1788,11 +1783,6 @@ { TRACE( "Couldn't get FD\n" ); return FALSE; - } - if ( ! (flags & FD_FLAG_OVERLAPPED) ) { - WARN ( "fd is not overlapped\n" ); - SetLastError ( ERROR_INVALID_PARAMETER ); - goto error; } ovp = (async_fileio*) HeapAlloc(GetProcessHeap(), 0, sizeof (async_fileio));

April 26, 2002

Re: RFC: How should ReadFile() on sockets behave ??

by Mike McCormack

Hi Martin, Hmmm. MSDN says that FD_READ is only re-enabled on recv, recvfrom, WSARecv and WSARecvFrom. Maybe you should verify that ReadFile doesn't re-enable FD_READ on a windows platform or two? ReadFile in asynchronous mode already reports completion of reads to the wineserver... why not make it always work like FILE_TimeoutRead in files/file.c for sockets? Mike Martin Wilck wrote: > If there is a socket for which event notification has been > requested by the application with WSAEventSelect(), > the behaviour is as follows: > > - When data arrives, FD_READ is signalled _ONCE_. > - FD_READ is only delivered again if the app explicitly > reenables it with WSAEventSelect/WSAAsyncSelect or > if the application issues a recv() call. > - The latter is accomplished in wine by calling _enable_event ( FD_READ, ...) > after every recv() operation in the winsock code. > - If an app uses ReadFile() rather than a winsock call > to retrieve data, the FD_READ event is of course not reenabled, > because the current implementation in file.c has no concept > of socket events. > > Question: should ReadFile() behave like recv(), i.e. reenable FD_READ, > or not? If yes, we would have a certain dependency of the ReadFile() code > on winsock, because FD_READ etc are winsock-specific macros. > If no, an app that relies on ReadFile() reenabling FD_READ will obviously > fail. > > The best thing would probably be to do this in the server, but we > currently can't, because the server does not notice when a read operation > is finished. > > Opinions? > Martin >

April 26, 2002

Byte Swapping in storage32.c for solaris

by Warren_Baird＠cimmetry.com

I've been running into some problems with byte swapping in ole related code - it looks like the relevant stuff is in storage32.c - I've modified StorageUtl_{Read,Write}Word and DWord to byteswap on bigendian platforms, and that seems to help, but I'm also running into problems with the wchar property names in StorageImpl_{Read,Write}Property - the individual characters are showing up in the wrong order, so "Data" is showing up as 0x44006100 0x74006100 instead of 0x00440061 0x00740061 as I would expect... Is it safe to use the same approach here? should ReadProperty byteswap each wchar and then WriteProperty byteswap it again? There seem to be a lot of places things like this happen: StorageImpl_ReadProperty(This, propertyIndex, &chainProperty); chainProperty.startingBlock = bbHeadOfChain; StorageImpl_WriteProperty(This, propertyIndex, &chainProperty); and I'm not sure how else to handle these cases... Also - at the moment the only byteswapping macros actually appear in tools/wrc/wrctypes.h - would it make sense to move them to one of the top-level include directories, and use them in both storage32.c and in wrc? If so, which include file should I drop them in? Thanks! Warren

April 26, 2002

Re: dragging trillian's window causes the X server to crash

by Michael Cardenas

XFree86 Version 4.1.0.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 21 December 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Build Operating System: Linux 2.4.13 i686 [ELF] Module Loader present from /etc/X11/XF86Config-4: Section "Device" Identifier "Device1" Driver "vesa" EndSection On Fri, Apr 26, 2002 at 11:49:19AM +0300, Hetz Ben Hamo wrote: > X server crashes??? > > Now thats the first time I hear about this one. Do you use XFree 4.1.0 (or > 4.2.0) with the latest nvidia drivers? I'm using Trillian but with > codeweavers's crosssover plugin and it works damn well, no crashes here... > > Hetz > > On Friday 26 April 2002 00:50, Michael Cardenas wrote: > > Using wine from 04/23/2002, when drag my buddy list window in trillian > > the X server crashes. > > > > -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 26, 2002

RFC: How should ReadFile() on sockets behave ??

by Martin Wilck

If there is a socket for which event notification has been requested by the application with WSAEventSelect(), the behaviour is as follows: - When data arrives, FD_READ is signalled _ONCE_. - FD_READ is only delivered again if the app explicitly reenables it with WSAEventSelect/WSAAsyncSelect or if the application issues a recv() call. - The latter is accomplished in wine by calling _enable_event ( FD_READ, ...) after every recv() operation in the winsock code. - If an app uses ReadFile() rather than a winsock call to retrieve data, the FD_READ event is of course not reenabled, because the current implementation in file.c has no concept of socket events. Question: should ReadFile() behave like recv(), i.e. reenable FD_READ, or not? If yes, we would have a certain dependency of the ReadFile() code on winsock, because FD_READ etc are winsock-specific macros. If no, an app that relies on ReadFile() reenabling FD_READ will obviously fail. The best thing would probably be to do this in the server, but we currently can't, because the server does not notice when a read operation is finished. Opinions? 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

April 26, 2002