With the user-space UART API in Windows, I get 32ms timing resolution (this is the normal timeslice length for the Windows scheduler) which can be a problem for faster protocols that are character-based and not packet based, or that is running concurrent transfers.

Running kernel-space drivers in Linux or running MS-DOS (or writing a driver for Windows), it's possible to handle timing with magnitudes better resolution, making it easy to keep track of individual characters in full-duplex transfers. An ISR isn't limited by the timeslice granularity of any OS, but just by how long the OS or other drivers may block interrupts from getting serviced. A PC with a PCI board with two or four UART is a very good solution. And having way more RAM - and also disk - means it can not only detect received characters or toggled handshake signals with good resolution. It can also save very large logs for later post-processing.

I also have access to PPC-based embedded platforms where I can turn off the FIFO and process the data for two external ports directly in the ISR. No significant difference from a PC, except that they are more the size of a small network switch and consumes way less power than a PC.