My background is in writing extensive serial communication programs. Most of them were written using MSCOMM communications control that has shipped with VB since version 2.0.

Thus, I see (and get asked) the same questions over and over again. In the same vein, same mistakes are committed countless times. This tutorial is a compilation of many emails I've exchanged with programmers around the world, as well as an attempt to address these issues, so that they do not trip others.

The question usually goes like this: I've tried everything, but the data is not getting through or MSCOMM is not working. Let me assure you, MSCOMM is the most bug-free component that Microsoft has ever released. The problem is your code, your hardware, and your connections. In other words, the problem is YOU.

So, now that you've acknowledged where the problem lies, let's solve it. Follow these suggestions below, not necessarily in this order.

1. Know the hardware devices you are connecting. It is fine to go modem-to-modem, but what if you are connecting a PC to a device that requires this speed and that parity, etc
   
   
2. Question: I am connecting between two PCs and nothing is coming out on the other end.
   
   A regular serial cable will not work. You need a Serial NULL Modem cable or a standard serial cable with a NULL modem adapter. You can get it at any Radio Shack. Or let me know - I'll send you one for US$100 + shipping & handling.
   
   Or the cable is busted. See below on tips to check whether the cable is broken.
   
   
3. Question: I am connecting between two PCs and junk (unreadable characters) is coming out on the other end.
   
   Make sure the COMM port settings (i.e. baud rate, parity, etc...) on both PCs are the same. How do you accomplish that? Make sure that the Settings property for the MSCOMM control is identical on both ends.
   
   
4. Question: The comm port settings are identical on both ends, but I still have garbage coming out on the other end.
   
   Most likely you are overwhelming the output buffer. Check the OutBufferSize property. Do not send more characters than the size of the buffer (unless you have HandShaking set to something other than 0). Wait for the buffer to clear after sending data (by checking the size of the output buffer), then send more.
   
   Comm ports are basically chips that are called UART.
   If you have an older machine, UART chip may not be able to handle a large amount of data at once. In addition, some of the older chips topped out at 57,600 bps. So starting a conversation at 115 kbps will yield junk.
   
   As a last ditch measure (I do not recommend this for anything but the most desperate of circumstances), go to Device Manager (in Win9x), click on the properties for the com port in question, go to Advanced and start playing with the Receive/Transmit buffers. I don't even think this method is available in NT, 2k, XP machines. Again, this is after you've explored every single other possibility known to man.
   
   
5. Question: I am connecting to a custom/proprietary device that does some function (like a digital volt meter, taxi cab reader, etc anything really). I am sending it commands as specified in the manual, but it does not respond.
   
   Connecting to mysterious devices requires a bit of serial knowledge. I recommend finding a reference that indicates what each pin on the serial interface does, because this is HUGE when debugging custom devices.
   
   That said, let's see what could go wrong. The key here is knowing what the device requires.
   
   Does it need Handshaking to be enabled? If so, what type: software (Xon/Xoff), hardware (RTS) or both (very rare to nonexistent)? Set the HandShaking property accordingly.
   
   Does the DTR (Data Terminal Ready) line need to be on? If so, set the property.
   
   Does the RTS (Ready To Send) line need to be on? Set it then.
   
   What exactly does it mean to be ON? Basically, when you set it to ON or TRUE, the chip on the comm port sends electricity to that pin.
   
   
6. Question: How do I know if the cable is broken?
   
   This maybe too high-tech for some here. The solution for this problem was invented by a former co-worker of my, who goes by the name of Mark Willson. Plug in the serial cable into the comm port. Now take a staple, and finagle it into the other end of the serial port, so that it touches both pins 2 and 3 (they are marked). Now open HyperTerminal to a COM port and start typing. If whatever you type echoes back, the cable is fine.
   
   
7. Question: How do I send files from one PC to another?
   
   The details are beyond the scope of this article, but here are two suggestions. You can buy a commercial COMM control, which implements the popular file transfer protocols of yesteryear, like ZMODEM, YMODEM, XMODEM, etc
   
   Or you can roll your own. Here is an idea. Come up with a START_FILE and END_FILE data markers, so that the program on the other end can extract just the file. Generate CRC32 of the file and append it to the data stream. Then, on the other end, if the file matches the CRC32, then your transmission was successful. The receiving computer can send a FILE_OK data marker. If the sending computer did not receive the FILE_OK, then error has occurred in the transmission. This may sound simple, but I assure you that there are many things to worry about, particularly if you are sending data via an error-prone medium like wireless.
   
   
8. Question: Will it be faster if I use Windows API for serial communications?
   
   No.
   
   
9. Question: Is there any reason to use Windows API for serial communications?
   
   Not normally. However, if you feel that your life is too full of excitement, you can do in place of a depressant.
   
   
10. Question: Can I use MSCOMM with .NET?
    
    Yes, you could. Even though MSCOMM is a COM component, Visual Studio .NET lets you use those types of component through a technique known as Interop. You don't actually deal with Interop, as Visual Studio hides it pretty well. So to the programmer it looks like another .NET control. It is not, however, enough to simply copy mscomm32.ocx to your .NET development machine. You actually have to have VB6 installed there as well. If you don't have VB6 installed, you will get a license error when attempting to instantiate MSCOMM.
    
    
11. Question: Should I use MSCOMM with .NET? If not, what are the alternatives?
    
    Just because you could doesn't necessarily mean that you should. Because .NET talks to MSCOMM via the Interop layer, there will be a small performance penalty. Now if performance is not that big of an issue, you have no issues. There are two alternatives to the MSCOMM control. The first one would be the commercial native .NET communications controls from Sax and others. The second alternative is a class written by one of Microsoft employees that more or less mimics MSCOMM as far as the properties and the methods go. The advantages of this class? It is free and you already know MSCOMM. It was posted on MSDN a while ago. Grab it here.
    
    
    Update (December 8, 2003).
    Microsoft is distributing a Visual Basic .NET resource kit, which has a lot of great stuff for free. Included in the bundle is a free native .NET Serial Communications control from Sax Software Corp. This makes it a no-brainer. Get it while it lasts.