The code sets the following timeout parameters:
Code: Select all
ReadIntervalTimeout = MAXDWORD;
WriteTotalTimeoutConstant = 500;
Initially I thought this was obviously an error with TeraTerm not re-trying if the wait failed but after doing some more reading I'm not so sure. There's documentation linked from the ReadFile API (https://docs.microsoft.com/en-us/window ... mmtimeouts) talking about comm timeouts. It says that:
Given that, it strikes me that ReadFile called when the comm timeout parameters are set as above, ought not to trigger an asynchronous read but instead return immediately with whatever data is present on the device. I think this means a modification to NtReadFile, probably right around line 5072 (https://github.com/wine-mirror/wine/blo ... le.c#L5072).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 bytes that have already been received, even if no bytes have been received.
I'm happy to propose a patch, but I feel a little like I'm running with scissors and would appreciate guidance as to whether or not this is the right approach
In case it's helpful, here's the code snippet from TeraTerm that does the reading from the serial port. Note that PReadFile is defined as ReadFile:
Code: Select all
do {
ClearCommError(cv->ComID,&DErr,NULL);
if (! PReadFile(cv->ComID,&(cv->InBuff[cv->InBuffCount]),
InBuffSize-cv->InBuffCount,&C,&rol)) {
if (GetLastError() == ERROR_IO_PENDING) {
if (WaitForSingleObject(rol.hEvent, 1000) != WAIT_OBJECT_0) {
C = 0;
}
else {
GetOverlappedResult(cv->ComID,&rol,&C,FALSE);
}
}
else {
C = 0;
}
}
cv->InBuffCount = cv->InBuffCount + C;
} while ((C!=0) && (cv->InBuffCount<InBuffSize));