windows程序设计windows环境经典著.doc

windows程序设计 windows环境 经典著windows程序设计(windows环境)(经典著作，本人修改)2010-11-19 18：16本书介绍在Windows下编程的方法。这些程序都采用C语言与原始的Windows API来编写。虽然用C与API不是编写Windows程序的唯一方法。但无论最终您使用什么方式编程，了解Windows API都是非常重要的。读此书有三个先决条件：第一，您应该熟悉使用Windows xp。第二，您应了解C语言。如果要写Windows程序，一开始却不想了解C语言，那不是一个好主意。我建议您在控制台环境中，例如在MS-DOS命令提示窗口下学习C语言。Windows程序设计有时包括一些非文字模式程序设计的部分；在这些情况下，我将针对这些问题单独讨论。所以，您应非常熟悉C语言，特别是C语言的结构和指针。了解标准C语言执行期链接库的一些相关知识是有帮助的，但不是必要的。第三，您应该在机器上安装Microsoft Visual C+6.0。至止，不需您具有任何Windows程序的写作经验。Windows简史在1981年秋天IBM PC推出不久，MS-DOS就已经很明显成为PC上的主流操作系统。MS-DOS代表Microsoft Disk Operating System(磁盘操作系统)。MS-DOS是一个小型的操作系统。MS-DOS提供给用户一种命令行接口，提供诸如DIR和TYPE等命令，也可以将应用程序加入内存执行。对于应用程序写作者，它提供了一组用于文件的输入输出(I/O)函数。对于其它的外围处理-尤其是将文字或图形写到显示器上-应用程序可以直接存取PC的硬件。当苹果计算机公司的Lisa计算机在1983年1月发布时，它提供了不同于文字模式环境的另一种选择，并在1984年1月成为Macintosh上图形环境的一种标准。尽管Macintosh的市场占有率在下降，但是它仍然被认为是衡量所有其它图形环境的标准。Windows是由微软在1983年11月(在Lisa之后，Macintosh之前)宣布，并在两年后(1985年11月)发行。在此后的两年中，紧随着Microsoft Windows早期版本1.0之后，又推出了几种改进版本，以支持国际商业市场，并提供新型显示器和打印机的驱动程序。Windows2.0是在1987年11月正式推出市场的。该版本对用户界面做了一些改进。这些改进中最有效的是使用了可重迭式窗口，而Windows 1.0中使用的是并排式窗口。Windows 2.0还增强了键盘和鼠标接口，特别是加入了菜单和对话框。至此，Windows还只需要Intel 8086或者8088等级的cpu，以实模式执行，能存取地址在1MB以下的内存。Windows/386(在Windows 2.0之后不久发行的)使用Intel 386微处理器的虚拟8086模式，实现将直接存取硬件的多个MS-DOS程序窗口化和多任务化。为了统一起见，Windows版本2.1被更名为Windows/286。Windows 3.0是在1990年5月22日发表的。它将Windows/286和Windows/386结合到同一种产品中。Windows 3.0有了一个很大的改变，这就是对Intel的286、386和486微处理器保护模式的支持。这能使Windows和Windows应用程序能存取高达16MB的内存。Windows用于执行程序和维护文件的外壳程序得到了全面的改进。Windows 3.0是第一个在家用和办公室市场上取得成功的版本。任何Windows的历史介绍都必须包括一些OS/2的说明，OS/2是对DOS和Windows的另一种选择，最初是由Microsoft和IBM合作开发的。OS/2版本1.0(只有文字模式)在Intel 286(或者后来的)微处理器上运行，在1987年末发布。在1988年10月的OS/2版本1.1中出现了管理图形使用界面的PM(Presentation Manager)。PM最初的设计构想是成为Windows的一种保护模式版本，但是图形API改变程度太大，致使软件生产厂商很难提供对这两种平台的支持。到1990年9月，IBM和Microsoft之间的冲突达到了高峰，导致这两个公司最后分道扬镳。IBM接管了OS/2，而Microsoft明确表示Windows将是他们操作系统策略核心。虽然OS/2仍然拥有一些狂热的崇拜者，但是它远不及Windows这样的普及程度。Microsoft Windows3.1是1992年4月发布的，其中包括的几个重要特性是TrueType字体技术(给Windows带来可缩放的轮廓字体)、多媒体(声音和音乐)、对象连结和嵌入(OLE：Object Linking and Embedding)和通用对话框。跟OS/2一样，Windows 3.1只能在保护模式下运作，并且要求至少配置了1MB内存的286或386处理器。在1993年7月发表的Windows NT是第一个支持Intel 386、486和Pentium微处理器32位保护模式的Windows版本。Windows NT提供32位平坦寻址，并使用32位的指令集。(本章后面我会谈到一些寻址空间的问题)。Windows NT还可以移植到非Intel处理器上，并在几种使用RISC芯片的工作站上执行。Windows 95是在1995年8月发布的。和Windows NT一样，Windows 95也支持Intel 386或更高等级处理器的32位保护模式。虽然它缺少Windows NT中的某些功能，诸如高安全性和对RISC机器的可移植性等，但是Windows 95具有较少硬件资源的优点。Windows 98在1998年6月发布，具有许多加强功能，包括执行效能的提高、更好的硬件支持以及与因特网和全球信息网(WWW)更紧密的结合。Windows方面Windows 98和Windows NT都是支持32位优先权式多任务(preemptive multitasking)及多线程的图形操作系统。Windows拥有图形用户接口(GUI)，这种用户界面也称作可视化接口或图形窗口环境。有关GUI的概念可追溯至70年代中期，在Alto和Star等机器上以及SmallTalk等环境中由Xerox PARC所作的研究工作。该项研究的成果后来被Apple Computer和Microsoft引入并流行起来。虽然有一些争议，但现在已非常清楚，GUI是一个在个人计算机工业史上集各方面技术大成于一体的最重要产物。所有GUI都在点矩阵对应的视频显示器上处理图形。图形提供了使用屏幕的最佳方式、传递信息的可视化，以及能够所见即所得的图形视频显示和为书面文件准备好格式化文字输出内容等。在早期，显示器仅用于响应用户通过键盘输入的文字。在图形界面中，显示器自身成为使用者输入的一个来源。显示器以图标和输入设备(例如按钮和滚动条)的形式显示多种图形对象。使用者可以使用键盘(或者更直接地使用鼠标等指向设备)直接在屏幕上操纵这些对象，拖动图形对象、按下鼠标按钮以及滚动滚动条。因此，用户与程序的交流变得更为亲密。这不再是一种从键盘到程序，再到显示器的单向信息流动，使用者已经能够与显示器上的对象直接交互作用了。于是使用者不再需要花费长时间学习如何使用计算机或掌握新的程序了。Windows让这一切成真，因为所有应用程序都有相同的基本外观和感觉。程序占据一个窗口-屏幕上的一块矩形区域。每个窗口由一个标题列标识。大多数程序功能由程序的菜单开始。用户可使用滚动条观察那些无法在一个屏幕中装下的信息。某些菜单项目触发对话框，用户可在其中输入额外的信息。几乎在每个大的Windows程序中都有一个用于开启文件的特殊对话框。该对话框在所有这些Windows程序中看起来都一样(或接近相同)，而且几乎总是从同一菜单选项中启动。一旦您了解了一个Windows程序的使用方法，您就会非常容易的学会其它的Windows程序。菜单和对话框允许用户试验一个新程序并探究它的功能。大多数Windows程序同时具有键盘接口和鼠标接口。虽然Windows程序的大多数功能可通过键盘控制，但使用鼠标要容易得多。从程序写作者的角度看，一致的用户接口来自于Windows建构菜单和对话框的内置程序。所有菜单都有同样的键盘和鼠标接口，因为这项工作是由Windows处理，而不是由应用程序处理。为便于多个程序的使用，以及这些程序间信息的交换，Windows支持多任务。在同一时刻能有多个Windows程序显示并运行。每个程序在屏幕上占据一个窗口。用户可在屏幕上移动窗口，改变它们的大小，在不同程序间切换，并从一个程序向另一个程序传送数据。因为这些窗口看起来有些像桌面上的纸(当然，这是计算机还未占据办公桌之前的年代)，Windows有时被称作：一个显示多个程序的桌面。Windows的早期版本使用一种非优先权式(non-preemptive)的多任务系统。这意味着Windows不使用系统定时器将处理时间分配给系统中运行的多个应用程序，程序必须自愿放弃控制权以便其它程序运行。在Windows NT和Windows 98中，多任务是优先权式的，而且程序自身可分割成近乎同时执行的多个执行体。操作系统不对内存进行管理便无法实现多任务。当新程序启动、旧程序终止时，内存会出现碎裂空间。系统必须能够将闲置的内存空间组织在一起，因此系统必须能够移动内存中的程序代码和数据块。即使是在8088微处理器上跑的Windows 1.0也能进行这类内存管理。在实际模式限制下，这种能力被认为是软件工程一个令人惊讶的成就。在Windows 1.0中，PC硬件结构的640KB内存限制，在不要求任何额外内存的情况下被有效地扩展了。但Microsoft并未就此停步：Windows 2.0允许Windows应用程序存取扩充内存(EMS)；Windows 3.0在保护模式下，允许Windows应用程序存取高达16MB的扩展内存。Windows NT和Windows 98通过成熟的32位操作系统及平坦寻址空间，摆脱了这些旧的限制。Windows上执行的程序可共享在称为动态链接库的文件中的例程。Windows包括一个机制，能够在执行时连结使用动态链接库中例程的程序。Windows自身基本上就是一个动态链接库的集合。Windows是一个图形接口，Windows程序能够在显示器和打印机上充分利用图形和格式化文字。图形接口不仅在外观上更有吸引力，而且还能够让使用者传递高层次的信息。Windows应用程序不能直接存取设备硬件。然而，Windows提供了一种图形设备接口(GDI)，使显示图形和格式化文字更容易。Windows虚拟化了显示硬件，使为Windows编写的程序可使用任何具有Windows设备驱动程序的视频卡或打印机，而程序无需确定系统相连的设备类型。对Windows开发者来说，将与设备无关的图形接口输出到IBM PC上不是件轻松的事。PC的设计是基于开放式架构的原则，鼓励第三方硬件制造商为PC开发接口设备，而且开发了大量这样的设备。虽然出现了多种标准，PC上的传统MS-DOS程序仍不得不各自支持许多不同的硬设备。这对MS-DOS字处理软件来说非常普遍，它们连同1到2张有许多小文件的磁盘一同销售，每个文件支持一种特定的打印机。Windows程序不要求每个应用程序都自行开发这些驱动程序，因为这种支持是Windows的一部分。动态链接Windows运作机制的核心是一个称作动态链接的概念。Windows为应用程序提供了丰富的API函数，大多数用于实现其用户接口和在显示器上显示文字和图形。这些函数采用动态链接库(Dynamic Linking Library，DLL)的方式撰写。这些动态链接库是些具有.DLL或者有时是.EXE扩展名的文件，在Windows 98中通常位于WINDOWSSYSTEM子目录中，在Windows NT中通常位于WINNTSYSTEM和WINNTSYSTEM32子目录中。在早期，Windows的主要部分仅通过三个动态链接库实现。这代表了Windows的三个主要子系统，它们被称作Kernel、User和GDI。当子系统的数目在Windows最近版本中增多时，大多数典型的Windows程序产生的函数调用仍对应到这三个模块中。Kernel(日前由16位的KRNL386.EXE和32位的KERNEL32.DLL实现)处理所有在传统上由操作系统核心处理的事务-内存管理、文件I/O和多任务管理。User(由16位的USER.EXE和32位的USER32.DLL实作)指用户接口，实现所有窗口操作。GDI(由16位的GDI.EXE和32位的GDI32.DLL实作)是一个图形设备接口，允许程序在屏幕和打印机上显示文字和图形。Windows 98提供上千种函数调用。每个函数都有一个描述名称，例如CreateWindow。该函数(如您所猜想的)为程序建立新窗口。所有应用程序可以使用的Windows函数都在表头文件里预先声明过了。在Windows程序中，使用Windows函数的方式通常与使用如strlen等C语言链接库函数的方式相同。主要的区别在于C语言链接库函数的代码连结到您的程序代码中，而Windows函数的程序代码在您程序执行文件外的DLL中。当您执行Windows程序时，它通过一个称作动态链接的方式与Windows相接。当Windows程序被加载到内存中时，程序中的调用被指向DLL函数的入口。如果该DLL不在内存中，就把它加载到内存中。当您产生一个可执行文件时，您必须连结程序开发环境提供的特定引用链接库(import library)。这些引用链接库包含了动态链接库名称和所有Windows函数的引用信息。连结程序使用该信息在.EXE文件中建立一个表格，在加载程序时，Windows使用它将呼叫转换为Windows函数。WINDOWS程序设计选项为说明Windows程序设计的多种技术，本书提供了许多范例程序。这些程序使用C语言撰写并原原本本的使用Windows API来开发程序。我将这种方法称作古典Windows程序设计。这是我们在1985年的Windows程序的方法，但它今天仍是编写Windows程序的有效方法。API和内存模式对于程序写作者来说，API是由操作系统定义的。API包含了所有应用程序能够使用的windows函数，同时包含了相关的数据类型和结构。在Windows中，API还意味着一个特殊的程序架构，我们将在每章的开头进行研究。一般而言，Windows API自Windows 1.0以来一直保持一致，没什么重大改变。具有Windows 98程序编程经验的程序员会对Windows 1.0程序的原始码感觉非常熟悉。API改变的方式就是进行增强。Windows 1.0支持不到450个函数调用，现在已有了上千种函数调用。Windows API和它的语法的最大变化来自于从16位架构向32位架构转化的过程中。Windows从版本1.0到版本3.1使用16位Intel 8086、8088、和286微处理器上所谓的分段内存模式，由于兼容性的原因，从386开始的32位Intel微处理器也支持该模式。在这种模式下，微处理器缓存器的大小为16位，因此C的int数据型态也是16位宽。在分段内存模式下，内存地址由两个部分组成-一个16位段(segment)指针和一个16位偏移量(offset)指标。从程序写作者的角度看，这非常凌乱并带来了long或far指针(包括段地址和偏移量地址)和short或near指标(包括带有假定段地址的偏移量地址)的区别。从Windows NT和Windows 95开始，Windows支持使用Intel 386、486和Pentium处理器32位模式下的32位平坦寻址内存模式。C语言的int数据型态也扩展为32位的值。为32位版本Windows编写的程序使用简单的平坦线性空间寻址的32位指针值。用于16位版本Windows的API(Windows 1.0到Windows 3.1)现在称作Win16。用于32位版本Windows的API(Windows 95、Windows 98和所有版本的Windows NT)现在称作Win32。许多函数调用在从Win16到Win32的转变中保持相同，但有些需要增强。例如，图像坐标点由Win16中的16位值变为Win32中的32位值。此外，某些Win16函数返回一个包含在32位整数值中的二维坐标点。这在Win32中不可能，因此增加的新函数以不同方式运作。所有32位版本的Windows都支持Win16 API(以确保和旧有应用程序兼容)和Win32 API(以运行新应用程序)。非常有趣的是，Windows NT与Windows 95及Windows 98的工作方式不同。在Windows NT中，Win16函数通过一个转换层被转化为Win32函数，然后被操作系统处理。在Windows 95和Windows 98中，该操作正相反：Win32函数通过转换层转换为Win16函数，再由操作系统处理。现在，Windows都能够支持Win32 API。然而，每个操作系统依然都支持某些不被别的操作系统支持的某些功能特性。因为它们的相同之处是相当可观的，所以有可能编写在两个操作系统下都可执行的程序。而且，人们普遍认为这两个产品最终会合而为一。语言选项使用C语言和原始的API不是编写Windows 98程序的唯一方法。然而，这种方法却能提供给您最佳的性能、最强大的功能和在发掘Windows特性方面最大的灵活性。可执行文件相对较小且运行时不要求外部链接库(自然，Windows DLL自身除外)。最重要的是，不管您最终以什么方式开发Windows应用程序，熟悉API会使您对Windows内部有更深入的了解。了解越深入，应用越自如。虽然我认为学习古典的Windows程序设计对任何Windows程序写作者都是重要的，但我不建议使用C和API编写每个Windows应用程序。许多程序员，特别是那些为公司内部开发程序或在家编写娱乐程序的程序员喜欢轻松的开发环境，例如Microsoft Visual Basic或者Borland Delphi(它结合了对象导向的Pascal版本)。这些环境使程序员将精力集中于应用程序的用户界面和相关用户接口对象的程序代码上。在专业程序员中，特别是那些开发商业应用程序的程序员-Microsoft Visual C+和Microsoft Foundation Class Library(MFC)是近年来流行的选择。MFC在一组C+对象类别中封装了许多Windows程序设计中的琐碎细节。最近，Internet和World Wide Web的流行大力推广着Sun Microsystems的Java，这是一个受C+启发却与微处理器无关的程序设计语言，而且结合了可在几个操作系统平台上执行的图形应用程序开发工具组。显然，很难说哪种方法更有利于开发Windows应用程序。更主要的是，也许是应用程序自身的特性决定了所使用的工具。不管您最后实际上使用什么工具写作程序，学习Windows API将使您更深入地了解Windows工作的方式。Windows是一个复杂的系统，在API上增加一个程序写作层并未减少它的复杂性，仅仅是掩盖了它，早晚您会碰到它。了解API会给您更好的补救机会。在原始的Windows API之上的任何软件层都必定将您限制在全部功能的一个子集内。您也许发现，例如，使用Visual Basic编写应用程序非常理想，然而它不允许您做一个或两个很简单的基本工作。在这种情况下，您将不得不使用原始的API。API定义了作为Windows程序员所需的一切。没有什么方法比直接使用API更万能的了。MFC尤其问题百出。虽然它大幅简化了某些工作(例如OLE)，我却经常发现要让它们按我所想的去工作时，就会在其它特性(例如Document/View架构)上碰壁。MFC还不是Windows程序设计者所追求的灵丹妙药，很少有人认为它是一个好的对象导向设计的模型。然而MFC程序员对MFC的对象类别定义受益颇深，并会在编程时经常参考MFC原码，然而要搞懂这些原码就必须学习Windows API。程序开发环境Microsoft Visual C+6.0中包括C编译器和其它编译及连结Windows程序所需的文件和工具等。它还包括一个可编辑原始码、以交谈方式建立资源(如图标和对话框)以及编辑、编译、执行和测试程序的环境。API文件本书不是Windows API权威的正式文件的替代品。当您安装Visual C+6.0时，您将得到一个包括API文件的在线求助系统。您可通过订阅MSDN或使用Microsoft网站上的在线求助系统更新该文件。连接到，并选择MSDN Library Online。在Visual C+6.0中，从Help菜单项选择Contents项目开启MSDN窗口。API文件按树形结构组织，寻找标有Platform SDK的部分，所有在本书中引用的文件都来自于该部分。我将向您介绍如何从Platform SDK开始寻找以斜线分层分门别类的文件的位置。(我知道Platform SDK是整个MSDN知识库中较为晦涩的部分，但我敢保证那是Windows程序设计的基本核心。)例如，对于如何在Windows程序中使用鼠标的文件，您可参考/Platform SDK/User Interface Services/User Input/Mouse Input。我在前面提到Windows大致分为Kernel、User和GDI子系统。kernel接口在/Platform SDK/Windows Base Services中，User界面函数在/Platform SDK/User Interface Services中，GDI位于/Platform SDK/Graphics and Multimedia Services/GDI中。编写第一个WINDOWS程序现在是开始写些程序的时候了。为了便于对比，让我们以一个非常短的Windows程序和一个简短的文字模式程序开始。这会帮助我们找到使用开发环境并感受建立和编译程序机制的正确方向。文字模式(Character-Mode)模型程序员们喜爱的一本书是The CProgramming Language(Prentice Hall，1978年和1988年)，由Brian W.Kernighan和Dennis M.Ritchie(亲切地称为K&R)编著。该书的第一章以一个显示hello,world的C语言程序开始。这里是在The CProgramming Language第一版第6页中出现的程序：main()printf(hello,worldn)；以前C程序员在使用printf等C执行期链接库函数时，无需先声明它们。但现在，我们愿意给编译器一个在我们的程序中标出错误的机会。这里是在K&R第二版中修正的程序：#include stdio.h main()printf(hello,worldn)；该程序仍然是那么短。但它可通过编译并执行得很好，但当今许多程序员更愿意清楚地说明main函数的返回值，在这种情况下ANSI C规定该函数必须返回一个值：#include stdio.h int main()printf(hello,worldn)；return 0；我们还可以包括main的参数，把程序弄得更长一些，但让我们暂且这样就好了-包括一个include声明、程序的进入点、一个执行期链接库声明和一个return语句。同样效果的Windows程序Windows关于hello,world程序的等价程序有和文字模式版本完全相同的组件。它有一个include声明、一个程序进入点、一个函数调用和一个return语句。下面便是该程序：/*-HelloMsg.c-DisplaysHello,Windows 98！in amessage box(c)Charles Petzold,1998-*/#include windows.h int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,PSTR szCmdLine,int iCmdShow)MessageBox(NULL,TEXT(Hello,Windows 98！),TEXT(HelloMsg),0)；return 0；在剖析该程序之前，让我们看一下在Visual C+Developer Studio中建立新程序的方式。首先，从File菜单中选New。在New对话框中，单击Projects页面标签，选择Win32 Application。在Location栏中，选择一个子目录，在Project Name栏中，输入该项目的名称，此时该名称是HelloMsg，这便是在Location栏中显示的目录的子目录。Create New Workspace复选框应该勾起来，Platforms部分应该显示Win32，选择OK。将会出现一个标题为Win32 Application-Step 1Of 1的对话框，指出要建立一个Empty Project，并按下Finish按钮。从File菜单中再次选择New。在New对话框中，选择Files页面标签，选择C+Source File。Add To Project复选框应被选中，并应显示HelloMsg。在File Name栏中输入HelloMsg.c，选中OK。现在您可输入上面所示的HELLOMSG.C文件，您也可以选择Insert菜单和File As Text选项从本书附带的CD-ROM上复制HELLOMSG.C的内容。从结构上说，HELLOMSG.C与K&R的hello,world程序是相同的。表头文件STDIO.H已被WINDOWS.H所代替，进入点main被WinMain所代替，而且C语言执行时期链接库函数printf被Windows API函数MessageBox所代替。然而，在程序中有许多新东西，包括几个陌生的大写标识符。让我们从头开始。头文件HELLOMSG.C以一个前置处理器指示命令开始，实际上在每个用C编写的Windows程序的开头都可看到：#include windows.h WINDOWS.H是主要的含入文件，它包含了其它Windows头文件，这些头文件的某些也包含了其它头文件。这些头文件中最重要的和最基本的是：WINDEF.H基本型态定义。WINNT.H支持Unicode的型态定义。WINBASE.H Kernel函数。WINUSER.H用户接口函数。WINGDI.H图形设备接口函数。这些头文件定义了Windows的所有数据类型、函数定义、数据结构和常数标识符，它们是Windows文件中的一个重要部分。使用Visual C+Developer Studio的Edit菜单中的Find in Files搜索这些头文件非常方便。您还可以在Developer Studio中打开这些头文件并直接阅读它们。程序进入点正如在C程序中的进入点是函数main一样，Windows程序的进入点是WinMain，总是像这样出现：int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,PSTR szCmdLine,int iCmdShow)该进入点在/Platform SDK/User Interface Services/Windowing/Windows/Window Reference/Window Functions中有说明。它在WINBASE.H中声明如下：int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nShowCmd)；您会注意到我在HELLOMSG.C中做了许多小改动。第三个参数在WINBASE.H中定义为LPSTR，我将它改为PSTR。这两种数据型态都定义在WINNT.H中，作为指向字符串的指针。LP前缀代表长指针，这是16位Windows下的产物。我还在WinMain声明中改变了两个参数的名称。许多Windows程序中的变量名使用一种称作匈牙利表示法的命名系统，该系统在变量名称前面增加了表示变量数据型态的短前缀，我将在第三章更详细地讨论这个概念。现在仅需记住前缀i表示int、sz表示以零结束的字符串。WinMain函数声明为返回一个int值。WINAPI标识符在WINDEF.H定义，语句如下：#define WINAPI _stdcall该语句指定了一个调用约定，包括如何生产机械码以在堆栈中放置函数的参数。许多Windows函数声明为WINAPI。WinMain的第一个参数被称作执行实例句柄。在Windows程序设计中，句柄仅是一个应用程序用来识别某些东西的数字。在这种情况下，该句柄唯一地标识该程序，还需要它在其它Windows函数中作为参数。在Windows的早期版本中，当同时运行同一程序多次时，您便创建了该程序的多个实例(multiple instances)。同一应用程序的所有实例共享程序和只读的内存(通常是例如菜单和对话框模板的资源)。程序通过检查hPrevInstance参数就能够确定自身以外的其它实例是否正在运行。然后它可以略过一些繁杂的工作并从前面的实例中将某些数据移到自己的数据区域。在32位Windows版本中，该概念已被抛弃。传给WinMain的第二个参数总是NULL(定义为0)。WinMain的第三个参数是用于执行程序的命令列。某些Windows应用程序利用它在程序启动时将文件加载内存。WinMain的第四个参数指出程序最初显示的方式，可以是正常的或者是最大化地充满整个画面，或者是最小化显示在工作列中。我们将在第三章中介绍使用该参数的方法。MessageBox函数MessageBox函数用于显示短信息。虽然，MessageBox显示的小窗口不具有什么功能，实际上它被认为是一个对话框。MessageBox的第一个参数通常是窗口句柄，我们将在第三章介绍其含义。第二个参数是在消息框主体中显示的字符串，第三个参数是出现在消息框标题列上的字符串。在HELLMSG.C中，这些文字字符串的每一个都被封装在一个TEXT宏中。通常您不必将所有字符串都封装在TEXT宏中，但如果想将您的程序转换为Unicode字符集，这确是一个好主意。我将在第二章详细讨论该问题。MessageBox的第四个参数可以是在WINUSER.H中定义的一组以前缀MB_开始的常数的组合。您可从第一组中选择一个常数指出希望在对话框中显示的按钮：#define MB_OK 0x 00000000L#define MB_OKCANCEL 0x 00000001L#define MB_ABORTRETRYIGNORE 0x 00000002L#define MB_YESNOCANCEL 0x 00000003L#define MB_YESNO 0x 00000004L#define MB_RETRYCANCEL 0x 00000005L如果在HELLOMSG中将第四个参数设置为0，则仅显示OK按钮。可以使用C语言的OR(|)操作符号将上面显示的一个常数与代表内定按钮的常数组合：#define MB_DEFBUTTON1 0x 00000000L#define MB_DEFBUTTON2 0x 00000100L#define MB_DEFBUTTON3 0x 00000200L#define MB_DEFBUTTON4 0x 00000300L还可以使用一个常数指出消息框中图示的外观：#define MB_ICONHAND 0x 00000010L#define MB_ICONQUESTION 0x 00000020L#define MB_ICONEXCLAMATION 0x 00000030L#define MB_ICONASTERISK 0x 00000040L这些图示中的某些有替代名称：#define MB_ICONWARNING MB_ICONEXCLAMATION#define MB_ICONERROR MB_ICONHAND#define MB_ICONINFORMATION MB_ICONASTERISK#define MB_ICONSTOP MB_ICONHAND虽然只有少数其它MB_常数，但您可以自己参考头文件或/