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

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

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+

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