Windows程序设计第五版PDF美化版 - Charles Petzold

5星 · 超过95%的资源需积分: 5 72 浏览量更新于2024-12-21 收藏 5.78MB PDF 举报

"《Windows程序设计第五版美化版》是由Charles Petzold著作，余孟学翻译的一本深入讲解Windows程序设计的书籍，特别适合使用C语言进行编程的读者。这本书主要涵盖了在Windows 98、Windows NT 4.0以及Windows NT 5.0环境下编写程序的方法，通过原始的Windows API接口。书中还提到，虽然使用其他编程方式也是可能的，但理解Windows API对于任何Windows程序开发都是至关重要的。本书的基础篇从第一章开始，引导读者进入Windows程序设计的世界。作者建议读者对Windows 98的操作系统有基本的用户操作了解，并且具备C语言编程的基础知识。学习C语言最好是通过文本控制台环境，例如在Windows 98的MS-DOS命令提示窗口。在Windows编程中，可能会遇到非文本模式编程的情况，但大多数时候，扎实的C语言语法和指针知识是必不可少的。另外，读者需要在自己的计算机上安装一个32位C语言编译器和开发环境，书中以Microsoft Visual C++ 6.0为例，这个编译器可以单独购买，也可以作为Visual Studio 6.0套装的一部分。书中的内容并不假设读者有图形用户界面（GUI）开发的经验，所以它是从零开始的学习指南。在后续章节中，读者将逐步学习如何利用Windows API创建窗口、处理消息、管理内存、使用文件系统、进行图形绘制等。此外，书中可能还会涉及到线程、进程、同步机制、网络通信等高级主题，这些都是构建复杂Windows应用程序所必需的知识。《Windows程序设计第五版美化版》是一本适合初学者和进阶者的技术书籍，它不仅提供了详细的API使用教程，还帮助读者建立起对Windows系统底层工作原理的理解，是深入学习Windows程序设计的重要参考资料。"

//Defoe.Tu tyysoft@yahoo.com.cn Windows 程序设计 PDF 美化版

图2-2 Windows ANSI字符

集（基于ANSI/ISO 8859-1）

空方框表示该位置未定义字符。这与ANSI/ISO 8859-1的最终定义一致。ANSI/ISO 8859-1仅显

示了图形字符，而没有控制字符，因此没有定义DEL。此外，代码0xA0定义为一个非断开的空格（这

意味着在编排格式时，该字符不用于断开一行），代码0xAD是一个软连字符（表示除非在行尾断开

单词时使用，否则不显示）。此外，ANSI/ISO 8859-1将代码0xD7定义为乘号（*），0xF7为除号（/）。

Windows中的某些字体也定义了从0x80到0x9F的某些字符，但这些不是ANSI/ISO 8859-1标准的一

部分。

MS-DOS 3.3（1987年4月发行）向IBM PC用户引进了代码页（code page）的概念，Windows

也使用此概念。代码页定义了字符的映像代码。最初的IBM字符集被称作代码页437，或者「MS-DOS

Latin US）。代码页850就是「MS-DOS Latin 1」，它用附加的带重音字母（但不是图2-2所示的Latin

1 ISO/ANSI标准）代替了一些线形字符。其它代码页被其它语言定义。最低的128个代码总是相同

的；较高的128个代码取决于定义代码页的语言。

在MS-DOS中，如果用户为PC的键盘、显示卡和打印机指定了一个代码页，然后在PC上创建、

编辑和打印文件，一切都很正常，每件事都会保持一致。然而，如果用户试图与使用不同代码页的

用户交换文件，或者在机器上改变代码页，就会产生问题。字符码与错误的字符相关联。应用程序

能够将代码页信息与文件一起保存来试图减少问题的产生，但该策略包括了某些在代码页间转换的

工作。

虽然代码页最初仅提供了不包括带重音符号字母的附加拉丁字符集，但最终代码页的较高的

128个字符还是包括了完整的非拉丁字母，例如希伯来语、希腊语和斯拉夫语。自然，如此多样会

导致代码页变得混乱；如果少数带重音的字母未正确显示，那么整个文字便会混乱不堪而不可阅读。

代码页的扩展正是基于所有这些原因，但是还不够。斯拉夫语的MS-DOS代码页855与斯拉夫

语的Windows代码页1251以及斯拉夫语的Macintosh代码页10007不同。每个环境下的代码页都

是对该环境所作的标准字符集修正。IBM OS/2也支援多种EBCDIC代码页。

但等一下，你会发现事情变得更糟糕。

双字节字符集

迄今为止，我们已经看到了256个字符的字符集。但中国、日本和韩国的象形文字符号有大约

