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

bug in wine install

by Yannick Fillatrau

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 Either you entered an incorrect password or we failed to run 'make install' correctly. If you didn't enter an incorrect password then please report this error to wine-devel(a)winehq.com. Installation failed, aborting. --- I'm sure the password was correct...

April 26, 2002

file.c:FILE_ReadFileEx - fd is not overlapped

by Marcelo Welter

Helle friends Still fighting with my serial printers.. :) 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 i comment the lines //if ( ! (flags & FD_FLAG_OVERLAPPED) ) { // WARN ( "fd is not overlapped\n" ); // SetLastError ( ERROR_INVALID_PARAMETER ); // goto error; //} in files/file.c and my printer communicate good. What i can change in my application to work with serial in this case See in +comm,+file trace:comm:ClearCommError handle 48 cbInQue = 2 cbOutQue = 0 trace:file:ReadFile 48 0x10025308 2 0x40566828 (nil) trace:file:FILE_TimeoutRead 48 0x10025308 2 0x40566828 trace:file:FILE_ReadFileEx file 48 to buf 0x10025308 num 2 0x40566794 func (nil) warn:file:FILE_ReadFileEx fd is not overlapped trace:comm:ClearCommError handle 48 cbInQue = 2 cbOutQue = 0 trace:file:ReadFile 48 0x10025308 2 0x40566828 (nil) trace:file:FILE_TimeoutRead 48 0x10025308 2 0x40566828 trace:file:FILE_ReadFileEx file 48 to buf 0x10025308 num 2 0x40566794 func (nil) warn:file:FILE_ReadFileEx fd is not overlapped Marcelo

April 26, 2002

warning while compiling with gcc3

by Rizsanyi Zsolt

Hi! I have run into a warning, when compiling with gcc 3.1 (I dont know if it is reported or not with 2.x gccs). And I think the warning is right. I dont think that the initializer of nil is right. It initializes an zero (0) character length WCHAR array to a one character lenght array. Or I just does not understand something? Here is the code snippet from dlls/commctl32/ipaddress.c line 265: static void IPADDRESS_ClearAddress (IPADDRESS_INFO *infoPtr) { WCHAR nil[0] = { 0 }; int i; TRACE("\n"); for (i = 0; i < 4; i++) SetWindowTextW (infoPtr->Part[i].EditHwnd, nil); } Best regards Zsolt Rizsanyi

April 26, 2002

Re: Bug 572

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > Alexandre, could you look at bug 572: > > http://bugs.codeweavers.com/show_bug.cgi?id=572 > > > > It is possible that this bug is caused by your > patch. > > Quite possible, but I'm afraid the trace is not > really helpful. I'd > need to see a backtrace, and probably a complete > relay trace too. <hint> Anybody can register in Bugzilla, add comments to the bug description, add his email to the CC list. Any bug updates will be sent to everybody on the bug CC list. </hint> :-) Alexandre, could you assign the bug to yourself? Add your request for information to the bug description. Thank you, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/

April 26, 2002

Re: existing cooperation with mono?

by Andriy Palamarchuk

--- Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > > And I think, that for the last type of programs a > cooperation between the > > Wine-Devels and the Mono-Devels is very > advantageous. So, existing this > > cooperations? > not to my knowledge. > moreover, it has to be seen the exact difference > between MS > implementation > and the ECMA standard which mono is supposed to > implement IMHO, now there is no interest in these technologies because they are currently useless for our goals - there is no applications which are based on them. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/

April 26, 2002

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

by Martin Wilck

Alexandre, -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. 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

[Germany] Linuxtag

by Uwe Bonnes

Hallo, is there anybody beside me willing to care for a booth at Linuxtag June 6-9 in Karlsruhe? Please give feedback so I can apply for a booth. Beside our normal program winex and crossover might be good objects to demonstrate. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 26, 2002

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

by Hetz Ben Hamo

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.

April 26, 2002

Re: More BUG fixes for winsock2 patch series

by Rein Klazes

On Thu, 25 Apr 2002 21:09:38 +0200 (CEST), you wrote: > > Patch: BUGS in my recently submitted patch series > > This applies over my complete patch series - > I will send clean patches tomorrow. > > The fixes in server/file.c and server/serial.c relate to Rein Klazes' > problem. Rein: please tell me if they fix it!! Yes, it works fine again. Thanks, Rein. -- Rein Klazes rklazes(a)xs4all.nl

April 26, 2002

Re: Last header patch for Mingw32 I think (wingdi.h)

by Alexandre Julliard

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> writes: > I think I needed it there for another define of MAX_PATH. stdlib.h does > exist in mingw. Do you think I should just use wines windef.h and > disregard this? I guess there could be a configure check for the MAX_* > definitions also. Well, wingdi.h uses MAX_PATH but it's up to the code including it to make sure that MAX_PATH is defined by including windef.h first. That's the way it works under Windows. It shouldn't matter whether you include Wine's or Mingw's windef.h, both should define MAX_PATH. And note that you can't use configure checks in standard Windows headers since the app using them may not have a configure script. -- Alexandre Julliard julliard(a)winehq.com

