Hello,
Perhaps I should appologise, I have been lurking on the list way too long and this message just passed by while I was messing arround with the next project, which gladly does not involve serial comms and wine :-)
I had a similar problem (characters go out, nothing gets in) and it turned out that it was caused because the Serial timeouts was set to a special combination, which I forgot, I just remember that one of the timouts was set to MAXDWORD. Now according to the windows api docs this means the serial port should behave like a socket, and Read always returns successfully with whatever is there (even if it is nothing).
Wine does not implement this special case though, so it ends up waiting 51 days (if I remember correctly) to fill the buffer, which of course never happens.
I worked arround it by adding a single if() that would tell upper layer code that this thing is a SOCKET and not a FILE if the special case timeouts are there. For my one app, that solved the problem. Hyperterm is still broken though, but I stopped caring at that point. The patch was posted to this list, with a comment that it is probably a severe hack that will stop working in future releases.
I have to admit that if the ovp details was somehow stored in the file handle (typing from memory, I haven't looked at the code in a month) the decision as to whether a read should succeed (ie set the status to success) can take into account details from the ovp, which includes things like timeouts and stuff. From a design point of view (this is the feeling I get anyway) the current serial code is well designed, but it appears not to work so well with some of the less well-designed parts of the windows API. IMHO anyway. I think adding the ovp to the file handle might break the neat layout, because I would think that at the file layer you really shouldn't have to worry about the details of the underlying device. Unfortunately it seems that fixing this problem requires you to do that.
My 0.02 ZA cents anyway (0.003 US cents) :-)
Cheers, Izak
James Courtier-Dutton wrote:
Eric Pouech wrote:
The next time the app calls read, wine sets off a new (now making it two) FILE_AsyncReadService, but clears the buffer first, so all the characters received from the previous FILE_AsyncReadService get lost.
it seems the event to be signaled when something is done in the first read is never set, hence the application not reading the content of the buffer.
can you send me the trace generated with the latest patch ? A+
I attach 2 log files. One is the latest wine cvs (before) The other is after applying your comm.diff patch (after)
The setup now is: - 2 PCs. With serial link between them Log taken with this command: On PC 1: WINEDEBUG="+comm,+file,+ntdll" wine ttermpro.exe 2>after-patch.txt On PC 2: kermit
kermit is a native linux app. I type "test1" then press ENTER on the kermit terminal, so 6 chars sent. Nothing appears on the destination terminal, although you can see the chars hitting wine. No chars are reaching the windows app. trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 1/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 2/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 3/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 4/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 5/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 6/1024 so far
I think that the results are almost identical, with and without your patch.
I think the problem is more due to wine/dlls/kernel/file.c:339 function ReadFile() and wine/dlls/ntdll/file.c:399 function NtReadFile()
With it calling at wine/dlls/ntdll/file.c:442 if (!(ovp = RtlAllocateHeap(GetProcessHeap(), 0, sizeof(async_fileio)))) I think that it should only call this once the first time NtReadFile() is called, and then just remember it for future read calls.
And also setting io_status->Information = 0; in too many places.
io_status->Information should be set to 0 initially, and then let FILE_AsyncReadService() increase it when chars are received.
Then, only let the NtReadFile() set io_status->Information=0; when it actually sends the chars to the application.
If NtReadFile() is called with io_status->Information > 0, i.e. some chars have arrived, it should return those chars to the application. Instead it is just setting io_status->Information=0; which effectively gets it to forget all the chars that FILE_AsyncReadService() has buffered up.
So, I think that we should some how store the ovp details in the file handle structure, so that it is remembered in between NtReadFile calls.
If you can give me some pointers as to how best to remember the ovp state between NtReadFile calls, I could do some more tests.
Well, that is my diagnosis of the problem, you might have other ideas.
Cheers James