21,000个。如何容纳这些语言而仍保持和ASCII的某种兼容性呢？

解决方案（如果这个说法正确的话）是双字节字符集（DBCS：double-byte character set）。

DBCS从256代码开始，就像ASCII一样。与任何行为良好的代码页一样，最初的128个代码是ASCII。

然而，较高的128个代码中的某些总是跟随着第二个字节。这两个字节一起（称作首字节和跟随字

节）定义一个字符，通常是一个复杂的象形文字。

虽然中文、日文和韩文共享一些相同的象形文字，但显然这三种语言是不同的，而且经常是同

一个象形文字在三种不同的语言中代表三件不同的事。Windows支持四个不同的双字节字符集：代

码页932（日文）、936（简体中文）、949（韩语）和950（繁体汉字）。只有为这些国家（地区）生

产的Windows版本才支持DBCS。

双字符集问题并不是说字符由两个字节代表。问题在于一些字符（特别是ASCII字符）由1个字

节表示。这会引起附加的程序设计问题。例如，字符串中的字符数不能由字符串的字节数决定。必

须剖析字符串来决定其长度，而且必须检查每个字节以确定它是否为双字节字符的首字节。如果有

一个指向DBCS字符串中间的指针，那么该字符串前一个字符的地址是什么呢？惯用的解决方案是

从开始的指针分析该字符串！

//Defoe.Tu tyysoft@yahoo.com.cn Windows 程序设计 PDF 美化版

Unicode解决方

案

我们面临的基本问题是世界上的书写语言不能简单地用256个8位代码表示。以前的解决方案包

括代码页和DBCS已被证明是不能满足需要的，而且也是笨拙的。那什么才是真正的解决方案呢？

身为程序写作者，我们经历过这类问题。如果事情太多，用8位数值已经不能表示，那么我们

就试更宽的值，例如16位值。而且这很有趣的，正是Unicode被制定的原因。与混乱的256个字符

代码映像，以及含有一些1字节代码和一些2字节代码的双字节字符集不同，Unicode是统一的16

位系统，这样就允许表示65,536个字符。这对表示所有字符及世界上使用象形文字的语言，包括一

系列的数学、符号和货币单位符号的集合来说是充裕的。

明白Unicode和DBCS之间的区别很重要。Unicode使用（特别在C程序设计语言环境里）「宽

字符集」。「Unicode中的每个字符都是16位宽而不是8位宽。」在Unicode中，没有单单使用8位数

值的意义存在。相比之下，在双字节字符集中我们仍然处理8位数值。有些字节自身定义字符，而

某些字节则显示需要和另一个字节共同定义一个字符。

处理DBCS字符串非常杂乱，但是处理Unicode文字则像处理有秩序的文字。您也许会高兴地

知道前128个Unicode字符（16位代码从0x0000到0x007F）就是ASCII字符，而接下来的128个

Unicode字符（代码从0x0080到0x00FF）是ISO 8859-1对ASCII的扩展。Unicode中不同部分的字

符都同样基于现有的标准。这是为了便于转换。希腊字母表使用从0x0370到0x03FF的代码，斯拉

夫语使用从0x0400到0x04FF的代码，美国使用从0x0530到0x058F的代码，希伯来语使用从0x0590

到0x05FF的代码。中国、日本和韩国的象形文字（总称为CJK）占用了从0x3000到0x9FFF的代码。

Unicode的最大好处是这里只有一个字符集，没有一点含糊。Unicode实际上是个人计算机行

业中几乎每个重要公司共同合作的结果，并且它与ISO 10646-1标准中的代码是一一对应的。

Unicode的重要参考文献是《The Unicode Standard，Version 2.0》（Addison-Wesley出版社，

1996年）。这是一本特别的书，它以其它文件少有的方式显示了世界上书写语言的丰富性和多样性。

此外，该书还提供了开发Unicode的基本原理和细节。

Unicode有缺点吗？当然有。Unicode字符串占用的内存是ASCII字符串的两倍。（然而压缩文

件有助于极大地减少文件所占的磁盘空间。）但也许最糟的缺点是：人们相对来说还不习惯使用

Unicode。身为程序写作者，这就是我们的工作。

宽字符和 C

对C程序写作者来说，16位字符的想法的确让人扫兴。一个char和一个字节同宽是最不能确定

的事情之一。没几个程序写作者清楚ANSI/ISO 9899-1990，这是「美国国家标准程序设计语言－C」

（也称作「ANSI C」）通过一个称作「宽字符」的概念来支持用多个字节代表一字符的字符集。这

些宽字符与常用的字符完美地共存。

ANSI C也支持多字节字符集，例如中文、日文和韩文版本Windows支持的字符集。然而，这

