I have written a lot of commercial serial port code, and ain''t it fun! It sounds to me like:
1. Hyperterminal does exactly what you want it to.
2. Your code doesn''t.
Invest in a light box at Radio Shack. I think they still sell them. I think your lack of flow control is the culprit. Most devices use hardware flow control...RTS/CTS and DTR/DSR. I assume that you are using some form of NULL modem, since Hyperterminal works.
ClearCommError can be used to see if flow control is the culprit. EscapeCommFunction can be used to turn on RTS and DTR. I think your device is wanting the DTR before it sends anything.

To sum up, ALWAYS use RTS/DSR flow control unless you KNOW they are not needed. If Hyperterminal uses them, you must also. When a device wants to transmit, it raises RTS (Request To Send). The would-be receive device replies with CTS (Clear To Send). This is probably what Hyperterminal is doing that you aren''t. You can''t unilaterally decide against flow control, unless you hardwire the lines to loop back.

Yes, that''s what I''m saying to do. You might also set the bits in the DCB before you open the port. RS-232 is pretty difficult in a "non-preemptive" multitasking OS, and there is no real standard to speak of...RS-232 really only defines pins numbers on the connector, but if you are working in a process control, or data acquisition system, its almost always hardware flow control, like I said before. The post about using a thread is a GREAT IDEA in any case. If you couple that to a user defined message in your message pump, and have the thread "wake-up" the app to process data. Works great, even at high rates (I have gotten 115200 bps with no problem using MFC, and the OnIdle thread.) I stayed away from letting Windows do that work, because high data rate, and proprietary nature of the application gave it fits. HOPE THIS HELPS.