我正在使用传统的C ++ / MFC / Win32代码。该项目通过单独的物理串行端口（每个客户端系统一个）将各种串行协议多路复用到公共前端数据存储库。
由于该程序最初设计为通过串行端口进行通信，因此在串行事件的设置和管理方面，代码中存在许多假设：ACK / NAK传输验证，内部字节延迟检查等......
现有架构通过WaitCommEvent利用事件通知重叠读写。
我的任务是使用单个客户端管道服务器添加另一个客户端界面;与串行端口一样，每个“文件”将支持一个客户端。
在阅读WaitCommEvent的文档时，它似乎被设计为与OS抽象的物理通信设备一起工作;比如串口。
简单的问题是，我可以利用现有的串行偏斜“等待”模型来处理管道，还是应该继续虚拟化它以便可以使用特定的管道逻辑覆盖它？
感谢那些知道我在问什么的开发人员（肯定是少数人）。
答案 0 :(得分：0)
我现在找不到一个好的参考，但我的理解是WaitCommEvent仅适用于通信资源，并且管道未被定义为与例如通信资源相同的通信资源。一个串口。 WaitCommEvent等待底层驱动程序设置某些位标志，比如新字符到达时，我不相信管道（或文件）在内部工作。