Win32 TransmitCommChar trap

Sometimes my customers tell me they get trouble with TransmitCommChar. I try to tell you the story from driver side.

When you want to write data into COM port in Windows with C/C++, you will get 2 functions in SDK document: WriteFile and TransmitCommChar. If you only want to write one byte, most people will choose TransmitCommChar. Yes, it's easier than WriteFile. But I think this choice is not correct. 

TransmitCommChar is only "urgent" data and the char will be sent ahead of any pending data. In driver, it will only allocate one byte buffer for this function. When driver want to send any data, it will check urgent data buffer. If any, send it first. If there is any pending "urgent" data while calling this function, driver will return fail. That is, if you really want to use this function (just becuase WriteFile is too complicated...), you have to check the return value. If failed, you need to try again.

The "urgent" data concept is from UNIX. Sometimes you want to send "stop" or Xoff char to another side, you may this kind of function. So if you are not trying to send "urgent" data, don't use TransmitCommChar or you will get in trouble.