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

PATCH: async-immediate.diff (1 in series)

by Martin Wilck

PATCH: async-immediate.diff (Resubmission of http://www.winehq.com/hypermail/wine-patches/2002/04/0021.html) This patch uses a more elegant and (IMO) more wine-ish method to check for possible immediate completion of asynchronous IO requests in ReadFile() and WriteFile(). The implementation in current CVS is wrong for 2 reasons: 1. The overlapped event is not set, nor the completion routine called, if immediate completion succeeds. This breaks apps that do not check for immediate success. 2. If there are async requests currently in the queue, immediate completion will bypass the request ordering. This will lead to data corruption on FIFO-type files. The patch fixes this. Patch against: Wine CVS 2002-04-12 Test status: Compiles (no errors/warnings). Tested for regular file IO (ok). The 2002-01-15 patch has been tested for 16-bit serial IO by Lawson Whitney (ok). Modified Files: files : file.c Log message: Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> GetOverlappedResult(): Return ERROR_IO_INCOMPLETE if IO still pending (MSDN docs) ReadFile() / WriteFile(): Use GetOverlappedResult() to check for immediate completion. diff -ruNX ignore TMP/wine/files/file.c MW/wine/files/file.c --- TMP/wine/files/file.c Tue Apr 9 13:20:25 2002 +++ MW/wine/files/file.c Tue Apr 9 13:25:25 2002 @@ -1395,7 +1395,8 @@ if(lpTransferred) *lpTransferred = lpOverlapped->InternalHigh; - SetLastError(lpOverlapped->Internal); + SetLastError ( lpOverlapped->Internal == STATUS_PENDING ? + ERROR_IO_INCOMPLETE : lpOverlapped->Internal ); return (r==WAIT_OBJECT_0); } @@ -1576,41 +1577,21 @@ SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } - - /* see if we can read some data already (this shouldn't block) */ - result = pread( unix_handle, buffer, bytesToRead, OVERLAPPED_OFFSET(overlapped) ); - if ((result < 0) && (errno == ESPIPE)) - result = read( unix_handle, buffer, bytesToRead ); - close(unix_handle); - - if(result<0) - { - if( (errno!=EAGAIN) && (errno!=EINTR) && - ((errno != EFAULT) || IsBadWritePtr( buffer, bytesToRead )) ) - { - FILE_SetDosError(); - return FALSE; - } - else - result = 0; - } - /* if we read enough to keep the app happy, then return now */ - if(result>=bytesToRead) - { - *bytesRead = result; - return TRUE; - } - - /* at last resort, do an overlapped read */ - overlapped->InternalHigh = result; + close(unix_handle); + overlapped->InternalHigh = 0; if(!FILE_ReadFileEx(hFile, buffer, bytesToRead, overlapped, NULL, overlapped->hEvent)) return FALSE; - /* fail on return, with ERROR_IO_PENDING */ - SetLastError(ERROR_IO_PENDING); - return FALSE; + if ( !GetOverlappedResult (hFile, overlapped, bytesRead, FALSE) ) + { + if ( GetLastError() == ERROR_IO_INCOMPLETE ) + SetLastError ( ERROR_IO_PENDING ); + return FALSE; + } + + return TRUE; } if (flags & FD_FLAG_TIMEOUT) { @@ -1790,43 +1771,20 @@ return FALSE; } - /* see if we can write some data already (this shouldn't block) */ - - result = pwrite( unix_handle, buffer, bytesToWrite, OVERLAPPED_OFFSET (overlapped) ); - if ((result < 0) && (errno == ESPIPE)) - result = write( unix_handle, buffer, bytesToWrite ); - close(unix_handle); + overlapped->InternalHigh = 0; - if(result<0) - { - if( (errno!=EAGAIN) && (errno!=EINTR) && - ((errno != EFAULT) || IsBadReadPtr( buffer, bytesToWrite )) ) - { - FILE_SetDosError(); - return FALSE; - } - else - result = 0; - } + if(!FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, NULL, overlapped->hEvent)) + return FALSE; - /* if we wrote enough to keep the app happy, then return now */ - if(result>=bytesToWrite) + if ( !GetOverlappedResult (hFile, overlapped, bytesWritten, FALSE) ) { - *bytesWritten = result; - return TRUE; - } - - /* at last resort, do an overlapped read */ - overlapped->Internal = STATUS_PENDING; - overlapped->InternalHigh = result; - - if(!FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, NULL, overlapped->hEvent)) + if ( GetLastError() == ERROR_IO_INCOMPLETE ) + SetLastError ( ERROR_IO_PENDING ); return FALSE; + } - /* fail on return, with ERROR_IO_PENDING */ - SetLastError(ERROR_IO_PENDING); - return FALSE; + return TRUE; } switch(type)

April 12, 2002

Patch series for async socket IO & winsock2

by Martin Wilck

Hi, I will soon start submitting this week's work on async sockets. As I said in yesterday's "good news/bad news" posting, this is work in progress and far from being complete. However, I strongly need feedback and perhaps some testing by adventurous people. Anybody out there with an app that uses overlapped socket IO ?? However, the more basic parts can hardly break things, and do represent an improvement against the current CVS version. Even the other parts probably don't break apps, but I have not carried out extensive regression testing so far. Since the full thing would be too big, I have splitted it into functional pieces that are easier to read. I will forward those parts that I consider sufficiently robust to wine-patches. Of course the back side of splitting the patches is that the later ones depend (at least some) of the others. I have indicated these dependencies in the headers. That's not beutiful but probably better than one big chunk. I will be extremely grateful for any feedback. Nice weekend, Martin PS: As I indicated in my last posting, there is a lot of work outstanding to make all of the winsock2 code consistent with this async IO implementation. I see strange things in socket.c anyway, e.g. the select() call that simply disregards all the wait mechanisms that are provided in other places in wine. If any of the original authors of this code read this message, I'd be really happy to get in contact with you!! -- 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 12, 2002

Re: Make dumping more robust

by Uwe Bonnes

>>>>> "juergen" == juergen schmied <juergen.schmied(a)debitel.net> writes: juergen> I just rewrote the dumping of pidl's because the dumping itself juergen> produces lots of relay/snoop messages. So I made it not call juergen> any other functions. Will send it soon. Nice to hear :-) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 12, 2002

Re: Make dumping more robust

by juergen.schmied＠debitel.net

I just rewrote the dumping of pidl's because the dumping itself produces lots of relay/snoop messages. So I made it not call any other functions. Will send it soon. juergen

April 12, 2002

Expect Trouble

by Shachar Shemesh

Hi list, I am sorry if this is a baisc question. I have not been able to find anything about it in the docs. I am trying to run a small program I wrote and compiled with VC6 on Windows. I am getting the following error: Invoking /usr/bin/wine.bin HebTest.exe ... Warning: loading builtin kernel32.dll, but native version already present. Expect trouble. Warning: loading builtin user32.dll, but native version already present. Expect trouble. wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ("debugger/winedbg 134661992 32") (2) Read the Wine Developers Guide on how to set up winedbg or another debugger Wine failed with return code 5 I get the same error whether I am using my own CVS compiled version, or the nightly CVS for debian SID. I get this error regardless of whether I am using fake windows or real windows. I even tried removing the user32.dll file (0 bytes) completely from C:\Windows\System of the fake windows. Attached is the output when running wine with --debugmsg +all, and the binary I am using to run this program (it is a debug build). It's a tiny program of my writing, so unless I unwittedly stole it from somewhere, you hereby have my permission to use the binary as you see fit. Sources are available upon request. Thanks Shachar

April 12, 2002

WM_WINHELP, was: Re: Handling of messages above WM_USER in pack_message

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> I don't know if this global approach is valid, but at least it helped >> me to get winhlp32 working called with WinHelpA from an >> application. In what other way can we cope with user defined messages >> and their related structures in inter-process SendMessage? Alexandre> We can't. User messages cannot pass data around, WinHelpA Alexandre> will need to do that differently. The best way to find out Alexandre> how is probably to watch winhlp32 with a message spy under Alexandre> Windows. On Win95 OSR2 with Spy++ I could only see the Winhelp Message, nothing else special. Searching the web, I could find several approaches. However I think none of the required infrastructure is completly in place with wine yet - Allocate Remote memory The sending process allocates memory in the remote process with VirtualAlloxEx and copies the the local structure to that remote memory with WriteProcessMemory. Then the local process sends the WM_WINHELP message with the remote handle. This seems cleanest to me, but VirtualAllocEx is not yet implemented for remote processed. - Usage of shared memory (probably only on Win9X). Do we yet have shared memory? As we go the NT-way, this is probably depreciated. - Usage of SHAllocEx Probably requires support in the remote application to lock the passed handle, which is not the case for winhlp32.exe I could also see the possibility to inform the message-packer about the need to pack the WinHelp structure when RegisterWindowMessage is called. What other possibilities do other people see? Help and ideas appreciated. 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 12, 2002

Re: update to regression testing framework

by Alexandre Julliard

Paul Millar <paulm(a)astro.gla.ac.uk> writes: > Here's the rationale: when a test result is displayed (currently only on > failure or success in a todo block) the file name and line number are > included. If the test file is altered then any tests after the edit will > have different line numbers. This makes these tests look like new ones: an > undesirable behaviour but not too big an issue. Explicitly naming tests is > a way of making the test results line-number independent. I think it's much more useful to have line numbers, it makes it much easier to find the offending test. Most tests scripts will contain thousands of individual tests and you won't be able to come up with meaningful names for them anyway. For the same reason, I don't think displaying every successful test is really useful. Traces are a much better way to see what's going on IMO. -- Alexandre Julliard julliard(a)winehq.com

April 11, 2002

Re: NT Status vs. Dos Error code in async operations

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > What we'd need would consequently be a errno->NT status converter to > set the overlapped status correctly from the error reported by read or > write. file_set_error() in server/file.c should do what you want. You can't call the function from the client but you can simply copy the code. -- Alexandre Julliard julliard(a)winehq.com

April 11, 2002

Async IO on sockets: good news and bad news

by Martin Wilck

Hi, The good news is: I have the basic mechanism for async IO on sockets running. Requests can be scheduled and waited for, just like for regular files. The bad news is: This is not enough for sockets. Problems occur especially when sockets are closed, because the signalling of socket events uses a completely independent mechanism. This leads to all sorts of strange behaviour, mostly to data loss because "FD_CLOSE" is signalled prematurely. Sadly, this means for me: - The whole event signalling mechanism needs to be reworked so that it is consistent with overlapped IO. - Probably the async IO mechanism, too. It seems that it would be good to have a single IO queue where all events are handled, rather than several ones. Unlike now, also things like "peer closed socket" would be scheduled in that queue. Well I need to think more. Currently, I am not even sure how exactly it _should_ work. 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 11, 2002

Re: update to regression testing framework

by Tels

-----BEGIN PGP SIGNED MESSAGE----- Moin, On 11-Apr-02 Francois Gouget carved into stone: > On Thu, 11 Apr 2002, Paul Millar wrote: > [...] >> > -ok( ($atom >= 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); >> > +named_ok( "Adding atom \"$name\" via GlobalAddAtomA()", ($atom >= >> > 0xc000) && ($atom <= 0xffff) && !defined($wine::err) ); >> >> Here's the rationale: when a test result is displayed (currently only on >> failure or success in a todo block) the file name and line number are >> included. If the test file is altered then any tests after the edit will >> have different line numbers. This makes these tests look like new ones: >> an >> undesirable behaviour but not too big an issue. Explicitly naming tests >> is >> a way of making the test results line-number independent. > > Ok, so the goal is to make it possible to automatically analyze the > test results. I see you point then. > > [...] >> meaning) and they may appear at an arbitrary point. A test name always >> appears in the same line as the test result, producing lines like: >> >> tests/atom.pl:Checking GlobalAddAtom[AW](i) i < 0xc0000: Test succeeded >> >> IMHO, this is a lot cleaner than using trace messages, although there's >> still the potential redundancy between a test's name and its error >> message. > > Yes, seems cleaner than test messages but there is the problem of > redundancy between the 'name' and the error message. Also, it seems that > for your purposes all tests should use named_ok otherwise you will not > be able to identify all tests. This means modifying all tests, and/or > just having ok. No? Just a quick hint: The perl core test frame work already has dealed (probably) with problems like this. Check out the Test, Test::More and Test::Harness modules. Maybe you can re-use the work done there? Thanx in advance, Tels - -- "Why do you go so slowly? Do you think this is some kind of game?" PGP key available on http://bloodgate.com/tels.asc or via email. perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"' dynamically utilize value-added technologies -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPLXrMHcLPEOTuEwVAQHJXgf+K/UeFqq4jnCu3jqAVDN7Wy657APhmWsG ql3lhSqfjDYklE1Lvck0qzir0Eiz+9UycdbYswo+EX4OQB5NV2ut0DbRjWAhPqzI hnWh8iuC8q7RZQUbPWMLoJaZI/P+v5sVzpMcp3YGXAoa3JZfMcF7XW5LfT2/twMu XIFD5Kfly018SdJL1K1xxCjgt1zLUjVXjeYwhCj8KqJEX2tuo8rxKpk5wGD2z584 EGkjIqItXgyT5LJX2JXOGbmWsenUOeR3w1sXoOuJ+05A22eHibp5w1veWWvuL9Hr vXpnSxWW1lqi/0IZ3UxPK+3XbxtViC4us9qLSluUVbSrUmlVMDVY0w== =HC8H -----END PGP SIGNATURE-----

April 11, 2002