学习的最好方法就是看代码，所以我们不妨跟着 IPC 的调用路线图，来学习学习 IPC。
从 x01.Lab.Download 下载代码后，首先进入 main.c 文件，在 TestA 中，有这么一句：Print("<Ticks:%x>", GetTicksIPC()); 其中，GetTicksIPC 就是通过 IPC 获取时间 tick 数。进入 GetTicksIPC，会看到如下代码：
m.type = M_GetTicks;
_SendReceive(M_Both, T_IPC, &m);
return m.M_RetValue;
_SendReceive 是对 syscall.s 文件中的 SendReceive 封装。调用 SendReceive 会产生一个中断而进入 SysSendReceive（在 proc.c 文件中）。顾名思义，SysSendReceive 根据消息类型，进行相应处理。现在有个问题，就是消息不止一种，每种又不止一个，处理这么多消息，需要有个生生不息的发动机。这个发动机，就是 IPC 任务，进入 ipc.c 文件，可看到如下代码：
#include "kstd.h"
void TaskIPC() {
Message msg;
while () {
_SendReceive(M_Receive, T_Any, &msg);
int src = msg.source;
switch (msg.type) {
case M_GetTicks:
msg.M_RetValue = g_Ticks;
_SendReceive(M_Send, src, &msg);
break;
default:
Panic("Unknown message type!");
break;
}
}
}这一下就明白了，原来，在 TaskIPC 中，先接收所有的消息，再根据消息的类型进行处理，处理后的结果由 _SendReceive 发送出去。这同微软的消息处理机制如出一辙。
TaskIPC 在任务表中，由 Schedule 进行调用。而 Schedule 则由时钟中断周而复始的调用之。生生不息的机制原来在此！
由终端进入工程目录，make 后 bochs，可看到效果图如下：
看来，我们的 IPC 机制，已然发挥作用了。
不过，说实话，这套消息机制，看起来优雅，但多了几次调用，效率是大打折扣的。从设计看优雅，从实际看却不理想。二者不可兼得，还是要从实际出发。也难怪 Linux 要舍弃这套近乎完美的消息处理机制，而采用宏内核了。