些多字节字符集被当成单字节构成的字符串看待，只不过其中一些字符改变了后续字符的含义而

已。多字节字符集主要影响C语言程序执行时期链接库函数。相比之下，宽字符比正常字符宽，而

且会引起一些编译问题。

宽字符不需要是Unicode。Unicode是一种可能的宽字符集。然而，因为本书的焦点是

Windows而不是C执行的理论，所以我将把宽字符和Unicode作为同义语。

Char数据型态

//Defoe.Tu tyysoft@yahoo.com.cn Windows 程序设计 PDF 美化版

假定我们都非常熟悉在C程序中使用char数据型态

来定义和储存字符跟字符串。但为了便于理

解C如何处理宽字符，让我们先回顾一下可能在Win32程序中出现的标准字符定义。

下面的语句定义并初始化了一个只包含一个字符的变量：

char c = 'A' ;

变量c需要1个字节来保存，并将用十六进制数0x41初始化，这是字母A的ASCII代码。

您可以像这样定义一个指向字符串的指针：

char * p ;

因为Windows是一个32位操作系统，所以指针变量p需要用4个字节保存。您还可初始化一个

指向字符串的指针：

char * p = "Hello!" ;

像前面一样，变量p也需要用4个字节保存。该字符串保存在静态内存中并占用7个字节－6个字

节保存字符串，另1个字节保存终止符号0。

您还可以像这样定义字符数组：

char a[10] ;

在这种情况下，编译器为该数组保留了10个字节的储存空间。表达式sizeof（a）将返回10。

如果数组是整体变量（即在所有函数外定义），您可使用像下面的语句来初始化一个字符数组：

char a[] = "Hello!" ;

如果您将该数组定义为一个函数的区域变量，则必须将它定义为一个static变量，如下：

static char a[] = "Hello!" ;

无论哪种情况，字符串都储存在静态程序内存中，并在末尾添加0，这样就需要7个字节的储存

空间。

宽字符

Unicode或者宽字符都没有改变char数据型态在C中的含义。char继续表示1个字节的储存空

间，sizeof （char）继续返回1。理论上，C中1个字节可比8位长，但对我们大多数人来说，1个

字节（也就是1个char）是8位宽。

C中的宽字符基于wchar_t数据型态，它在几个表头文件包括WCHAR.H中都有定义，像这样：

typedef unsigned short wchar_t ;

因此，wchar_t数据型态与无符号短整数型态相同，都是16位宽。

要定义包含一个宽字符的变量，可使用下面的语句：

wchar_t c = 'A' ;

变量c是一个双字节值0x0041，是Unicode表示的字母A。（然而，因为Intel微处理器从最小的

字节开始储存多字节数值，该字节实际上是以0x41、0x00的顺序保存在内存中。如果检查Unicode

文字的计算机储存应注意这一点。）

您还可定义指向宽字符串的指针：

wchar_t * p = L"Hello!" ;

注意紧接在第一个引号前面的大写字母L（代表「long」）。这将告诉编译器该字符串按宽字符

//Defoe.Tu tyysoft@yahoo.com.cn Windows 程序设计 PDF 美化版

保存－即每个字符占用2个字节。

通常，指针变量p要占用4个字节，而字符串变量需要14个字节－

每个字符需要2个字节，末尾的0还需要2个字节。

同样，您还可以用下面的语句定义宽字符数组：

static wchar_t a[] = L"Hello!" ;

该字符串也需要14个字节的储存空间，sizeof (a) 将返回14。索引数组a可得到单独的字符。

a[1] 的值是宽字符「e」，或者0x0065。

虽然看上去更像一个印刷符号，但第一个引号前面的L非常重要，并且在两个符号之间必须没

有空格。只有带有L，编译器才知道您需要将字符串存为每个字符2字节。稍后，当我们看到使用宽

字符串而不是变量定义时，您还会遇到第一个引号前面的L。幸运的是，如果忘记了包含L，C编译

器通常会给提出警告或错误信息。

您还可在单个字符文字前面使用L前缀，来表示它们应解释为宽字符。如下所示：

wchar_t c = L'A' ;

但通常这是不必要的，C编译器会对该字符进行扩充，使它成为宽字符。

宽字符链接库函数

我们都知道如何获得字符串的长度。例如，如果我们已经像下面这样定义了一个字符串指针：

char * pc = "Hello!" ;

我们可以呼叫

iLength = strlen (pc) ;

这时变量iLength将等于6，也就是字符串中的字符数。

太好了！现在让我们试着定义一个指向宽字符的指针：

wchar_t * pw = L"Hello!" ;

再次呼叫strlen ：

iLength = strlen (pw) ;

