Win32 行程通讯的观念与技术.docxVIP

Win32 行程通讯的观念与技术窗子提供的永远只是局部的风景。身为窗子的制造者以及使用者的我们不可能不 明白这个道理:对於窗子的使用者日益挑剔的品味，窗子的制造者所能提供的不 仅止於窗子的大小，往往是窗子的数量。的确，探出窗去看得将更多 些，外头 天空地宽朗朗白日，别的窗子也许正有我们想要的风景。这篇文章谈的是 Interprocess Communication (IPC) ，我将与你分享跨行程通讯 的各项技术与资料交换的方法。为什麽需要 IPC?为什麽需要 Inter-process Communication?显而易见的，没有 个视窗应用程式可以包办全部的工作。为了避免资料重覆输 入的时间浪费与人为错误，各应用程式间的资料会有互相交换的需求。首先的压 力将来自於使用者，甚至於很可能是你自己。先不说别的，在写这篇文章时，我 就曾剪贴原来以 De1phi 撰写的理式到文书编辑软体，同时，也利用抓图软体帮 我拍下执行画面，最後，这些文章与范例程式得用压缩程式压起来，然後E-mai1 寄给杂志编辑。使用 IPC 在某些情况下是不得不然的决定，有时候程式必须跨过机器边界让另 部机器内的理式明白该怎麽合作来共同完成工作，这同时也暗示我们可能面临不 同的作业系统的问题。此外，IPC有助於系统的安全与稳定。由於Win32各个行程彼此独立的特性， 个 行程死掉了，其他的行程还可以继续跑下去，对於某些稳定性要求很高的系统而 言，值得以额外的负担 (Overhead) 交换系统的强固性 (robustness) 。嗯!我的意 思是说，因为系统对稳定性的需求要求较高，值得拆开来做甚至额外的备援系 统，既然工作拆成两个以上，此时必然需要IPC。关於IPC ，一般人可能会对其有 I 执行效率缓慢 J 的印象，这当然不能说是错误 的，但绝不是公平的评语。这麽说吧:一个主管亲自去做一件事，往往会比先说 明再授权下属去做来得快，这是单一工作时的情况;然而如果管理者同时有好几 件事在手上，托付别人去做才能使得整个公司的效能提高。换句话说，如果能善 用 IPC ，整体的系统效能不仅不会下降，反而可能因为充分利用整个运算群的能 力而有提升。我们的第一个 IPC 例子每个图形介面的视窗应用程式都接受并处理讯息 (Message) ，因此，使用讯息伫列 通知其他的行程是脑中很自然会浮现的第 个想法:换句话说，两行程问彼此互 相以 SendMessage 0 或 PostMessage 0 传送讯息通知对方。即然要互送讯息，就需要 个彼此都认得的讯息编号。於是，除了 Windows 标准 的讯息编号之外，我们还需要额外定义个(些)讯息。行程通讯问用来约定讯息编号常用的方法是呼叫RegisterWindowMessage() API 函 数。这个函数只有 个字串型别的引数，Windows系统会检查我们传入的讯息名称 并传回 个安全不重覆的讯息编号，假如传入的讯息名称早已经登记有案，则系 统传回的是稍早传给那个行梧的相同编号。换句话说，两支程式只要彼此都用相同的讯息名称呼叫RegisterWindowMessage()注册讯息，系统便会都给两者 个相同的自订讯息编号。接下来要送出讯息了，可是，要送给谁呢?嗯，我在这使用的方法是:第 次先 用广播的，每 个视窗程式都会收到通知，讯息的短会数 (wParam) 中写明发讯视 窗的 Handle 值，如果是同志，它自然明白这个讯息代表了什麽，并且也使用 SendMessage 0 回送约定的讯息表示收到。同样的，讯息的短会数注明自己的 Handle。於是，茫茫人海的小俩口终於得知对方的下落，以後就不再需要公开寻 人可以透过Handle值直接与对方联络了。除了讯息编号，讯息的wParam， lParam长短会数也可以用来进 步约定通讯的细 节。事情进展得似乎十分顺利，现在我们知道合作对象，也确信它明白我们的讯 息代表什麽。虽然简单，但是这种暗通款曲的方式是系统默许的。不过，我们还 需要再多解决个问题。由於SendMessage 只有 wParam ， lParam 两个 DWORD 型别的长短会数，携带的资 料量十分有限。很显然的，我们需要能够 次传送更多资料的方法。Windows 也 的确提供了许多交换资料的机制，我在这篇文章中将会 说明，其中最简便的 方法是使用阳 COPYDATA 讯息，作法如下·将资料内容指定到COPYDATASTRUCT 这个资料结构中。.必须使用SendMessage 0送出阳 ωPYDATA讯息，讯息的短会数是发讯端视 窗的Handle值，长会数的内容则是指向COPYDATASTRUCT的指标。·受讯端行程收到讯息时，以长会数提供的线索