>So if I open up a command prompt and enter the following command:
>

>echo this is a test > com1
>

>is this going through my print driver? How about this one:
>

>copy file test.txt com1
>

>

The above commands will not use the print driver as you are not printing to the Generic/Text printer. That is the ugly beast you are fighting with.

>These commands don't care if there is a printer driver attached. They work fine, and I don't think they are going through the print driver or the print spooler. I could certainly be wrong. It seems to me that the print driver attaches itself to the port, but doesn't open it until it needs to print. If open the port with mscomm and then change the print driver to use com1 there is no problem with the operation, but it will error when I try to print something using the print driver. That job will hang in the queue in an error state until I close the port with the mscomm control.
>

I think your above assessment on what's happening is correct.

>It seems to me that the printer driver is happy to let something else use port when it is not printing, but that mscomm will not open the port unless it can have exclusive access to it. If this is the case, is there some other tools I can use to work with the port that might work better?
>

I'm running Win2k with VFP8/9 here, and once I assign the Generic/Text driver to a comm port, I cannot use that port with the MSCOMM control at all, whether there is a print job or not. So if OPOS is out, and you need this status testing of the drawer with MSCOMM, how about running your print jobs to FILE with the Generic/Text driver and send that file with the MSCOMM control? Would this screw up your app badly? Sending the file could be as simple as:

Form.CommControl.Output = Filetostr("yourfile.txt")

Or am I oversimplifying the problem?