本文探讨一个新的Windows上的两个UI进程间的通信和编程模型。
开门见山，下面是这个通信模型的梗概图：
这个模型的设计目标描述如下：
（1）发送数据接口：RpcSend, RpcPost
- RpcSend是同步接口，发送数据到目标fsm, 同时接收返回数据，其原型为
int RpcSend(const char* strFsmName, unsigned int uEvent, PBYTE pMsgData, int nMsgDataLen, PBYTE& pResultData, int& nResultDataLen);
参数说明：
strFsmName: 目标状态机名称
uEvent: 事件id
pMsgData: 待发送数据
nMsgDataLen: 数据长度
pResultData:应答数据
nResultDataLen: 应带数据长度
返回值是发送的数据长度。
- RpcPost 定义为发送数据到目标fsm，与RpcSend相比，它不能接收到对方的返回数据。
int RpcPost(const char* strFsmName, unsigned int uEvent, PBYTE pMsgData, int nMsgDataLen);
参数说明：
strFsmName: 目标状态机名称
uEvent: 事件id
pMsgData: 待发送数据
nMsgDataLen: 数据长度
返回值是发送的数据长度。
（2）接收数据在状态机的事件函数中处理，函数原型为：onEventProc。
（3）应用的逻辑在状态机模型FSM中完成实现。
（4）两端的Container的功能为通信适配和容器的工作。它可以独立运行在一个新线程中，也可附着在现有应用的UI线程中。hMainWnd是这个Container的主窗口，如果该Container附着在一个应用的窗口上，hMainWnd就是这个窗口句柄.
（5）Pipe完成IPC的进程间通信，监听接收到数据，并发送给窗口消息过程。
实际上，在应用结构中，需要多个状态机的组合才能实现一个完整的应用需求，这组状态机需要一个管理者(Fsm Manager)来作为他们的容器或通信的纽带。
Fsm Manager需要从Fsm继承而来，所以它实际上也是一个状态机，这样做的好处能够通过状态机的组合创造出极大的灵活性和方便，同时RpcPost和RpcSend同样适用于Fsm Manager，因为它就是状态机。
状态机是怎么启动的？ 我们需要一个Manifest.xml，这是一个配置文件，我们在其中配置需要启动的状态的名字和参数。Container在初始化的过程中，会把状态机启动。一般我们只需要设置一个需要启动的Fsm Manager，而其它的状态机，通过这个Fsm Manager完成启动。