search

otya128 / winevdm

16-bit Windows (Windows 1.x, 2.x, 3.0, 3.1, etc.) on 64-bit Windows
GNU General Public License v2.0
2.64k stars 150 forks source link

Reading data from the COM port does not work #1425

Closed nukee86 closed 2 months ago

nukee86 commented 2 months ago

Try the latest version first. Go here and click Environment: THIS_BUILD_IS_RECOMMENDED__VCXPROJ_BUILD=1-> Artifacts 1-> zip to download the latest version.

Describe the bug App succesfully connects to the device, sends some bytes, but is unable to read any data.

Expected behavior I've got an old app which connects through serial port to a device. I had no success with connecting using all available versions of winevdm. In the app, there's a possibility to check COM connection using raw terminal. It seems, that data is sent from the program to device, but it gets nothing in return. I wrote a simple python script to test if any data comes, but I get none. On the screenshot I attached you can compare expected behavior on windows xp and then there's windows 10 version which is not getting any data.

Screenshots raw_win10 raw_winxp

Environment (please complete the following information):

Tested also on Windows 7 64-bit, same behavior.

Additional context There is no crash or something like that. Program works without any problems, the only thing is it doesn't get any data coming from serial port.

trace_raw.zip

cracyc commented 2 months ago

Try https://github.com/otya128/winevdm/pull/1426 . This program sets a receive notification queue size of 160 bytes but never gets anywhere near that in your test so it isn't reading the input. Win31 ignores the limit and sends the message after 100ms. Ntvdm always sends the message if there's data available so i've changed it to work like that.

nukee86 commented 2 months ago

Thank you for your effort. It works like a charm! In my tests with raw terminal and with a device simulator I wrote, all the responses are as expected. Let the thread open until I test the app on Monday on the real device. The app is supposed to allow monitoring of many devices through terminal windows. I will put it to max stress and see if it won't crash. I'm already amazed it succeed to run on windows 10.

May I know what you mean by 160 bytes receive notification queue size? PCom-Server program sets that size? It would be weird, cause I reverse engineered the data sent and it gets nowhere near that value at any moment.

cracyc commented 2 months ago 
0130:Call USER.245: ENABLECOMMNOTIFICATION(0001,006f,00a0,ffff) ret=121f:e397 ds=1257
1880:0130:trace:comm:EnableCommNotification16 (1, 6f, 160, -1)

The third parameter sets the receive queue size. It's set by the program. Probably, on slower computers it needs the queue that large to avoid hanging the machine if data arrives too quickly. The 100ms timeout makes sure that the program is signaled when the machine is idle even if there is less than the limit data ready. On modern machines it doesn't matter.

nukee86 commented 2 months ago

You were right - i sent huge amount of data and raw terminal printed out the input. I was curious if that was the case with normal connection. I looked through traces of new and old compilation. Both cases EnableCommNotification16 was the same:

1c6c:Call USER.245: ENABLECOMMNOTIFICATION(0001,0053,0001,ffff) ret=1217:51e6 ds=1257
120c:1c6c:trace:comm:EnableCommNotification16 (1, 53, 1, -1)

However, in old compilation program "stopped" getting data at 0x2E byte, while the new one gets through. Here are the pictures: trace_old

trace_new

Logs: trace_new_old.zip

Seems like your fix sort out this problem aswell :)

nukee86 commented 2 months ago

I just tested communication on the real device. If I use COM port redirector, everything works fine. If I use real COM port in computer, i got no response again.

Here are my devices: devices

And here are traces for real com and vcoms to compare: trace_com.zip

I mainly got to connect using real COM port, so it would be great if there's something you can find in the traces.

cracyc commented 2 months ago

There's nothing in the trace that suggests why it's not working. Maybe there's something wrong with the connection or some incompatibility with your usb-serial adapter.