最近评论
正在载入评论列表...
3.5为什么GetWindowText的规则如此奇怪
让我们把时光机器（wayback machine）倒回1983年，当时个人电脑中的配置通常是8086的处理器，主频47MHz，两个360K的51/4英寸软盘驱动器（如果你很富有的话，也可能是一个软盘驱动器和一个10MB的硬盘驱动器），以及256KB内存。
这就是Windows 1.0在当时所处的情况。
Windows 1.0是一个协作式多任务（cooperatively multitasked）操作系统，并没有抢先式多任务（preemptive multitasking）的概念。如果程序得到了系统的控制权，那么它可以想占有多久，就占有多久。只有当你调用像PeekMessage或者GetMessage这样的函数时，才会将控制权转交给其他的应用程序。
这是很重要的，因为在缺少硬件内存管理器的情况下，你需要特别确保不会在内存使用上出现问题。
在协作式多任务操作系统中，很重要的一点是，如果你的程序正在运行，那么你就不仅要知道没有其他的程序在运行，而且还要知道每个窗口都会响应消息。为什么？因为如果这些窗口挂起了，那么你将无法得到系统控制权！
这意味着发送消息将总是安全的。你永远都不用担心将消息发送给一个挂起的窗口，因为你很清楚不会存在挂起的窗口。
因此，在Windows 1.0这个简单的系统中，GetWindowText函数是非常直接了当的：
对于所有的窗口，以上代码无论在什么时候都是有效的。对于不同进程中的窗口并没有进行特殊处理。
当操作系统过渡到Win32时，抢先式多任务的方式强行改变了这个规则，此时，你想要进行通信的窗口可能不会对消息进行响应。
现在，你就遇到了一个向后兼容性的问题。正如前面的描述，系统的许多组件和程序都要求在获取窗口文本时不会遇到挂起的情况。因此，如何才能够实现在获取窗口文本时不会遇到挂起的情况，而同时又可以让一些控件（例如编辑控件等）能够进行自定义的文本管理工作？
在Win32中GetWindowText函数的规则正是为了解决这个相互矛盾的目标而制定的。
图书导读
