Windows程序设计基础篇.docx
《Windows程序设计基础篇.docx》由会员分享，可在线阅读，更多相关《Windows程序设计基础篇.docx（15页珍藏版）》请在冰豆网上搜索。
Windows程序设计基础篇
本文介绍了在MicrosoftWindows98、MicrosoftWindowsNT4.0和WindowsNT5.0下程式写作的方法。
这些程式用C语言编写并使用原始的WindowsApplicationProgrammingInterface（API）。
如在本章稍後所讨论的，这不是写作Windows程式的唯一方法。
然而，无论最终您使用什么方式写作程式，了解WindowsAPI都是非常重要的。
正如您可能知道的，Windows98已成为使用Intel32位元微处理器（例如486和Pentium）的IBM相容型个人电脑环境上最新的图形作业系统之代表。
WindowsNT是IBMPC相容机种以及一些RISC（精简指令集电脑）工作站上使用的Windows工业增强型版本。
使用本书有三个先决条件。
首先，您应该从使用者的角度熟悉Windows98。
不要期望可以在不了解Windows使用者介面的情形下开发其应用程式。
因此，我建议您在开发程式（或在进行其他工作）时使用执行Windows的机器来跑Windows应用程式。
第二，您应了解C语言。
如果要写Windows程式，一开始却不想了解C语言，那不是一个好主意。
我建议您在文字控制台环境中，例如在Windows98MS-DOS命令提示视窗下提供的环境中学习C语言。
Windows程式设计有时包括一些非文字模式程式设计的C语言部分；在这些情况下，我将针对这些问题提供讨论。
但大多数情况下，您应非常熟悉该语言，特别是C语言的结构和指标。
了解标准C语言执行期程式库的一些相关知识是有帮助的，但不是必要的。
第三，您应该在机器上安装一个适於进行Windows程式设计的32位元C语言编译器和开发环境。
在本书中，假定您正在使用MicrosoftVisualC++6.0，该套装软体可独立购买，也可作为VisualStudio6.0套装软体的一部分购买。
到此为止，我将不再假设您具有任何图形使用者介面（如Windows）的程式写作经验。
WINDOWS环境
Windows几乎不需要介绍。
然而人们很容易忘记Windows给办公室和家庭桌上型电脑所带来的重大改变。
Windows在其早期曾经走过一段坎坷的道路，征服桌上型电脑市场的前途一度相当渺茫。
Windows简史
在1981年秋天IBMPC推出之後不久，MS-DOS就已经很明显成为PC上的主流作业系统。
MS-DOS代表MicrosoftDiskOperatingSystem（磁碟作业系统）。
MS-DOS是一个小型的作业系统。
MS-DOS提供给用户一种命令列介面，提供如DIR和TYPE的命令，也可以将应用程式载入记忆体执行。
对於应用程式写作者，它提供了一组函式呼叫，进行档案的输入输出（I/O）。
对於其他的周边处理－尤其是将文字或图形写到显示器上－应用程式可以直接存取PC的硬体。
由於记忆体和硬体的限制，成熟的图形环境缓慢地才到来。
当苹果电脑公司不幸的Lisa电脑在1983年1月发表时，它提供了不同於文字模式环境的另一种选择，并在1984年1月成为Macintosh上图形环境的一种标准。
尽管Macintosh的市场占有率在下降，但是它仍然被认为是衡量所有其他图形环境的标准。
包括Macintosh和Windows的所有图形环境，其实都要归功於XeroxPaloAltoResearchCenter（PARC）在70年代中期所作的开拓性研究工作。
Windows是由微软在1983年11月（在Lisa之後，Macintosh之前）宣布，并在两年後（1985年11月）发行。
在此後的两年中，紧随著MicrosoftWindows早期版本1.0之後，又推出了几种改进版本，以支援国际商业市场，并提供新型视讯显示器和印表机的驱动程式。
Windows版本2.0是在1987年11月正式在市场上推出的。
该版本对使用者介面做了一些改进。
这些改进中最有效的是使用了可重叠式视窗，而Windows1.0中使用的是并排式视窗。
Windows2.0还增强了键盘和滑鼠介面，特别是加入了功能表和对话方块。
至此，Windows还只要求Intel8086或者8088等级的微处理器，以「实际模式」执行，只能存取位址在1MB以下的记忆体。
Windows/386（在Windows2.0之後不久发行的）使用Intel386微处理器的「虚拟8086」模式，实现将直接存取硬体的多个MS-DOS程式视窗化和多工化。
为了统一起见，Windows版本2.1被更名为Windows/286。
Windows3.0是在1990年5月22日发表的。
它将Windows/286和Windows/386结合到同一种产品中。
Windows3.0有了一个很大的改变，这就是对Intel的286、386和486微处理器保护模式的支援。
这能使Windows和Windows应用程式能存取高达16MB的记忆体。
Windows用於执行程式和维护档案的「外壳」程式得到了全面的改进。
Windows3.0是第一个在家用和办公室市场上取得立足点的版本。
任何Windows的历史介绍都必须包括一些OS/2的说明，OS/2是对DOS和Windows的另一种选择，最初是由Microsoft和IBM合作开发的。
OS/2版本1.0（只有文字模式）在Intel286（或者後来的）微处理器上运行，在1987年末发布。
在1988年10月的OS/2版本1.1中出现了管理图形使用者介面的PM（PresentationManager）。
PM最初的设计构想是成为Windows的一种保护模式版本，但是图形API改变程度太大，致使软体生产厂商很难提供对这两种平台的支援。
到1990年9月，IBM和Microsoft之间的冲突达到了高峰，导致这两个公司最後分道扬镳。
IBM接管了OS/2，而Microsoft明确表示Windows将是他们作业系统策略的中心。
虽然OS/2仍然拥有一些狂热的崇拜者，但是它远不及Windows这样的普及程度。
MicrosoftWindows版本3.1是1992年4月发布的，其中包括的几个重要特性是TrueType字体技术（给Windows带来可缩放的轮廓字体）、多媒体（声音和音乐）、物件连结和嵌入（OLE：
ObjectLinkingandEmbedding）和通用对话方块。
跟OS/2一样，Windows3.1只能在保护模式下运作，并且要求至少配置了1MB记忆体的286或386处理器。
在1993年7月发表的WindowsNT是第一个支援Intel386、486和Pentium微处理器32位元保护模式的Windows版本。
WindowsNT提供32位元平坦定址，并使用32位元的指令集。
（本章後面我会谈到一些定址空间的问题）。
WindowsNT还可以移植到非Intel处理器上，并在几种使用RISC晶片的工作站上执行。
Windows95是在1995年8月发布的。
和WindowsNT一样，Windows95也支援Intel386或更高等级处理器的32位元保护模式。
虽然它缺少WindowsNT中的某些功能，诸如高安全性和对RISC机器的可携性等，但是Windows95具有需要较少硬体资源的优点。
Windows98在1998年6月发布，具有许多加强功能，包括执行效能的提高、更好的硬体支援以及与网际网路和全球资讯网（WWW）更紧密的结合。
Windows方面
Windows98和WindowsNT都是支援32位元优先权式多工（preemptivemultitasking）及多执行绪的图形作业系统。
Windows拥有图形使用者介面（GUI），这种使用者介面也称作「视觉化介面」或「图形视窗环境」。
有关GUI的概念可追溯至70年代中期，在Alto和Star等机器上以及SmallTalk等环境中由XeroxPARC所作的研究工作。
该项研究的成果後来被AppleComputer和Microsoft引入主流并流行起来。
虽然有一些争议，但现在已非常清楚，GUI是（Microsoft的CharlesSimonyi的说法）一个在个人电脑工业史上集各方面技术大成於一体的最重要产物。
所有GUI都在点矩阵对应的视讯显示器上处理图形。
图形提供了使用萤幕的最佳方式、传递资讯的视觉化丰富多彩环境，以及能够WYSIWYG（whatyouseeiswhatyouget：
所见即所得）的图形视讯显示和为书面文件准备好格式化文字输出内容。
在早期，视讯显示器仅用於回应使用者通过键盘输入的文字。
在图形使用者介面中，视讯显示器自身成为使用者输入的一个来源。
视讯显示器以图示和输入设备（例如按钮和卷轴）的形式显示多种图形物件。
使用者可以使用键盘（或者更直接地使用滑鼠等指向装置）直接在萤幕上操纵这些物件，拖动图形物件、按下滑鼠按钮以及滚动卷轴。
因此，使用者与程式的交流变得更为亲密。
这不再是一种从键盘到程式，再到视讯显示器的单向资讯流动，使用者已经能够与显示器上的物件直接交互作用了。
使用者不再需要花费长时间学习如何使用电脑或掌握新程式了。
Windows让这一切成真，因为所有应用程式都有相同的基本外观和感觉。
程式占据一个视窗－萤幕上的一块矩形区域。
每个视窗由一个标题列标识。
大多数程式功能由程式的功能表开始。
用户可使用卷轴观察那些无法在一个萤幕中装下的资讯。
某些功能表项目触发对话方块，用户可在其中输入额外的资讯。
几乎在每个大的Windows程式中都有一个用於开启档案的特殊对话方块。
该对话方块在所有这些Windows程式中看起来都一样（或接近相同），而且几乎总是从同一功能表选项中启动。
一旦您了解使用一个Windows程式的方法，您就非常容易学习其他的Windows程式。
功能表和对话方块允许用户试验一个新程式并探究它的功能。
大多数Windows程式同时具有键盘介面和滑鼠介面。
虽然Windows程式的大多数功能可通过键盘控制，但使用滑鼠要容易得多。
从程式写作者的角度看，一致的使用者介面来自於Windows建构功能表和对话方块的内置程式。
所有功能表都有同样的键盘和滑鼠介面，因为这项工作是由Windows处理，而不是由应用程式处理。
为便於多个程式的使用，以及这些程式间资讯的交换，Windows支援多工。
在同一时刻能有多个Windows程式显示并运行。
每个程式在萤幕上占据一个视窗。
用户可在萤幕上移动视窗，改变它们的大小，在不同程式间切换，并从一个程式向另一个程式传送资料。
因为这些视窗看起来有些像桌面上的纸（当然，这是电脑还未占据办公桌之前的年代），Windows有时被称作：
一个显示多个程式的「具象化桌面」。
Windows的早期版本使用一种「非优先权式（non-preemptive）」的多工系统。
这意味著Windows不使用系统计时器将处理时间分配给系统中运行的多个应用程式，程式必须自愿放弃控制以便其他程式运行。
在WindowsNT和Windows98中，多工是优先权式的，而且程式自身可分割成近乎同时执行的多个执行绪。
作业系统不对记忆体进行管理便无法实现多工。
当新程式启动、旧程式终止时，记忆体会出现碎裂空间。
系统必须能够将闲置的记忆体空间组织在一起，因此系统必须能够移动记忆体中的程式码和资料块。
即使是在8088微处理器上跑的Windows1.0也能进行这类记忆体管理。
在实际模式限制下，这种能力被认为是软体工程一个令人惊讶的成就。
在Windows1.0中，PC硬体结构的640KB记忆体限制，在不要求任何额外记忆体的情况下被有效地扩展了。
但Microsoft并未就此停步：
Windows2.0允许Windows应用程式存取延伸记忆体（EMS）；Windows3.0在保护模式下，允许Windows应用程式存取高达16MB的扩展记忆体。
WindowsNT和Windows98通过成熟的32位元作业系统及平坦定址空间，摆脱了这些旧的限制。
Windows上执行的程式可共用在称为「动态连结程式库」的档案中的常式。
Windows包括一个机制，能够在执行时连结使用动态连结程式库中常式的程式。
Windows自身基本上就是一个动态连结程式库的集合。
Windows是一个图形介面，Windows程式能够在视讯显示器和印表机上充分利用图形和格式化文字。
图形介面不仅在外观上更有吸引力，而且还能够让使用者传递高层次的资讯。
Windows应用程式不能直接存取萤幕和印表机等图形显示设备硬体。
相反，Windows提供一种图形程式语言（称作图形装置介面，或者GDI），使显示图形和格式化文字更容易。
Windows虚拟化了显示硬体，使为Windows编写的程式可使用任何具有Windows装置驱动程式的视频卡或印表机，而程式无需确定系统相连的装置类型。
对Windows开发者来说，将与装置无关的图形介面输出到IBMPC上不是件轻松的事。
PC的设计是基於开放式架构的原则，鼓励第三方硬体制造商为PC开发周边设备，而且开发了大量这样的设备。
虽然出现了多种标准，PC上的传统MS-DOS程式仍不得不各自支援许多不同的硬体设备。
这对MS-DOS文字处理软体来说非常普遍，它们连同1到2张有许多小档案的磁片一同销售，每个档案支援一种特定的印表机。
Windows程式不要求每个应用程式都自行开发这些驱动程式，因为这种支援是Windows的一部分。
动态连结
Windows运作机制的核心是一个称作「动态连结」的概念。
Windows提供了应用程式丰富的可呼叫函式，大多数用於实作其使用者介面和在视讯显示器上显示文字和图形。
这些函式采用动态连结程式库（DynamicLinkingLibrary，DLL）的方式撰写。
这些动态连结程式库是些具有.DLL或者有时是.EXE副档名的档案，在Windows98中通常位於\WINDOWS\SYSTEM子目录中，在WindowsNT中通常位於\WINNT\SYSTEM和\WINNT\SYSTEM32子目录中。
在早期，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实作）是一个图形装置介面，允许程式在萤幕和印表机上显示文字和图形。
Windows98支援应用程式可使用的上千种函式呼叫。
每个函数都有一个描述名称，例如CreateWindow。
该函数（如您所猜想的）为程式建立新视窗。
所有应用程式可以使用的Windows函式都在表头档案里预先宣告过。
在Windows程式中，使用Windows函式的方式通常与使用如strlen等C语言程式库函式的方式相同。
主要的区别在於C语言程式库函式的机械码连结到您的程式码中，而Windows函式的程式码在您程式执行档外的DLL中。
当您执行Windows程式时，它通过一个称作「动态连结」的过程与Windows相接。
一个Windows的.EXE档案中有使用到的不同动态连结程式库的参考资料，所使用的函式即在那些动态连结程式库中。
当Windows程式被载入到记忆体中时，程式中的呼叫被指向DLL函式的入口。
如果该DLL不在记忆体中，就把它载入到记忆体中。
当您连结Windows程式以产生一个可执行档案时，您必须连结程式开发环境提供的特定「引用程式库（importlibrary）」。
这些引用程式库包含了动态连结程式库名称和所有Windows函式呼叫的引用资讯。
连结程式使用该资讯在.EXE档案中建立一个表格，在载入程式时，Windows使用它将呼叫转换为Windows函式。
WINDOWS程式设计选项
为说明Windows程式设计的多种技术，本书提供了许多范例程式。
这些程式使用C语言撰写并原原本本的使用WindowsAPI来开发程式。
我将这种方法称作「古典」Windows程式设计。
这是我们在1985年为Windows1.0写程式的方法，它今天仍是写作Windows程式的有效方法。
API和记忆体模式
对於程式写作者来说，作业系统是由本身的API定义的。
API包含了所有应用程式能够使用的作业系统函式呼叫，同时包含了相关的资料型态和结构。
在Windows中，API还意味著一个特殊的程式架构，我们将在每章的开头进行研究。
一般而言，WindowsAPI自Windows1.0以来一直保持一致，没什么重大改变。
具有Windows98程式写作经验的Windows程式写作者会对Windows1.0程式的原始码感觉非常熟悉。
API改变的一种方式是进行增强。
Windows1.0支援不到450个函式呼叫，现在已有了上千种函式呼叫。
WindowsAPI和它的语法的最大变化来自於从16位元架构向32位元架构转化的过程中。
Windows从版本1.0到版本3.1使用16位元Intel8086、8088、和286微处理器上所谓的分段记忆体模式，由於相容性的原因，从386开始的32位元Intel微处理器也支援该模式。
在这种模式下，微处理器暂存器的大小为16位元，因此C的int资料型态也是16位元宽。
在分段记忆体模式下，记忆体位址由两个部分组成－一个16位元段（segment）指标和一个16位偏移量（offset）指标。
从程式写作者的角度看，这非常凌乱并带来了long或far指标（包括段位址和偏移量位址）和short或near指标（包括带有假定段位址的偏移量位址）的区别。
从WindowsNT和Windows95开始，Windows支援使用Intel386、486和Pentium处理器32位元模式下的32位元平坦定址记忆体模式。
C语言的int资料型态也扩展为32位元的值。
为32位元版本Windows编写的程式使用简单的平坦线性空间定址的32位元指标值。
用於16位元版本Windows的API（Windows1.0到Windows3.1）现在称作Win16。
用於32位元版本Windows的API（Windows95、Windows98和所有版本的WindowsNT）现在称作Win32。
许多函式呼叫在从Win16到Win32的转变中保持相同，但有些需要增强。
例如，图像座标点由Win16中的16位元值变为Win32中的32位元值。
此外，某些Win16函式呼叫返回一个包含在32位元整数值中的二维座标点。
这在Win32中不可能，因此增加的新函式呼叫以不同方式运作。
所有32位元版本的Windows都支援Win16API（以确保和旧有应用程式相容）和Win32API（以运行新应用程式）。
非常有趣的是，WindowsNT与Windows95及Windows98的工作方式不同。
在WindowsNT中，Win16函式呼叫通过一个转换层被转化为Win32函式呼叫，然後被作业系统处理。
在Windows95和Windows98中，该操作正相反：
Win32函式呼叫通过转换层转换为Win16函式呼叫，再由作业系统处理。
在同一时刻有两个不同的WindowsAPI集（至少名称不同）。
Win32s（「s」代表「subset（子集）」）是一个API，允许程式写作者编写在Windows3.1上执行的32位元应用程式。
该API仅支援已被Win16支援的32位元函式版本。
此外，Windows95API一度被称作Win32c（「c」代表「compatibility（相容性）」），但该术语已被抛弃了。
现在，WindowsNT和Windows98都被认为能够支援Win32API。
然而，每个作业系统依然都支援某些不被别的作业系统支援的某些功能特性。
因为它们的相同之处是相当可观的，所以有可能编写在两个作业系统下都可执行的程式。
而且，人们普遍认为这两个产品最终会合而为一。
语言选项
使用C语言和原始的API不是编写Windows98程式的唯一方法。
然而，这种方法却提供给您最佳的性能、最强大的功能和在发掘Windows特性方面最大的灵活性。
可执行档案相对较小且运行时不要求外部程式库（自然，WindowsDLL自身除外）。
最重要的是，不管您最终以什么方式开发Windows应用程式，熟悉API会使您对Windows内部有更深入的了解。
虽然我认为学习古典的Windows程式设计对任何Windows程式写作者都是重要的，我没有必要建议使用C和API编写每个Windows应用程式。
许多程式写作者，特别是那些为公司内部开发程式或在家编写娱乐程式的程式写作者喜欢轻松的开发环境，例如MicrosoftVisualBasic或者BorlandDelphi（它结合了物件导向的Pascal版本）。
这些环境使程式写作者将精力集中於应用程式的使用者介面和相关使用者介面物件的程式码上。
要学习VisualBasic，您也许需要参考MicrosoftPress的一些其他图书，例如MichaelHalvorson1996年著的《LearnVisualBasicNow》。
在专业程式写作者中－特别是那些开发商业应用程式的程式写作者－MicrosoftVisualC++和MicrosoftFoundationClassLibrary（MFC）是近年来流行的选择。
MFC在一组C++物件类别中封装了许多Windows程式设计中的琐碎细节。
JeffProsise的《ProgrammingWindowswithMFC,第二版》（MicrosoftPress,1999年）提供了MFC程式的写作指南。
最近，Internet和WorldWideWeb的流行大力推广著SunMicrosystems的Java，这是一个受C++启发却与微处理器无关的程式设计语言，而且结合了可在几个作业系统平台上执行的图形应用程式开发工具组。
MicrosoftPress有一本关於MicrosoftJ++（Microsoft的Java）开发工具的好书，《ProgrammingVisualJ++6.0》（1998年），由StephenR.Davis著。
显然，很难说哪种方法更有利於开发Windows应用程式。
更主要的是，也许是应用程式自身的特性决定了所使用的工具。
不管您最後实际上使用什么工具写作程式，学习WindowsAPI将使您更深入地了解Windows工作的方式。
Windows是一个复杂的系统，在API上增加一个程式写作层并未减少它的复杂性，仅仅是掩盖了它，早晚您会碰到它。
了解API会给您更好的补救机会。
在原始的WindowsAPI之上的任何软体层都必定将您限制在全部功能的一个子集内。
您也许发现，例如，使用VisualBasic编写应用程式非常理想，然而它不允许您做一个或两个很简单的基本工作。
在这种情况下，您将不得不使用原始的API呼叫。
API定义了作为Windows程式写作者所需的一切。
没有什么方法比直接使用API更万能的了。
MFC尤其问题百出。
虽然它大幅简化了某些工作（例如OLE），我却经常发现要让它们按我所想的去工作时，会在其他特性（例如Document/View架构）上碰壁。
MFC还不是Windows程式设计者所追求的灵丹妙药，很少有人认为它是一个好的物件导向设计的模型。
MFC程式写作者从他们使用的物件类别定义如何工作中受益颇深，并
升级会员 