TONT 35193 为什么在Windows中有基于广播的消息机制？

原文链接：https://devblogs.microsoft.com/oldnewthing/20050627-00/?p=35193

Many Windows information mechanisms are based on message broadcasts, among them DDE, WM_FONTCHANGE, and changes in system settings. Why do these mechanisms use broadcasts, when we know that broadcasts can result in the system grinding to a halt due to windows that have stopped processing messages?

许多Windows中的信息机制都基于消息广播，其中包括DDE、WM_FONTCHANGE，以及系统设置的变更等。为什么这些机制在知晓可能会遇到已经停止处理消息的窗口，而将整个系统拖入挂起状态的前提下，还是要使用广播机制呢？

Because in 16-bit Windows, you didn’t have this problem.

因为在16位Windows环境下，这个问题是不存在的。

Recall that 16-bit Windows was co-operatively multi-tasking. When a program received control of the CPU, it could do anything it wanted, knowing that no other programs could run until it explicitly yielded control by calling a function such as GetMessage or PeekMessage. The downside of this, of course, was that a single hung program caused the entire system to hang, because it wasn’t releasing the CPU. The upside, however, was that if your program was running, then you knew, a priori, that there were no hung programs in the system. How do you know that? Because if there were a hung program, it would be running and not you. If there’s only one thing, and you have it, then you know that nobody else is hogging it. Therefore, broadcasting messages was completely safe in 16-bit Windows. You didn’t have to worry about non-responsive programs because you had proof that there weren’t any.

回忆一下，16位Windows是协作多任务机制。当某个程序获得了CPU的控制权后，它就可以想做什么做什么，因为它知道直到调用类似GetMessage或PeekMessage这样的方法来让渡（对CPU的）控制权之前，没有其它程序是可以同时运行的。这种设计的不足之处，在于一个程序挂起就会导致整个系统挂起，因为它没有释放对CPU的控制权。而这种设计的益处，则在于如果你的程序在正常运行，那么就可以先知先觉地知晓系统中没有其它挂起的程序。何以见得呢？因为如果如果有挂起的程序的话，那肯定是其它正在运行的程序、并且肯定不是你。如果某样东西只有独一份，而此时它在你的掌控下，你就知道肯定没有其它人在占有它。因此，广播机制在16位Windows环境下是绝对安全的，你不用担心有未响应的程序，因为你有证据证明没有这回事。

Of course, when the switch to pre-emptive multi-tasking occurred, this assumption no longer applied, but by then it was too late. The broadcast-based model was already in use, and consequently had to be preserved for compatibility reasons. (It would be bad if, for example, Lotus 1-2-3 stopped working on Windows NT because DDE broadcasts were no longer supported. If the Windows NT team had tried that gambit, nobody would have upgraded and Windows NT wouldn’t have survived to make a second version.)

自然，当抢占式多任务出现后，这样的猜测就再也无法成立了，但那时已经太晚了。基于广播的模型已经广泛应用，并且基于兼容性的原因还得予以保留。（举例来说，如果 Lotus 1-2-3（译注：1990年代流行的办公软件）由于 Windows NT 不再支持 DDE 广播而无法是用了，那将是一件很糟糕的事。如果 Windows NT 团队真这样下注的话，是不会有人为此而升级系统的，而 Windows NT 连活到第二个版本的机会都没有。）

On the other hand, given the risks involved in DDE broadcasts, you probably would be better off designing your program to not use dynamic data exchange as a data communication mechanism, thereby avoiding the pitfall of message broadcasts. No point contributing to the problem.

另一方面，由于DDE广播中存在的这些风险，你大概应当选择不要使用动态数据交换（DDE）作为你的应用的数据通讯机制，这样就可以避免由于消息广播（的缺点）而产生的坑了。为这种问题添砖加瓦是没有意义的。