WaitCommEvent compatible with pipes?

I am working with legacy C++/MFC/Win32 code. The project multiplexes various serial protocols over separate physical serial ports, one per client system, to a common front end data repository.

Since the program was originally designed to communicate over serial ports there are many assumptions开发者_如何转开发 in the code as far as setup and management of serial events go: ACK/NAK transport verification, inner-byte delay checks, etc…

The existing architecture leverages overlapped reads and writes with event notification via WaitCommEvent.

I have been tasked to add another client interface, using a single client pipe server; which, like the serial ports, will support one client per “file”.

In reading the docs for WaitCommEvent it looks like it was designed to work with OS abstracted physical communications devices; like serial ports.

The simple question, can I leverage the existing serial skewed “wait” model to work with a pipe, or should I go ahead and virtualize it so that it can be overridden it with specific pipe logic?

Thanks to those (the minority for sure) of developers who know what I am asking.

---

I can't find a good reference right now, but it is my understanding that WaitCommEvent only works with communications resources and that a pipe is not defined to be a communications resource in the same sense as e.g. a serial port. WaitCommEvent waits for the underlying driver to set certain bit-flags, like when new characters arrive, and I don't believe pipes (or files) work that way internally.