第三章 Win32应用程序设计

第三章Win32应用程序设计

在过去，进行Windows程序设计是一件痛苦异常的事情，原因是那时候还没有现在的这些设计精美的应用程序开发工具。在今天，一个对Windows程序运行的内部机制几乎一无所知的初入门者，只需要通过不到一天的学习，也可以使用如Visual Basic之类的程序开发工具创建出功能完整的Windows应用程序。这在几年前还是一件不可思议的事，因为即使是一个熟练掌握C语言的程序员，在当时差不多需要半年的学习才可以较全面的掌握Windows 的编程技术，而且，与在DOS环境下编程相比，急剧膨胀的程度代码大大增加了程序调试的困难，从而使得编写一个出色的Windows应用程序要比编写一个出色的DOS需要考虑多得多的东西。

在Microsoft的另一种易学易用的编程工具Visual Basic中，从某种角度说，Windows程序不是编出来的，而是由程序员画出来的。但是要知道，一个出色的Windows的应用程序并不仅在于在屏幕上绘出程序的各个窗口和在窗口中恰当的安排每一个控件。对于具有一定基础的程序员而言，更重要的内容在于知道Windows和Windows应用程序的运行机制，以及它们之间以何种方式来进行通信，然而，明确自己在编写Windows时所需做的工作是哪一些。换句话说，我们需要透过Windows漂亮的图形用户界面，认清在底层所发生的每一件事情。然而，这并非是一件容易的事。虽然，使用MFC和AppWizard，我们仍可能只需要回答几个简单的问题和添加少数的几条代码就能够生成功能完整的Windows应用程序。但是记住，没有一个成功的商业软件是使用这样的方式生成的。同时，也只有深入的理解了MFC应用程序框架的运行机制，才可能用好和用活这一工具，才能达到熟悉掌握VisualC++的境界。

尽管说MFC应用程序框架提供的是面向对象的Windows编程接口，这和传统的使用C语言和SDK来进行的Windows应用程序设计有着很大的不同，但是从底层来说，其中的大部分功能仍是通过调用最基本的Win32 API 来实现的。其中最重要的一点是，Windows应用程序的运行机制仍然没有改变，它们仍然是通过消息来和操作系统，进而和用户进行交互的事件驱动的应用程序。MFC对这一切进行了比较彻底的封装，它们隐藏在你所看不见的背面。即使你对这一切一无所知，你仍可以在Visual C++中使用MFC来进行程序设计。但是，经验表明，理解这一切的最好的方式是回过头去，看一看这些内容在SDK编写的应用程序是如何实现的，然后，再看一看在MFC中是如何把它们一层一层的与程序员隔离开的。

因此，在本章中介绍相对已“过时”的Win32 SDK编程，并非是说以后也使用SDK来编写应用程序，而在于让你通过它们更深入的从MFC的内部了解MFC，并且，对于某些术语和概念的说明和澄清，也有助于你以后理解很多的东西。如果你一开始对这些东西不感兴趣，那么，你可以先暂时跳过此章，继续阅读本书的其它部分。当你对于MFC中的某些问题感到不解，或者想知道MFC究竟是如何工作的时候，再回过头来补充这些知识，也是完全可以的。

本章包括以下的内容：

W indows应用程序的消息处理

W in32 API和SDK

W inMain函数

窗口和窗口过程

32位编程的特点

第一节事件驱动的应用程序

类似的话已在很多书籍中说过了无数遍，以至于每一个正在或试图进行Windows编程的人都耳熟能详：Windows 应用程序是事件驱动(或称作消息驱动)的应用程序。Windows是一个多任务的操作系统，也就是说，在同一时刻，在Windows中有着多个应用程序的实例正在运行，比如说这时我正在打开字处理软件Word来编写这本书的书稿，同时，还打开了Visual C++的集成开发环境Microsoft Developer Studio来调试书中的示例程序，而且，后台还在放着歌曲。在这样的一个操作系统中，不可能像过去的DOS那样，由一个应用程序来享用所有的系统资源，这些资源是由Windows统一管理的。那么，特定的应用程序如何获得用户输入的信息呢？事实上，Windows时刻监视着用户的一举一动，并分析用户的动作与哪一个应用程序相关，然后，将用户的动作以消息的形式发送给该应用程序，应用程序时刻等待着消息的到来，一但发现它的消息队列中有未处理的消息，就获取并分析该消息，最后，应用程序根据消息所包含的内容采取适当的动作来响应用户所作的操作。举一个例子来说明上面的问题，假设我们编了一个程序，该程序有一个File菜单，那么，在运行该应用程序的时候，如果用户单击了File菜单，这个动作将被Windows (而不是应用程序本身！)所捕获，Windows经过分析得知这个动作应该由上面所说的那个应用程序去处理，既然是这样，Windows就发送了个叫做WM_COMMAND的消息给应用程序，该消息所包含的信息告诉应用程序：“用户单击了File菜单”，应用程序得知这一消息之后，采取相应的动作来响应它，这个过程称为消息处理。Windows为

每一个应用程序(确切地说是每一个线程)维护了相应的消息队列，应用程序的任务就是不停的从它的消息队列中获取消息，分析消息和处理消息，直到一条接到叫做WM_QUIT消息为止，这个过程通常是由一种叫做消息循环的程序结构来实现的。

Windows所能向应用程序发送的消息多达数百种，但是，对于一般的应用程序来说，只是其中的一部分有意义，举一个例子，如果你的应用程序只使用鼠标，那么如WM_KEYUP、WM_KEYDOWN和WM_CHAR等消息就没有任何意义，也就是说，应用程序中事实上不需要处理这些事件，对于这些事件，只需要交给Windows作默认的处理即可。因此，在应用程序中，我们需要处理的事件只是所有事件中的一小部分。

图3.1给出了一般Windows应用程序的执行流程。

图3. 1 Windows应用程序的基本流程

因此，从某种角度上来看，Windows应用程序是由一系列的消息处理代码来实现的。这和传统的过程式编程方法很不一样，编程者只能够预测用户所利用应用程序用户界面对象所进行的操作以及为这些操作编写处理代码，却不可以这些操作在什么时候发生或者是以什么顺序来发生，也就是说，我们不可能知道什么消息会在什么时候以什么顺序来临。

Windows程序在处理消息时使用了一种叫做回调函数(callbackfunction)的特殊函数。回调函数由应用程序定义，但是，在应用程序中并没有调用回调函数的代码，回调函数是供操作系统或者其子系统调用的，这种调用通常发生在某一事件发生，或者在窗口或字体被枚举时。典型的回调函数有窗口过程、对话框过程和钩子函数。其中的窗口过程和对话框过程将在本章后面的内容中讲述。

第二节Win32 API和SDK

说到Windows编程，就不能不谈到Windows API (WindowsApplication Programming Interface，Windows应用程序编程接口)，它是所有Windows应用程序的根本之所在。简单的说，API就是一系列的例程，应用程序通过调用这些例程来请求操作系统完成一些低级服务。在Windows这样的图形用户界面中，应用程序的窗口、图标、菜单和对话框等就是由API来管理和维护的。

Windows API具有两种基本类型：Win16 API和Win32 API。两者在很多方面非常相像，但是Win32 API除了几乎包括了Win16 API中的所有内容以外，还包括很多的其它内容。Windows API依靠三个主要的核心组件提供Windows 的大部分函数，在Win16和Win32中，它们具有不同的名称，如表3.1所示。