General serial communications issues
Hello, I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem. They all exhibit the same situation, DATA seems to go OUT, but never seems to come IN. Several other people have experienced the same thing, as seen in this bug report: http://bugs.winehq.org/show_bug.cgi?id=2115 By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a serial problem. It's freeware available here: http://hp.vector.co.jp/authors/VA002416/teraterm.html It appears to be a fundamental problem in the serial/file code, which I understand is now under the ntdll tree. Obviously, I don't know much about it, but there is definitely something wrong. I was wondering if any developers were aware of this problem, as the decreased general usage of serial communications may have caused this to slip under the carpet, so to speak. I look forward to hearing any ideas, work-arounds, or patches. Thanks _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/
"David Purucker" <purucker(a)hotmail.com> writes:
Hello,
I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem.
We are using serial ports under Wine for a current project, and they work OK (apart from a few warnings). The machine I'm using doesn't have X, so I haven't tried HyperTerminal or TeraTerm, but our console-mode applications operate pretty much as expected. I'm using two patches applied to a recent CVS. The first is a patch Eric Pouech recently posted: http://www.winehq.org/hypermail/wine-devel/2004/05/0297.html The second is a patch of my own to supress warnings when using a pseudo-tty as a serial port: http://www.winehq.org/hypermail/wine-devel/2004/05/0278.html But our apps worked OK before that; they just generated some warnings. Still, these patches might help, or at least cut down on the noise and help you find the real error. TeraTerm has source available, so it should be one of the easier applications to debug. ----ScottG.
On Mon, May 24, 2004 at 05:06:49PM +0000, David Purucker wrote:
Hello,
I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem.
Teraterm worked almost 100% ok a few months back for me. There was some issue with buffer sizes or something, but I changed a setting in TeraTerm and it worked perfect for me. regards, Jakob
Hi, I have problems with wine serial code since 2000/2001. I think this might be related to your problem. In my situation, I have a bunch of stores that runs linux. Their sales sistem is remote application that can be run thru ssh/telnet/... Unfortunally they are required to use expensive serial fiscal printers that does not work with linux. The solution was to use netterm, a freeware term program, that given special escape sequences, it will handle it to a proprietary dll that them comunicates to the printer driver. Everything worked fine until the serial rewrite somewhere between 2000 and 2001. One strange thing is that some new printers (different brand) now works fine with wine, while the older printer does not. I can only get them to work with wine 20001026. So you probably should try that out if you have a chance. One problem is that this is a really old version of wine, which makes it really difficult to compile under a new distro with gcc 3.x, new glibc and probably kernel 2.6. I am not a serial expert, but I don't understand what can change in the serial communication to work with one printer and not work with another (that use to work). For me serial is TX, RX and a few control pins and that's it. Does anyone knows what really changed in the serial code? Should the new code works like the old one or is there fundamental differences that makes this incompatible? Could this be a API problem and not a problem in the way serial is handled? I have the same application with both wines. Old 20001026 (in a old distro) for the old printer and recent builds (in fresh distro) for the new printer in different machines. Is there any debugging code I can generate to help solve or find where the problem lies? I really would like to help solve this issue, however I have little win32 knowledge. []'s Raul Dias On Mon, 2004-05-24 at 14:06, David Purucker wrote:
Hello,
I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem.
They all exhibit the same situation, DATA seems to go OUT, but never seems to come IN. Several other people have experienced the same thing, as seen in this bug report: http://bugs.winehq.org/show_bug.cgi?id=2115
By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a serial problem. It's freeware available here: http://hp.vector.co.jp/authors/VA002416/teraterm.html
It appears to be a fundamental problem in the serial/file code, which I understand is now under the ntdll tree. Obviously, I don't know much about it, but there is definitely something wrong.
I was wondering if any developers were aware of this problem, as the decreased general usage of serial communications may have caused this to slip under the carpet, so to speak.
I look forward to hearing any ideas, work-arounds, or patches.
Thanks
_________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/
Raul Dias a écrit :
I am not a serial expert, but I don't understand what can change in the serial communication to work with one printer and not work with another (that use to work). For me serial is TX, RX and a few control pins and that's it. there's lot of stuff in between the physical interface and the application code (linux TTY driver, Linux serial code, Windows libs...), and also several ways to call the Windows API.
Does anyone knows what really changed in the serial code? the way overlapped operations (aka asynchronous read/write) are handled.
However, it's hard to tell what's broken from the information you gave. It may also well be that your issues are not linked to the issues reported by others A+
Raul Dias wrote:
Hi,
I have problems with wine serial code since 2000/2001. I think this might be related to your problem.
In my situation, I have a bunch of stores that runs linux. Their sales sistem is remote application that can be run thru ssh/telnet/...
Unfortunally they are required to use expensive serial fiscal printers that does not work with linux.
The solution was to use netterm, a freeware term program, that given special escape sequences, it will handle it to a proprietary dll that them comunicates to the printer driver.
Everything worked fine until the serial rewrite somewhere between 2000 and 2001.
One strange thing is that some new printers (different brand) now works fine with wine, while the older printer does not.
I can only get them to work with wine 20001026. So you probably should try that out if you have a chance.
One problem is that this is a really old version of wine, which makes it really difficult to compile under a new distro with gcc 3.x, new glibc and probably kernel 2.6.
I am not a serial expert, but I don't understand what can change in the serial communication to work with one printer and not work with another (that use to work). For me serial is TX, RX and a few control pins and that's it.
Does anyone knows what really changed in the serial code?
Should the new code works like the old one or is there fundamental differences that makes this incompatible?
Could this be a API problem and not a problem in the way serial is handled?
I have the same application with both wines. Old 20001026 (in a old distro) for the old printer and recent builds (in fresh distro) for the new printer in different machines. Is there any debugging code I can generate to help solve or find where the problem lies?
I really would like to help solve this issue, however I have little win32 knowledge.
[]'s Raul Dias
The serial port problem has now been fixed. It is not in the CVS yet, but the patches attached to previous emails in this thread, when applied to the current CVS, make serial comms work. I hope this gets all your "serial fiscal printers" working with the latest wine versions. Althought the serial comms now works, it might not work with the redirector your were using. Maybe you won't need the redirector any more. Cheers James
James Courtier-Dutton a écrit :
The serial port problem has now been fixed. It is not in the CVS yet, but the patches attached to previous emails in this thread, when applied to the current CVS, make serial comms work.
I hope this gets all your "serial fiscal printers" working with the latest wine versions. Good news. The only issue I have is that the fix I sent to wine-devel might break the socket semantics :-( I'll have to check that before making a release candidate for CVS. A+
David Purucker wrote:
Hello,
I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem.
They all exhibit the same situation, DATA seems to go OUT, but never seems to come IN. Several other people have experienced the same thing, as seen in this bug report: http://bugs.winehq.org/show_bug.cgi?id=2115
By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a serial problem. It's freeware available here: http://hp.vector.co.jp/authors/VA002416/teraterm.html
It appears to be a fundamental problem in the serial/file code, which I understand is now under the ntdll tree. Obviously, I don't know much about it, but there is definitely something wrong.
I was wondering if any developers were aware of this problem, as the decreased general usage of serial communications may have caused this to slip under the carpet, so to speak.
I look forward to hearing any ideas, work-arounds, or patches.
Thanks
I can confirm this problem. My setup is this. PC -> Serial Cable -> Loopback plug. linux based kermit works correctly, and the loopback also loops RTS/CTS. I type a character, and the loopback plug returns it back to the PC. With the loopback plug removed, no character is returned. It I then use teraterm, teraterm manages to output characters to the cable (I see LEDs flashing on the loopback plug). But, no characters make it back to windows. I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe "no-loop.txt" is without a loopback plug. "loop.txt" is with a loopback plug. So, this is certainly a wine bug, and I hope the logs help someone fix this. Cheers James fixme:comm:SetupComm insize 8192 outsize 2048 unimplemented stub trace:comm:PurgeComm handle 0x68, flags f trace:comm:SetCommTimeouts (0x68,0x406cf558) trace:comm:SetCommState handle 0x68, ptr 0x406cf56c trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState fOutxCtsFlow 0 fRtsControl 1 trace:comm:SetCommState fOutxDsrFlow 0 fDtrControl1 trace:comm:SetCommMask handle 0x68, mask 0 trace:comm:SetCommMask handle 0x68, mask 1 trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x4232010c trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:PurgeComm handle 0x68, flags f trace:comm:EscapeCommFunction handle 0x68, function=6 trace:comm:EscapeCommFunction CLRDTR trace:comm:SetCommMask handle 0x68, mask 0 fixme:comm:SetupComm insize 8192 outsize 2048 unimplemented stub trace:comm:PurgeComm handle 0x68, flags f trace:comm:SetCommTimeouts (0x68,0x406cf558) trace:comm:SetCommState handle 0x68, ptr 0x406cf56c trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState fOutxCtsFlow 0 fRtsControl 1 trace:comm:SetCommState fOutxDsrFlow 0 fDtrControl1 trace:comm:SetCommMask handle 0x68, mask 0 trace:comm:SetCommMask handle 0x68, mask 1 trace:comm:WaitCommEvent (0x68 0x42320178 (nil) ) trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0x68 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0x68, flags f trace:comm:EscapeCommFunction handle 0x68, function=6 trace:comm:EscapeCommFunction CLRDTR trace:comm:SetCommMask handle 0x68, mask 0
Eric Pouech wrote:
James Courtier-Dutton a écrit :
I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe
WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA.
I linked two computers together. ttermpro on one, and kermit on the other. When I type characters on the ttermpro console, each character appears on the kermit console immeadiately. After looking at the first log: comm-file-ntdll.txt I noticed messages like this: - 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 I then thought. What would happen if I typed 1024 characters. So, in the second log file I do that: comm-file-ntdll-2.txt Eventually, after typing 1024 characters, they actually arrive on the ttermpro console. Summary: - All characters are getting through the comms link, except that on the receive (READ) path, individual chars are getting buffered, and only when the buffer is full do they reach the application. This sounds to me like some Nagle algorithm gone wrong. We would want this buffering to happen if there was a lot of traffic (e.g. PPP internet link), as it would reduce the amount of api calls, but for simple interactive terminal session, if a new char has not arrived within 2 or 3 chars periods at the current baud rate, the buffer should be forwarded to the application. I attach two log files, one where I type a few characters, and one where I typed more than 1024. I hope this helps Can other people verify my findings regarding the 1024 char threshold? Cheers James
Eric Pouech wrote:
James Courtier-Dutton a écrit :
I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe
WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA.
In addition to my last response regarding the 1024 buffer threshold, this web page might help. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/... Look at the details regarding the "ReadIntervalTimeout". Cheers James
Eric Pouech wrote:
James Courtier-Dutton a écrit :
I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe
WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA.
In addition, ttermpro.exe is setting the following: - memset(&ctmo,0,sizeof(ctmo)); ctmo.ReadIntervalTimeout = MAXDWORD; ctmo.WriteTotalTimeoutConstant = 500; SetCommTimeouts(cv->ComID,&ctmo); Which according to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/... Means: - ReadIntervalTimeout: Maximum time allowed to elapse between the arrival of two characters on the communications line, in milliseconds. During a ReadFile operation, the time period begins when the first character is received. If the interval between the arrival of any two characters exceeds this amount, the ReadFile operation is completed and any buffered data is returned. A value of zero indicates that interval time-outs are not used. A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the characters that have already been received, even if no characters have been received. So, WINE should be "return immediately with the characters that have already been received, even if no characters have been received." WINE is obviously not doing this. Cheers James
Eric Pouech wrote:
So, WINE should be "return immediately with the characters that have already been received, even if no characters have been received."
does this help ? A+
Yes and no. The read call does return quicker, but no actual characters get to the application if it returns quickly. characters still only get returned if I type 1024 chars. Summary: - I just have to type quicker than before! Not being able to leave much space in between chars now. ;-) Cheers James
I have looked into the wine code now, and async reads from the COM port are just broken. The app calls read, wine sets off the FILE_AsyncReadService, and then returns to the app. FILE_AsyncReadService is called each time a character is received from the COM port, and it buffers up the received characters in the 1024 bytes buffer. 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. This is where the input characters are getting lost. James
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+
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
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
Eric Pouech a écrit :
Izak Burger a écrit :
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 :-)
does this fix it ? A+ (don't forget to run tools/make_request after applying the patch and before compiling) +A
Eric Pouech wrote:
Izak Burger a écrit :
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 :-)
does this fix it ? A+
This works for me also. Nice work. Cheers James
participants (7)
-
David Purucker -
Eric Pouech -
Izak Burger -
Jakob Eriksson -
James Courtier-Dutton -
Raul Dias -
Scott W Gifford