现在麻烦来了。首先，C编译器会显示一条警告消息，可能是这样的内容：

'function' : incompatible types - from 'unsigned short *' to 'const char *'

这条消息的意思是：声明strlen函数时，该函数应接收char类型的指标，但它现在却接收了一

个unsigned short类型的指标。您仍然可编译并执行该程序，但您会发现iLength等于1。为什么？

字符串「Hello!」中的6个字符占用16位：

0x0048 0x0065 0x006C 0x006C 0x006F 0x0021

Intel处理器在内存中将其存为：

48 00 65 00 6C 00 6C 00 6F 00 21 00

假定strlen函数正试图得到一个字符串的长度，并把第1个字节作为字符开始计数，但接着假定

如果下一个字节是0，则表示字符串结束。

这个小练习清楚地说明了C语言本身和执行时期链接库函数之间的区别。编译器将字符串

L"Hello!" 解释为一组16位短整数型态数据，并将其保存在wchar_t数组中。编译器还处理数组索引

和sizeof操作符，因此这些都能正常工作，但在连结时才添加执行时期链接库函数，例如strlen。这

//Defoe.Tu tyysoft@yahoo.com.cn Windows 程序设计 PDF 美化版

些函数认为字符串由单字节字符组成。遇到宽字符串时，函数就不像我们所希望那样执行了。

您可能要说：「噢，太麻

烦了！」现在每个C语言链接库函数都必须重写以接受宽字符。但事实

上并不是每个C语言链接库函数都需要重写，只是那些有字符串参数的函数才需要重写，而且也不

用由您来完成。它们已经重写完了。

strlen函数的宽字符版是wcslen（wide-character string length：宽字符串长度），并且在

STRING.H（其中也说明了strlen）和WCHAR.H中均有说明。strlen函数说明如下：

size_t __cdecl strlen (const char *) ;

而wcslen函数则说明如下：

size_t __cdecl wcslen (const wchar_t *) ;

这时我们知道，要得到宽字符串的长度可以呼叫

iLength = wcslen (pw) ;

函数将返回字符串中的字符数6。请记住，改成宽字节后，字符串的字符长度不改变，只是位

组长度改变了。

您熟悉的所有带有字符串参数的C执行时期链接库函数都有宽字符版。例如，wprintf是printf

的宽字符版。这些函数在WCHAR.H和含有标准函数说明的表头文件中说明。

维护单一原始码

当然，使用Unicode也有缺点。第一点也是最主要的一点是，程序中的每个字符串都将占用两

倍的储存空间。此外，您将发现宽字符执行时期链接库中的函数比常规的函数大。出于这个原因，

您也许想建立两个版本的程序－一个处理ASCII字符串，另一个处理Unicode字符串。最好的解决

办法是维护既能按ASCII编译又能按Unicode编译的单一原始码文件。

虽然只是一小段程序，但由于执行时期链接库函数有不同的名称，您也要定义不同的字符，这

将在处理前面有L的字符串文字时遇到麻烦。

一个办法是使用Microsoft Visual C++包含的TCHAR.H表头文件。该表头文件不是ANSI C标准

的一部分，因此那里定义的每个函数和宏定义的前面都有一条底线。TCHAR.H为需要字符串参数的

标准执行时期链接库函数提供了一系列的替代名称（例如，_tprintf和_tcslen）。有时这些名称也称

为「通用」函数名称，因为它们既可以指向函数的Unicode版也可以指向非Unicode版。

如果定义了名为_UNICODE的标识符，并且程序中包含了TCHAR.H表头文件，那么_tcslen就

定义为wcslen：

#define _tcslen wcslen

如果没有定义UNICODE，则_tcslen定义为strlen：

#define _tcslen strlen

等等。TCHAR.H还用一个新的数据型态TCHAR来解决两种字符数据型态的问题。如果定义了

_UNICODE标识符，那么TCHAR就是wchar_t：

typedef wchar_t TCHAR ;

否则，TCHAR就是Char：

typedef char TCHAR ;

现在开始讨论字符串文字中的L问题。如果定义了_UNICODE标识符，那么一个称作__T的宏就

剩余937页未读，继续阅读

w564867731

粉丝: 1
资源: 4

Windows程序设计第五版PDF美化版 - Charles Petzold

Windows程序设计第5版(高清PDF+美化版+WORD版)

CSkin WinForm 登录界面美化设计Demo

xp系统美化软件

改造windows server 2008 r2

用VC制作屏保程序.pdf

Windows程序设计入门与进阶指南

Windows程序设计基础与进阶指南

Windows程序设计入门与C语言结合详解

火狐浏览器23.0b9版官方Windows安装指南

QT与MFC界面美化集成源码包下载

最新资源