April 25, 2002

RE: Send the first two mingw32 patches to /dev/null and use these instead

by Steven Edwards

> > Index: windef.h > > =================================================================== > > RCS file: /home/wine/wine/include/windef.h,v > > retrieving revision 1.62 > > diff -u -r1.62 windef.h > > --- windef.h 10 Mar 2002 00:02:34 -0000 1.62 > > +++ windef.h 25 Apr 2002 02:09:36 -0000 > > @@ -157,8 +157,9 @@ > > #define _MAX_EXT _MAX_FNAME > > #define _MAX_PATH 260 > > #endif > > +#if ! defined (__MINGW__) > > #define MAX_PATH _MAX_PATH > > - > > +#endif > > This seems to be a mingw32 bug, it is not supposed to define > MAX_PATH, only _MAX_PATH. At least that's how it's done under Windows. > > I will email the mingw team and ask them about this and stdlib.h. Other then the MAX_* stuff and the basetsd.h issue there are no more major/annoying header problems I have found. Once again I guess a HAVE_MAX_PATH check could be written or this should work also. #ifdef __MINGW__ #undef MAX_PATH #endif #define MAX_PATH _MAX_PATH Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

April 25, 2002

RE: Last header patch for Mingw32 I think (wingdi.h)

by Steven Edwards

> > diff -u -r1.69 wingdi.h > > --- wingdi.h 3 Apr 2002 22:08:27 -0000 1.69 > > +++ wingdi.h 25 Apr 2002 16:48:19 -0000 > > @@ -24,6 +24,14 @@ > > extern "C" { > > #endif > > > > +#ifdef __MINGW__ > > +#undef _MAX_PATH > > +#undef _MAX_DIR > > +#undef _MAX_EXT > > +#undef _MAX_DRIVE > > +#include "stdlib.h" > > +#endif > > + > > Why do you need stdlib.h in wingdi.h? It's not there under Windows. > > -- > Alexandre Julliard I think I needed it there for another define of MAX_PATH. stdlib.h does exist in mingw. Do you think I should just use wines windef.h and disregard this? I guess there could be a configure check for the MAX_* definitions also. Steve "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

April 25, 2002

First attempt at unit testing. Victim of choice: _hread()

by Jakob Eriksson

Thanks to Vincent Béron and Francois Gouget I've managed to do my own little unit test. I post it here hoping for comments of any kind: possible improvements, additions, advice etc. (I guess I could add some more limit-tests, trying to read many small chunks in a row see that I still end up in the right place in the file. Things like that.) -------- #include "winbase.h" #include "winerror.h" #include "wine/test.h" static void test__hread( void ) { LPCSTR filename = "testfile.xxx"; LPCSTR sillytext = "en larvig liten text dx \033 gx hej 84 hej 4484 ! \001\033 bla bla..."; HFILE filehandle; char buffer[10000]; long bytes_read; UINT bytes_wanted; UINT i; filehandle = _lcreat( filename, 0 ); ok( HFILE_ERROR != filehandle, "_lcreat complains." ); ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite complains." ); ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." ); filehandle = _lopen( filename, OF_READ ); bytes_read = _hread( filehandle, buffer, 2 * strlen( sillytext )); ok( strlen( sillytext ) == bytes_read, "file has wrong size."); for (bytes_wanted = 0; bytes_wanted < strlen( sillytext ); bytes_wanted++) { ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." ); ok( _hread( filehandle, buffer, bytes_wanted ) == bytes_wanted, "erratic _hread return value." ); for (i = 0; i < bytes_wanted; i++) { ok( buffer[i] == sillytext[i], "that's not what's written." ); } } ok( HFILE_ERROR != _lclose( filehandle ), "_lclose complains." ); ok( DeleteFileA( filename ) != 0, "DeleteFile complains." ); } START_TEST(file) { test__hread( ); } -- regards, Jakob Eriksson The wages of sin is debugging. -- Ron Jeffries

April 25, 2002

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

by Alexandre Julliard

Michael Cardenas <michael.cardenas(a)lindows.com> writes: > do these patches include his fixes from today? Not yet, coming up soon. -- Alexandre Julliard julliard(a)winehq.com

April 25, 2002

Re: Bug 572

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Alexandre, could you look at bug 572: > http://bugs.codeweavers.com/show_bug.cgi?id=572 > > It is possible that this bug is caused by your patch. Quite possible, but I'm afraid the trace is not really helpful. I'd need to see a backtrace, and probably a complete relay trace too. -- Alexandre Julliard julliard(a)winehq.com

April 25, 2002