wably
commented
6 years ago As Peter has stated, a solution has been developed to correct the issues with commadpt.c when running Hercules on a Windows platform.
These changes can accommodate Windows and non-Windows builds of Hercules because of " #if defined(-MSVC-) " blocks added to the code where needed. This will allow (as one example) the proper handling of the Windows connect() function returning EWOULDBLOCK when connect() on other platforms returns EINPROGRESS.
I have tested the new commadpt modifications on Windows and they resolve the prior problems that Peter described. I will soon commit these changes to Hyperion.
I don't run Windows myself but I am aware of long standing issues using the commadpt 2703 bisync adaptor emulation when running Hercules on Windows. While working on a different device emulator for Hercules, I asked someone who does run Hercules on Windows to test my code and we ran into similar issues.
Bob Polmanter and I came up with solutions to make my code work properly Windows and it it occurred to me that the same solutions would apply to the issues with commadpt when running on Windows.
The main problem is that when running on Windows, outgoing connections from commadpt result in messages like this one:
HHC01001I n:ccuu:COMM: Connect out to a.b.c.d:p failed during initial status: A non-blocking socket operation could not be completed immediately.
Commadpt then goes on to assume the connection immediately failed when it actually may well succeed a short time later. Once that issue is overcome, commadpt can fail to be notice actual problems connecting. Both issues are because some Windows TCP/IP functions return different error values to those on other platforms in similar circumstances. For instance, Windows connect() returns the equivelant of EWOULDBLOCK when connect() on other platforms would return EINPROGRESS. Failures from connect() are also reported differently by select() on Windows compared to other platforms - they result in a bit being set in the exception file descriptor set, not in the write file descriptor set.
Bob and I have come up with a fix for commadpt which should address these issues with commadpt on Windows without any change to functionality on other platforms.