在增加Unicode宏后出现的错误..??怎么解决?

YP2002CN 2002-04-04 06:03:27

我已经在Link和c/c++中加入了申请所需要的Unicode宏设置..
可为什么编译出现下面的错误:
msvcrtd.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@16
TTT___Win32_Unicode_Debug/TTT.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

这是怎么回事?

...全文

33 3 打赏收藏转发到动态举报

写回复

用AI写文章

3 条回复

切换为时间正序

请发表友善的回复…

发表回复

YP2002CN 2002-04-04

打赏
举报

喔建立的是Dialog对话框....

YP2002CN 2002-04-04

打赏
举报

怎么用?不明白..能具体点吗?

逸少 2002-04-04

打赏
举报

使用 Unicode 编译后，连接的是 WinMianW 函数，可以使用 _tWinMian 宏.

第一部分程序员必读第一章对程序错误的处理在我们开始介绍Microsoft Windows应该提供的许多特性之前，我们首先必须了解Windows的各个函数是如何进行错误处理的。当你调用一个Windows函数时，它首先要检验你传递给它的的各个参数的有效性，然后再设法执行它的任务。如果你传递了一个无效参数，或者由于某种原因它无法执行这项操作，那么该函数就会返回一个值，指明该函数在某种程度上运行失败了。表1-1列出了大多数Windows函数使用的数据类型的返回值。表1-1 Windows函数常用的返回值类型数据类型表示失败的值 VOID 该函数的运行不可能失败。Windows函数的返回值类型很少是VOID。 BOLL 如果函数运行失败，那么返回值是0，否则返回的是非0值。最好对返回值进行测试，以确定它是0还是非0。如果它是TRUE ，则不要测试返回值。 HANDLE 如果函数运行失败，则返回值通常是NULL，否则返回值为 HANDLE，，用于标识你可以操作的一个对象。对于这个返回值，你应该小心处理，因为有些函数会返回一个句柄值INVALID_HANDLE_VALUE，它被定义为-1。该函数的 Platform SDK资料将会清楚地说明该函数是返回NULL还是INVALID_HANDLE_VALID，以便指明函数运行已经失败。 PVOID 如果函数运行失败，则返回值是NULL，否则返回PVOID，以标识数据块的内存地址。 LONG/DWORD 这是个难以处理的值。返回数量的函数通常返回LONG 或DWORD。如果由于某种原因，函数无法对你想要进行计数的对象进行计数，那么该函数通常返回0或-1（根据该函数而定）。如果你调用的函数返回了LONG/DWORD，那么请认真阅读Platform SDK资料，以确保你能正确检查潜在的错误。当一个Windows函数返回一个错误代码时，它常常可以用来了解函数为什么会运行失败。Microsoft公司编译了一个所有可能的错误代码的列表，并且为每个错误代码分配了一个32位的号码。从系统内部来讲，当一个Windows函数检测到一个错误时，它会使用一个称为线程本地存储器的机制，将相应的错误代码号码与调用的线程关联起来。（“线程本地存储器”将在第21章中介绍）。这将使线程能够互相独立地运行，而不会影响各自的错误代码。当函数返回给你时，它的返回值就能指明一个错误已经发生。若要确定这是个什么错误，请调用GetLastError函数：见原书P4的程序（1）该函数只返回线程的32位错误代码。当你拥有32位错误代码的号码时，你必须将该号码转换成更有用的某种对象。WinError.h头文件包含了Microsoft公司定义的错误代码的列表。下面我显示了该列表的某些内容，使你能够看到它的大概样子：见原书P4的程序（2）和P5的程序你可以看到，每个错误都有3种表示法：即一个消息ID（这是你可以在源代码中使用的一个宏，以便与GetLastError的返回值进行比较），消息文本（对错误的英文描述）和一个号码（你应该避免使用这个号码，而应该使用消息ID）。请记住，我只选择了WinError.h头文件中的很少一部分内容来向你进行展示，整个文件的长度超过21000行。当Windows函数运行失败时，你应该立即调用GetLastError函数，否则，如果你调用另一个Windows函数，它的值很可能被改写。说明 GetLastError能返回线程产生的最后一个错误。如果该线程调用的Windows 函数运行成功，那么最后一个错误代码就不被改写，并且不指明运行成功。有少数Windows函数并不遵循这一规则，并且它会更改最后的错误代码，但是Platform SDK资料通常指明，当函数运行成功时，该函数会更改最后的错误代码。 Windows 98 许多Windows 98的函数实际上是用Microsoft公司的16位Windows 3.1产品产生的16位代码来实现的。这种比较老的代码并不通过GetLastError之类函数来报告错误，而且Microsoft公司并没有在Windows 98中修改16位代码，以支持这种错误处理方式。对于我们来说，这意味着Windows 98中的许多Win32 函数在运行失败时不能设置最后的错误代码。该函数将返回一个值，指明运行失败，这样你就能够发现该函数确实已经运行失败。但是你无法确定运行失败的原因。有些Windows函数之所以能够成功运行，那是若干个原因产生的结果。例如，创建指明的事件内核对象之所以能够取得成功，原因是你实际上创建了该对象，或者是因为已经存在带有相同名字的事件内核对象。你的应用程序必须知道成功的原因。为了将该信息返回给你，Microsoft公司选择使用最后错误代码机制。这样，当某些函数运行成功时，你就能够通过调用GetLadtError函数来确定其他的一些信息。对于具有这种行为特性的函数来说，Platform SDK资料清楚地说明了GetLastError函数可以这样来使用。请参见该资料，以便找出CreateEvent函数的例子。当你进行调试的时候，我发现监控线程的最后错误代码是非常有用的。在Microsoft Visual studio 6.0中，Microsoft的调试程序支持一个非常有用的特性，即你可以配置Watch窗口，以便始终都能向你显示线程的最后错误代码的号码和该错误的英文描述。通过选定Watch窗口中的一行，并键入“@err,hr",你就能够做到这一点。观察图1-1，你会看到我已经调用了CreateFile函数。该函数返回INVALID_HANDLE_VALUE（-1）的HANDLE，表示它未能打开指定的文件。但是Watch窗口向我们显示最后错误代码（即如果我调用GetLastErro函数，该函数返回的错误代码）是0x00000002。该Watch窗口又进一步指明错误代码2是指“系统不能找到指定的文件。”你会发现它与WinError.h头文件中的错误代码2所指的字符串是相同的。图1-1 在Visual Studio 6.0的Watch窗口中键入 “@err,hr"，你就可以查看当前线程的最后错误代码。 Visual studio还配有一个小的实用程序，称为Error Lookup。你可以使用Error Lookup将错误代码的号码转换成它的文本描述。见P7的Error Lookup插图如果我在我编写的应用程序中发现一个错误，我可能想要向用户显示该错误的文本描述。Windows提供了一个函数，可以将错误代码转换成它的文本描述。该函数称为FormatMessage。请看下面的代码：见原书P8的程序（1） FormatMessage函数的功能实际上是非常丰富的，在创建向用户显示的字符串信息时，它是人们首选的函数。该函数之所以有这样大的作用，原因之一是它很容易用多种语言来进行操作。该函数能够检测出用户首选的语言（在Regional Settings Control Panel小应用程序中设定），并返回相应的文本。当然，你首先必须自己转换字符串，然后将已转换的消息表资源嵌入你的.exe文件或DLL模块，不过，这时该函数会选定正确的嵌入对象。ErrorShow示例应用程序（本章后面将加以介绍）展示了如何调用该函数，以便将Microsoft公司定义的错误代码转换成它的文本描述。有些人常常问我，Microsoft公司是否建立了一个主控列表，以显示每个Windows函数可能返回的所有错误代码。可惜，答案是没有这样的列表，而且Microsoft公司将永远不会建立这样的一个列表。因为在创建系统的新版本时，建立和维护该列表实在太困难了。建立这样一个列表时存在的问题是，你可以调用一个Windows函数，但是该函数能够在内部调用另一个函数，而这另一个函数又可以调用另一个函数，如此类推。由于各种不同的原因，这些函数中的任何一个函数都可能运行失败。有时，当一个函数运行失败时，较高级的函数对它进行恢复，并且仍然可以执行你想执行的操作。为了创建该主控列表，Microsoft公司必须跟踪每个函数的运行路径，并建立所有可能的错误代码的列表。这项工作很困难。当创建系统的新版本时，这些函数的运行路径就会改变。 1.1 你也能够定义自己的错误代码好了，我已经说明Windows函数是如何向函数的调用者指明发生的错误。Microsoft公司也使你能够将该机制用于你自己的函数。比如说，你编写了一个你希望其他人调用的函数。你的函数可能因为这样或那样的原因而运行失败，你必须向函数的调用者说明它已经运行失败。若要指明函数运行失败，你只需要设定线程的最后的错误代码，然后让你的函数返回FALSE，INVALID_HANDLE_VALUE，NULL，或者返回任何合适的信息。若要设定线程的最后错误代码，你只需要调用下面的代码：见原书P8的程序（2）请将你认为合适的任何32位号码传递给该函数。我设法使用WinError.h中已经存在的代码，只要该代码能够正确地指明我想要报告的错误即可。如果你认为WinError.h中的任何代码都不能正确地反映该错误的性质，那么你可以创建你自己的代码。错误代码是个32位的数字，它可以划分成下表所示的各个域。位 31-30 29 28 27-16 15-0 内容严重性 Microsoft/ 保留设备代码异常代码客户含义 0=成功 0=Microsoft 必须是0 由Microsoft 由Microsoft/ 1=供参考公司定义的公司定义客户定义 2=警告代码 3=错误 1=客户定义的代码这些域将在第24章中详细讲述。现在，你需要知道的重要域是第29位的信息。Microsoft公司规定，他们建立的所有错误代码的这个信息位均使用0。如果你创建自己的错误代码，你必须在这个信息位中输入1。这样，就可以确保你的错误代码与Microsoft公司目前或者将来定义的错误代码不会发生冲突， 1.2 ErrorShow示例应用程序 ErrorShow应用程序“01 ErrorShow.exe"(在图1-2中列出)展示了如何获取错误代码的文本描述的方法。该应用程序的源代码和资源文件位于本书所附光盘上的01-ErrorShow目录下。一般来说，该应用程序用于显示调试程序的Watch窗口和Error Lookup程序是如何运行的。当你启动该程序时，就会出现下面这个窗口。见原书P9的插图你可以将任何错误代码键入该编辑控件。当你单击Look Up按钮时，在底部的滚动窗口中就会显示该错误的文本描述。该应用程序唯一令人感兴趣的特性是如何调用FormatMessage函数。下面是我使用该函数的方法：见原书P10的程序（1）第一个代码行用于从编辑控件中检索错误代码的号码。然后，建立一个内存块的句柄并将它初始化为NULL。FormatMessage函数在内部对内存块进行分配，并将它的句柄返回给我们。当调用FormatMessage函数时，我传递了FORMAT_MESSAGE_FROM_SYSTEM标志。该标志告诉FormatMessage函数，我们想要系统定义的错误代码的字符串。我还传递了FORMAT_MESSAGE_ALLOCATE_BUFFER标志，告诉该函数为错误代码的文本描述分配足够大的内存块。该内存块的句柄将在hlocal变量中返回。第三个参数指明我们想要查找的错误代码的号码，第四个参数指明我们想要文本描述使用什么语言。如果FormatMessage函数运行成功，那么错误代码的文本描述就位于内存块中，我将它拷贝到对话框底部的滚动窗口中。如果FormatMesage函数运行失败，我设法查看NetMsg.dll模块中的消息代码，以了解该错误是否与网络有关。使用NetMsg.dll模块的句柄，我再次调用FormatMessage函数。你会看到，每个DLL（或.exe）都有它自己的一组错误代码，你可以使用Message Compiler（MC.exe）将这组错误代码添加给该模块，并将一个资源添加给该模块。这就是Visual Studio的Error Lookup工具允许你用Modules对话框进行的操作。图1-2 ErrorShow示例应用程序见原书P11—16 第2章 UNICODE 随着Microsoft公司的Windows操作系统在全世界日益广泛的流行，对于我们这些软件开发人员来说，将我们的目标瞄准国际上的各个不同市场，已经成为一个越来越重要的问题。美国的软件版本比国际版本提前6个月推向市场，这曾经是个司空见惯的现象。但是，由于各国对Windows操作系统提供了越来越多的支持，因此就更加容易为国际市场生产各种应用软件，从而缩短了软件的美国版本与国际版本推出的时间间隔。 Windows操作系统始终不逾地提供各种支持，以帮助软件开发人员进行应用程序的本地化工作。应用软件可以从各种不同的函数中获得特定国家的信息，并可观察控制面板的设置，以确定用户的首选项。Windows甚至支持不同的字体，以适应我们的应用的需要。我之所以将这一章放在本书的开头，是因为我考虑到Unicode是开发任何应用程序时要采用的基本步骤。关于Unicode的问题，我在本书的每一章中几乎都要讲到，而且本书中给出的所有示例应用程序都是“用Unicode实现的”。如果你为Microsoft Windows 2000或Microsoft Windows CE开发应用程序，你应该使用Unicode进行开发。如果你为Microsoft Windows 98开发应用程序，你必须对某些问题作出决定。本章也要讲述Windows 98的有关问题。 2.1 字符集软件的本地化要解决的真正问题，实际上就是如何来处理不同的字符集。多年来，我们许多人一直将文本串作为一系列单字节字符来进行编码，并在结尾处放上一个零。对于我们来说，这已经成了习惯。当我们调用strlen函数时，它在以0结尾的单字节字符数组中返回字符的数目。问题是，有些文字和书写规则（比如日文中的汉字就是个典型的例子）的字符集中的符号太多了，因此单字节（它提供的符号最多不能超过256个）是根本不敷使用的。为此我们创建了双字节字符集（DBCS），以支持这些文字和书写规则。 2.1.1 单字节与双字节字符集在双字节字符集中，字符串中的每个字符可以包含一个字节，也可以包含两个字节。例如，日文中的汉字，如果第一个字符在0x81与0x9F之间，或者在0xE0与0xFC之间，那么你就必须观察下一个字节，才能确定字符串中的这个完整的字符。如果要使用双字节字符集，对于程序员来说简直是个很大的难题，因为有些字符只有一个字节宽，而有些字符则是两个字节宽。如果只是调用strlen函数，那么你无法真正了解字符串中究竟有多少字符，它只能告诉你到达结尾的0之前有多少个字节。ANSI的C运行期库中没有配备相应的函数，使你能够对双字节字符集进行操作。但是，Microsoft Visual C++的运行期库却包含许多函数，如_mbslen,它可以用来操作多字节（既包括单字节也包括双字节）字符串。为了帮助你对DBCS字符串进行操作，Windows提供了下面的一组帮助函数。函数描述 PTSTR CharNext 返回字符串中的下一个字符的地址（PCTSTR pszCurrentChar）； PTSTR CharPrev 返回字符串中的上一个字符的地址（PCTSTR pszStart, PCTSTR pszCurrentChar)； BOOL IsDBCSLendByte 如果该字节是DBCS字符的第一个字节，则返（BYTE bTestChar）；回TRUE 2.1.2 Unicode：宽字节字符集 Unicode是Apple和Xerox公司于1988年建立的一个技术标准。1991年，成立了一个集团机构负责Unicode的开发和推广应用。该集团由Apple、Compaq、HP、IBM、Microsoft、Oracle、Silicon Graphics、Sybase、Unisys和Xerox等公司组成。（若要了解该集团的全部成员，请通过网址www.Unicode.org查找。）该集团公司负责维护Unicode标准。Unicode的完整描述可以参阅AddisonWesley出版的《Unicode Standard》一书。（该书可以通过网址www.Unicode.org订购。） Unicode提供了一种简单而又一致的表示字符串的方法。Unicode字符串中的所有字符都是16位的字符（两个字节）。它没有专门的字节来指明下一个字节是属于同一个字符的组成部分，还是一个新字符。这意味着你只需要对指针进行递增或递减，就可以遍历字符串中的各个字符。你不再需要调用CharNext,CharPrev和IsDBCSLeadByte之类的函数。由于Unicode用一个16位的值来表示每个字符，因此总共可以得到65000个字符，这样，它就能够对世界各国的书面文字中的所有字符进行编码。这远远超过了单字节字符集的256个字符的数目。目前，已经为阿拉伯文、中文拼音、西里尔字母（俄文）、希腊文、西伯莱文、日文、韩文和拉丁文（英文）字母定义了Unicode代码点1。这些字符集中还包含了大量的标点符号、数学符号、技术符号、箭头、装饰标志、区分标志和其他许多字符。如果你将所有这些字母和符号加在一起，总计约达35000个不同的代码点，这样，总计的65000个代码点中，大约还有一半可供将来扩充时使用。这65536个字符可以分成不同的区域。下面这个表显示了一部分这样的区域以及分配给这些区域的字符。 16位代码字符 16位代码字符 0000-007F ASCII 0300-036F 通用区分标志 0080-00FF 拉丁文1字符 0400-04FF 西里尔字母 0100-017F 欧洲拉丁文 0530-058F 亚美尼亚文 0180-01FF 扩充拉丁文 0590-05FF 西伯莱文 0250-02AF 标准拼音 0600-06FF 阿拉伯文 02B0-02FF 修改型字母 0900-097F 梵文注1．代码点是指字符集中的一个符号的位置目前尚未分配的代码点大约还有29000个，不过它们是保留供将来使用的。另外，大约有6000个代码点是保留供你个人使用的。 2． 2 为何应该使用Unicode 当你开发应用程序时，你当然应该考虑利用Unicode的优点。即使现在你不打算对你的应用程序进行本地化，开发时将Unicode放在心上，肯定可以简化将来的代码转换工作。此外，Unicode还具备下列功能： * 可以很容易地在不同语言之间进行数据交换 * 使你能够分配支持所有语言的单个二进制.exe文件或DLL文件 * 提高你的应用程序的运行效率（本章后面还要详细介绍） 2．3 Windows 2000与Unicode Windows 2000是使用Unicode从头进行开发的，用于创建窗口、显示文本、进行字符串操作等的所有核心函数都需要Unicode字符串。如果你调用任何一个Windows函数并给它传递一个ANSI字符串，那么系统首先要将字符串转换成Unicode，然后将Unicode字符串传递给操作系统。如果你希望函数返回ANSI字符串，系统就会首先将Unicode字符串转换成ANSI字符串，然后将结果返回给你的应用程序。所有这些转换操作都是在你看不见的情况下发生的。当然，进行这些字符串的转换需要占用系统的时间和内存开销。例如，如果你调用CreateWindowEx函数，并传递类名字和窗口标题文本的非Unicode字符串，那么CreateWindowEx必须分配内存块（在你的进程的默认堆中），将非Unicode字符串转换成Unicode字符串，并将结果存储在分配到的内存块中，然后调用Unicode版本的CreateWindowEx函数。对于用字符串填入缓存的函数来说，系统必须首先将Unicode字符串转换成非Unicode字符串，然后你的应用程序才能处理该字符串。由于系统必须执行所有这些转换操作，因此你的应用程序需要更多的内存，并且运行的速度比较慢。通过从头开始用Unicode来开发应用程序，你就能够使你的应用程序更加有效地运行。 2． 4 Windows 98与Unicode Windows 98不是一种全新的操作系统。它继承了16位Windows操作系统的特性，它不是用来处理Unicode。如果要增加对Unicode的支持，其工作量非常大，因此在该产品的特性列表中没有包括这个支持项目。由于这个原因，Windows 98象它的前任产品一样，几乎都是使用ANSI字符串来进行所有的内部操作的。你仍然可以编写用于处理Unicode字符和字符串的Windows应用程序，不过，使用Windows函数要难得多。例如，如果你想要调用CreateWindowEx函数并将ANSI字符串传递给它，这个调用的速度非常快，不需要从你进程的默认堆栈中分配缓存，也不需要进行字符串转换。但是，如果你想要调用CreateWindowEx函数并将Unicode字符串传递给它，你就必须明确分配缓存，并调用函数，以便执行从Unicode到ANSI字符串的转换操作。然后你可以调用CreateWindowEx，传递ANSI字符串。当CreateWindowEx函数返回时，你就能释放临时缓存。这比使用Windows 2000上的Unicode要麻烦得多。在本章的后面部分中，我要介绍如何在Windows 98下进行这些转换。虽然Unicode函数的大多数代码在Windows 98中不起任何作用，但是有少数Unicode函数确实拥有非常有用的实现代码。这些函数是：见原书的P21 可惜的是，这些函数中有许多函数在Windows 98中会出现各种各样的错误。有些函数无法使用某些字体，有些函数会破坏内存堆栈，有些函数会使打印机驱动程序崩溃，如此等等。如果你要使用这些函数，你必须对它们进行大量的测试。即使这样，你可能仍然无法解决问题。因此你必须向用户说明这些情况。 2． 5 Windows CE与Unicode Windows CE操作系统是为小型设备开发的，这些设备的内存很小，并且不带磁盘存储器。你可能认为，由于Microsoft公司的主要目标是建立一种尽可能小的操作系统，因此它会使用ANSI作为自己的字符集。但是Microsoft公司并不是鼠目寸光。他们懂得，采用Windows CE的设备要在世界各地销售，他们希望降低软件开发成本，这样就能更加容易地开发应用程序。为此，Windows CE本身就是使用Unicode的一种操作系统。但是，为了使Windows CE尽量做得小一些，Microsoft公司决定完全不支持ANSI Windows函数。因此，如果你要为Windows CE开发应用程序，你必须懂得Unicode，并且在整个应用程序中使用Unicode。 2． 6 需要注意的问题下面让我们进一步明确一下“Microsoft公司对Unicode支持的情况”： * Windows 2000既支持Unicode，也支持ANSI，因此你可以为它们当中的任何一种开发应用程序 * Windows 98 只支持ANSI，你只能为ANSI开发应用程序 * Windows CE只支持Unicode，你只能为Unicode开发应用程序虽然Microsoft公司试图让软件开发人员能够非常容易地开发在这3种平台上运行是软件，但是Unicode与ANSI之间的差异使得事情变得困难起来，并且这种差异通常是我遇到的最大的问题之一。请不要误解，Microsoft公司坚定地支持Unicode，并且我也坚决鼓励你使用它。不过你应该懂得，你可能遇到一些问题，需要一定的时间来解决这些问题。我建议你尽可能使用Unicode。如果你运行Windows 98，那么只有在必要时才要转换到ANSI。不过，还有另一个小问题你应该了解，那就是COM。 2．7 对COM的简单说明当Microsoft公司将COM从16位Windows转换成Win32时，公司作出了一个决定，即，需要字符串的所有COM接口方法都只能接受Unicode字符串。这是个了不起的决定，因为COM通常用于使不同的组件能够互相之间进行通信，而Unicode则是传递字符串的最佳手段。如果你为Windows 2000或Windows CE开发应用程序，并且也使用COM，那么你将会如虎添翼。在你的整个源代码中使用Unicode，将使与操作系统进行通信和与COM对象进行通信的操作变成一件轻而易举的事情。如果你为Windows 98开发应用程序，并且也使用COM，那么你将会遇到一些问题。COM要求你使用Unicode字符串。操作系统的大多数函数要求你使用ANSI字符串。那是多么难办的事情啊！我曾经从事过若干个项目的开发，在这些项目中，我编写了许多代码，仅仅是为了来回进行字符串的转换。 2． 8 如何编写Unicode源代码 Microsoft公司为Unicode设计了Windows API，这样，它可以尽量减少对你的代码的影响。实际上，你可以编写单个源代码文件，以便使用或者不使用Unicode来对它进行编译。你只需要定义两个宏（UNICODE和_UNICODE），就可以修改然后重新编译该源文件。 2． 8.1 C运行期库对Unicode的支持为了利用Unicode字符串，因此定义了一些数据类型。标准的C头文件String.h已经作了修改，以便定义一个名字为wchar_t的数据类型，它是一个Unicode字符的数据类型：见原书P23的程序（1）例如，如果你想要创建一个缓存，用于存放最多为99个字符的Unicode字符串和一个结尾为零的字符，你可以使用下面这个语句：见原书P23的程序（2）该语句创建了一个由100个16位值组成的数组。当然，标准的C运行期字符串函数，如strcpy、strchr和strcat等，只能对ANSI字符串进行操作，它们不能正确地处理Unicode字符串。因此，ANSI C也拥有一组补充函数。图2-1显示了一些标准的ANSI C字符串函数，后面是它们的等价Unicode函数。图2-1 标准的ANSI C字符串函数和它们的等价Unicode函数见原书P23的程序（3）和P24的程序请注意，所有的Unicode函数均以wcs开头，wcs是宽字符串的英文缩写。若要调用Unicode函数，只需用前缀wcs来取代任何ANSI字符串函数的前缀str即可。说明大多数软件开发人员可能已经不记得这样一个非常重要的问题了，那就是Microsoft公司提供的C运行期库与ANSI的标准C运行期库是一致的。 ANSI C规定，C运行期库支持Unicode字符和字符串。这意味着你始终都可以调用C运行期函数，以便对Unicode字符和字符串进行操作，即使你是在 Windows 98上运行，也可以调用这些函数。换句话说，wcscat,wcslen和wcstok 等函数都能够在Windows 98上很好地运行，这些都是你必须关心的操作系统函数。对于包含了对str函数或wcs函数进行显式调用的代码来说，你无法非常容易地同时为ANSI和Unicode对这些代码进行编译。在本章前面部分的内容中，我说过可以创建同时为ANSI和Unicode进行编译的单个源代码文件。若要建立这种双重功能，你必须包含Tchar.h文件，而不是包含String.h文件。 Tchar.h文件的唯一作用是帮助你创建ANSI/Unicode通用源代码文件。它包含你应该用在源代码中的一组宏，而不应该直接调用str函数或者wcs函数。如果你在编译源代码文件时定义了_UNICODE，这些宏就会引用wcs这组函数。如果你没有定义_UNICODE，那么这些宏将引用str这组宏。例如，在Tchar.h中有一个宏称为_tcscpy。如果在你包含该头文件时没有定义_UNICODE,那么_tcscpy就会扩展为ANSI的strcpy函数。但是如果定义了_UNICODE,_tcscpy将扩展为Unicode的wcscpy函数。拥有字符串参数的所有C运行期函数都在Tchar.h文件中定义了一个通用宏。如果你使用通用宏，而不是ANSI/Unicode的特定函数名，你就能够顺利地创建可以为ANSI或Unicode进行编译的源代码。但是，除了使用这些宏之外，还有一些操作你是必须进行的。Tchar.h文件包含了一些其他的宏。若要定义一个ANSI/Unicode通用的字符串数组，请使用下面的TCHAR数据类型。如果定义了_UNICODE，TCHAR将声明为下面的形式：见原书P25的程序（1）如果没有定义_UNICODE，则TCHAR将声明为下面的形式：见原书P25的程序（2）使用该数据类型，你可以象下面这样分配一个字符串：见原书P25的程序（3）你也可以创建对字符串的指针：见原书P25的程序（4）不过上面这行代码存在一个问题。按照默认设置，Microsoft公司的C++编译器能够编译所有的字符串，就象它们是ANSI字符串，而不是Unicode字符串。因此，如果没有定义_UNICODE，该编译器将能正确地编译这一行代码。但是，如果定义了_UNICODE，就会产生一个错误。若要生成一个Unicode字符串而不是ANSI字符串，你必须将该代码行改写为下面的样子：见原书P25的程序（5）原义字符串前面的大写字母L，用于告诉编译器该字符串应该作为Unicode字符串来编译。当编译器将字符串置于程序的数据部分中时，它在每个字符之间分散插入零字节。这种变更带来的问题是，现在只有当定义了_UNICODE时，程序才能成功地进行编译。我们需要另一个宏，以便有选择地在原义字符串的前面加上大写字母L。这项工作由_TEXT宏来完成，_TEXT宏也在Tchar.h文件中做了定义。如果定义了_UNICODE，那么_TEXT定义为下面的形式：见原书P25的程序（6）

仅收录该书籍以供学习和讨论包含pdf书籍及经过验证的示例执行demo中的示例方式在编译环境下进入demo目录，执行nmake命令在bin目录下生成可执行文件注：demo无注释，对应书本中部分示例。目录第1章　Windows应用程序开发入门　1 1.1　第一个实例程序　1 1.1.1　start.exe　1 1.1.2　Windows API　2 1.1.3　程序入口函数　2 1.1.4　start.c代码分析　2 1.2　编译代码　3 1.2.1　安装Visual Studio　3 1.2.2　安装Microsoft Platform SDK　4 1.2.3　集成Microsoft Platform SDK与Visual C++速成版　5 1.2.4　Vista SDK与Visual Studio 2008　6 1.2.5　Visual Studio专业版或团队系统版　7 1.2.6　使用图形化IDE建立工程、进行编译　7 1.2.7　“解决方案”与“工程”　8 1.2.8　使用命令行工具编译　8 第2章　Windows API概要　10 2.1　Windows数据类型　10 2.1.1　Windows数据类型示例　10 2.1.2　Windows数据类型与标准C数据类型的关系　14 2.1.3　Windows数据类型与Windows API　14 2.1.4　Windows中的数据结构　15 2.2　Windows API的功能分类　15 2.2.1　系统基本服务　15 2.2.2　系统管理　17 2.2.3　用户界面　17 2.2.4　图像和多媒体　20 2.2.5　网络　20 2.2.6　系统安全　20 2.2.7　其他功能　21 2.3　Windows API核心DLL　21 2.3.1　Kernel32.dll　21 2.3.2　User32.dll　21 2.3.3　Gdi32.dll　22 2.3.4　标准C函数　22 2.3.5　其他Dll　22 2.4　Unicode和多字节　22 2.4.1　W版本和A版本的API　24 2.4.2　Unicode与ASCII的转换　24 2.5　对Windows程序设计规范的建议　25 第3章　开发工具配置与使用　26 3.1　使用Visual C/C++编译链接工具　26 3.1.1　编译器cl.exe　27 3.1.2　资源编译器rc.exe　31 3.1.3　链接器link.exe　32 3.1.4　其他工具　38 3.1.5　编译链接工具依赖的环境变量　39 3.1.6　示例：使用/D选项进行条件编译　42 3.2　使用Platform SDK　43 3.2.1　Platform SDK的目录结构与功能　43 3.2.2　为编译链接工具设置环境变量　45 3.2.3　Platform SDK工具集　46 3.2.4　Windows Vista SDK　48 3.3　编写Makefile　48 3.3.1　使用nmake.exe构建工程　48 3.3.2　Makefile实例　50 3.3.3　注释　50 3.3.4　宏　50 3.3.5　描述块：目标、依赖项和命令　53 3.3.6　makefile预处理　55 3.3.7　在Platform SDK的基础上使用nmake　56 3.4　使用WinDbg调试　57 3.4.1　安装WinDbg　57 3.4.2　编译可调试的程序　58 3.4.3　WinDbg命令　59 3.4.4　调试过程演示　59 3.5　集成开发环境 Visual Studio　62 3.5.1　工程类型选择与配置　62 3.5.2　Visual Studio快捷方式　64 3.5.3　生成项目　64 3.5.4　调试　65 3.5.5　选项与设置　65 3.6　开发环境配置总结　66 第4章　文件系统　67 4.1　概述　67 4.1.1　文件系统的基本概念　67 4.1.2　文件系统主要API　68 4.2　磁盘和驱动器管理　70 4.2.1　遍历卷并获取属性　70 4.2.2　操作驱动器挂载点　76 4.2.3　判断光驱中是否有光盘　81 4.2.4　获取磁盘分区的总容量、空闲容量、簇、扇区信息　83 4.3　文件和目录管理　86 4.3.1　删除、复制、重命名、移动文件　87 4.3.2　创建、打开、读写文件，获取文件大小　90 4.3.3　创建目录　96 4.3.4　获取程序所在的目录、程序模块路径，获取和设置当前目录　97 4.3.5　查找文件、遍历指定目录下的文件和子目录　100 4.3.6　递归遍历目录树　103 4.3.7　获取、设置文件属性和时间　105 4.4　内存映射文件　110 4.4.1　使用Mapping File提高文件读写的效率　110 4.4.2　通过Mapping File在进程间传递和共享数据　115 4.4.3　通过文件句柄获得文件路径　118 4.5　总结　121 第5章　内存管理　122 5.1　Windows内存管理原理　122 5.1.1　基本概念　122 5.1.2　分页与分段内存管理、内存映射与地址转换　123 5.1.3　进程的内存空间　125 5.1.4　虚拟内存布局、内存的分工、堆与栈　127 5.1.5　内存的保护属性和存取权限　127 5.1.6　本章API列表　127 5.2　堆管理　129 5.2.1　获取堆句柄、分配与再分配堆　129 5.2.2　获取堆中内存块的大小信息　133 5.2.3　释放内存、销毁堆　134 5.3　全局(Global)和局部(Local)内存管理　136 5.3.1　Global函数　136 5.3.2　Local函数　137 5.3.3　使用全局和局部函数分配和释放内存、改变内存块属性　137 5.4　虚拟内存管理　138 5.4.1　虚拟地址空间与内存分页　139 5.4.2　分配和释放可读可写的虚拟内存页面　139 5.4.3　修改内存页面状态和保护属性、将页面锁定在物理内存中　142 5.4.4　管理其他进程的虚拟内存　143 5.5　内存操作与内存信息管理　144 5.5.1　复制、填充、移动、清零内存块、防止缓冲区溢出　144 5.5.2　获得当前系统内存使用情况　146 5.5.3　判断内存指针的可用性　147 5.6　各种内存分配方式的关系与比较　148 5.6.1　标准C内存管理函数与Windows内存管理API的关系　149 5.6.2　功能性区别　149 5.6.3　效率的区别　149 第6章　进程、线程和模块　150 6.1　基本概念　150 6.1.1　应用程序与进程　150 6.1.2　控制台应用程序与图形用户界面应用程序　151 6.1.3　动态链接库、模块　151 6.1.4　线程、纤程与作业　152 6.1.5　权限与优先级　153 6.2　进程管理　153 6.2.1　创建进程、获取进程相关信息、获取启动参数　153 6.2.2　编写控制台程序和图形用户界面应用程序　158 6.2.3　获取和设置环境变量　158 6.3　线程、纤程　162 6.3.1　创建线程、退出线程、获取线程信息　162 6.3.2　挂起、恢复、切换、终止线程　164 6.3.3　创建远程线程、将代码注入其他进程中执行　167 6.3.4　创建纤程、删除纤程、调度纤程　170 6.3.5　纤程与线程的互相转换　171 6.4　进程状态信息　176 6.4.1　PS API与Tool help API　176 6.4.2　遍历系统中的进程　178 6.4.3　列举进程的模块、线程　182 6.4.4　进程的堆使用、内存占用、虚拟内存大小，页面错误情况　184 6.5　动态链接库　185 6.5.1　加载、释放DLL、通过句柄获取DLL相关信息　186 6.5.2　编写动态链接库、导出函数　186 6.5.3　创建动态链接库工程，配置DLL编译链接选项　188 6.5.4　运行时动态获取DLL导出函数地址并调用　189 6.5.5　声明导出函数、创建lib库，为其他模块提供导入表调用接口　190 6.5.6　通过构建导入表调用DLL导出函数　191 第7章　线程同步　192 7.1　基本原理　192 7.1.1　线程同步的过程　193 7.1.2　同步对象　193 7.1.3　等待函数　193 7.2　同步对象示例　194 7.2.1　使用事件对象(Event)　194 7.2.2　使用互斥对象(Mutex)　199 7.2.3　使用信号量控制访问共享数据的线程数量　202 7.2.4　使用可等待计时器(Timer)　206 7.3　等待进程和线程的执行完成　209 第8章　服务　210 8.1　基本概念　210 8.1.1　服务控制器(SCM)　211 8.1.2　服务程序　211 8.1.3　服务控制管理程序　211 8.1.4　系统服务管理工具　211 8.1.5　服务的属性　211 8.2　编写服务程序　212 8.2.1　入口函数　212 8.2.2　服务主函数　212 8.2.3　控制处理函数　213 8.3　实现对服务的控制和管理　216 8.3.1　创建、删除服务　216 8.3.2　启动、停止服务，向服务发送控制请求　219 8.3.3　管理服务状态、配置服务、服务的依赖关系　222 第9章　图形用户界面　229 9.1　字符界面程序　229 9.1.1　基本概念　230 9.1.2　控制台读写　231 9.1.3　控制台字体、颜色等属性，操作屏幕缓存　234 9.1.4　控制台事件　244 9.2　图形用户界面：基本概念　246 9.2.1　窗口　246 9.2.2　窗口类　246 9.2.3　消息和消息处理函数　247 9.2.4　控件　247 9.2.5　资源　248 9.2.6　对话框　248 9.3　图形用户界面：窗口　248 9.3.1　注册窗口类　249 9.3.2　创建窗口　251 9.3.3　窗口消息处理函数　253 9.3.4　窗口属性、位置和大小　256 9.3.5　窗口显示方式　257 9.3.6　线程消息队列和消息循环　258 9.4　图形用户界面：控件　258 9.4.1　Tree View控件　258 9.4.2　为Tree View控件增加节点　260 9.4.3　Tree View右键菜单　262 9.4.4　List View控件　263 9.4.5　为List View控件增加分栏　265 9.4.6　为List View控件增加项　266 9.4.7　文本框控件　267 9.4.8　为文本框控件设置文字　268 9.5　界面资源　269 9.5.1　资源脚本(.rc)　269 9.5.2　资源ID定义和头文件　272 9.5.3　在程序中使用资源　273 9.6　菜单　273 9.6.1　菜单资源和菜单句柄　273 9.6.2　动态增加、删除、设置菜单及菜单项　274 9.6.3　菜单消息处理　274 9.7　对话框　275 9.7.1　创建对话框　275 9.7.2　对话框消息处理函数　276 第10章　系统信息的管理　277 10.1　Windows系统信息　277 10.1.1　获取系统版本　277 10.1.2　获取计算机硬件信息　279 10.1.3　获取系统目录等信息　281 10.1.4　用户名、计算机名、域名　282 10.1.5　处理系统颜色信息、尺度信息等　284 10.1.6　鼠标、键盘等外设信息　285 10.2　时间信息　286 10.2.1　设置、获取系统时间　286 10.2.2　获取开机至现在持续的时间　287 10.2.3　文件时间与系统时间的转换　287 10.3　注册表　288 10.3.1　注册表的作用及组织形式　288 10.3.2　键、子键、键属性及键值的相关操作　289 10.3.3　列举注册表项及键值　292 10.3.4　通过注册表设置一个自启动的程序　293 10.3.5　设置随程序启动而启动的调试器(任何程序)　294 10.3.6　指定程序崩溃实时调试器　294 第11章　进程间通信　295 11.1　邮槽(MailSlot)　295 11.1.1　创建邮槽、从邮槽中读取消息　296 11.1.2　通过邮槽发送消息　299 11.2　管道(Pipe)　300 11.2.1　创建命名管道　300 11.2.2　管道监听　302 11.2.3　使用异步I/O进行读写　303 11.2.4　关闭管道实例　307 11.2.5　客户端　307 11.3　剪贴板　310 11.3.1　获取、设置剪贴板数据　310 11.3.2　监视剪贴板　317 11.3.3　剪贴板数据格式　325 11.4　数据复制消息(WM_COPYDATA)　327 11.4.1　数据发送端　327 11.4.2　数据接收端　330 11.5　其他进程间通信方式　332 11.5.1　动态数据交换(DDE)和网络动态数据交换(NDDE)　332 11.5.2　通过File Mapping在进程间共享数据　333 11.5.3　Windows Socket　333 第12章　Windows Shell程序设计　334 12.1　Windows Shell目录管理　335 12.1.1　Shell对目录和文件的管理形式　335 12.1.2 “我的文档”等特殊目录相关操作　335 12.1.3　绑定、遍历、属性获取　337 12.1.4　浏览文件对话框　339 12.2　文件协助(File Associations)　340 12.2.1　文件类型相关注册表键值　340 12.2.2　为文件指定默认打开程序　341 12.2.3　定制文件类型的图标　342 12.3　Shell扩展　343 12.3.1　对象及概念　343 12.3.2　CLSID，处理例程的GUID　344 12.3.3　注册Shell扩展　345 12.3.4　COM程序开发基础　346 12.3.5　编写Handler程序　346 12.3.6　Shell扩展程序的调试　362 12.3.7　总结　363 12.4　任务栏通知区域(Tray)图标　363 12.4.1　创建图标窗口　364 12.4.2　创建图标和图标菜单　367 12.4.3　最小化主窗口到通知区域　370 12.4.4　弹出气泡通知　372 12.4.5　动态图标　374 12.4.6　其他功能　376 第13章　Windows GDI　379 13.1　GDI编程接口概述　379 13.1.1　Windows GDI的功能　379 13.1.2　链接库与头文件　380 13.2　设备上下文(DC)、输出操作与图形对象　380 13.2.1　设备上下文类型与关联设备　380 13.2.2　图形对象的作用及与DC的关系　380 13.2.3　各类图形对象的具体属性与作用　383 13.2.4　绘制、填充、写入等图形输出操作　384 13.2.5　修剪与坐标变换　385 13.2.6　设备上下文的图形模式　385 13.3　一个最简单的GDI程序　386 13.3.1　示例　386 13.3.2　DC的操作　387 13.3.3　颜色的表示　388 13.3.4　图形对象：画刷和画笔　389 13.3.5　输出操作：绘制图形和线条　390 13.4　文字和字体　391 13.4.1　选择、设置字体　393 13.4.2　选择字体图形对象　394 13.4.3　文字的颜色　394 13.4.4　输出文字　395 13.4.5　DC图形模式设置　395 13.4.6　遍历字体　396 13.4.7　为系统安装、删除字体文件　398 13.5　绘制线条　398 13.5.1　选择画笔对象　399 13.5.2　直线　399 13.5.3　绘制任意曲线　399 13.5.4　跟踪鼠标轨迹　399 13.5.5　弧线　405 13.6　绘制图形　405 13.6.1　填充颜色与边缘勾勒　406 13.6.2　绘制矩形、椭圆、圆角矩形　406 13.6.3　椭圆弓形和椭圆扇形　411 13.6.4　多边形　411 13.6.5　RECT结构及对RECT的操作　412 13.7　位图操作　414 13.7.1　截取屏幕、保存位图文件　414 13.7.2　将位图显示在界面上　419 13.8　区域(Regions)、路径(Paths)与修剪(Clip)操作　422 13.8.1　区域的创建及形状、位置等属性　422 13.8.2　区域边沿、区域填充、反转与勾勒操作　423 13.8.3　组合、比较、移动等操作　426 13.8.4　点击测试(Hit Testing)　427 13.8.5　路径的创建与操作　431 13.8.6　路径转换为区域　432 13.8.7　使用区域和路径进行修剪操作，限制输出　432 13.9　坐标变换　438 13.9.1　缩放　439 13.9.2　旋转　440 13.10　调色板　440 第14章　网络通信与配置　443 14.1　Socket通信　444 14.1.1　客户端　444 14.1.2　服务端　449 14.1.3　处理并发的客户端连接　455 14.1.4　网络通信的异步I/O模式　456 14.2　IP Helper　456 第15章　程序安装与设置　463 15.1　创建cab文件　463 15.1.1　makecab.exe　463 15.1.2　压缩多个文件　464 15.1.3　Cabinet软件开发工具包(CABSDK)　466 15.2　编写INF文件　466 15.2.1　INF文件格式　466 15.2.2　Install节　468 15.2.3　CopyFiles和AddReg等安装过程　468 15.2.4　源路径和目的路径　469 15.2.5　字符串表　469 15.3　安装程序setup.exe的编号　469 15.4　使用msi文件进行安装　472 15.4.1　Windows Installer Service　472 15.4.2　msi文件的创建与修改工具orca.exe　474 15.4.3　准备工作　475 15.4.4　编辑表组　475 第16章　设备驱动管理与内核通信　476 16.1　设备管理　476 16.1.1　列举设备接口　477 16.1.2　监控设备的加载和卸载　483 16.2　I/O控制、内核通信　488 16.2.1　加载驱动程序　488 16.2.2　控制驱动程序、与驱动程序进行通信　495 16.3　编写设备驱动程序　498 16.3.1　驱动程序开发包：DDK　499 16.3.2　开发驱动程序　499 16.4　I/O模式，同步与异步　504 第17章　用户、认证和对象安全　506 17.1　基本概念　506 17.1.1　访问令牌、权限和用户标识　506 17.1.2　进程的系统操作权限　507 17.1.3　安全对象　508 17.1.4　访问控制列表(ACL)　508 17.2　安全机制程序示例　509 17.2.1　列举进程访问令牌内容和权限　509 17.2.2　修改进程的权限　514 17.2.3　列举安全对象的安全描述符　515 17.2.4　修改安全描述符　521 17.3　用户　522 17.3.1　创建用户　522 17.3.2　用户组　523 17.3.3　删除用户　525 17.3.4　列举用户和用户组、获取用户信息　525 第18章　Windows API的内部原理　532 18.1　关于API的补充说明　532 18.1.1　Windows API的版本演进和Vista新增API　532 18.1.2　64位操作系统的接口　533 18.2　Windows系统中的对象封装　533 18.2.1　什么是对象　534 18.2.2　面向对象的思想　534 18.2.3　Windows系统中的对象：内核对象、GDI对象等　534 18.3　Windows程序设计参考：文档资源与样例代码　534 18.3.1　SDK文档和MSDN　534 18.3.2　SDK示例代码　535 18.4　x86平台程序函数调用原理　535 18.4.1　函数调用的真实过程　535 18.4.2　函数调用约定　539 18.4.3　为什么通过参数返回数据时只能使用指针　540 18.4.4　缓冲区溢出　540 18.4.5　程序运行错误的调试技巧　540 18.5　可执行程序结构与API函数接口内部机理　541 18.5.1　Windows可执行程序结构　541 18.5.2　导入表、导出表、动态链接　543 18.5.3　NTDLL.DLL、NATIVE API和SSDT　544 18.5.4　API HOOK　546 18.6　发布程序　546 18.6.1　合理选择编译链接选项　546 18.6.2　构建到指定路径　546 18.7　模块化，向Windows API学习接口定义　547 18.7.1　lib文件　547 18.7.2　头文件　547 18.7.3　为第三方应用软件提供SDK　547

CMake是跨平台开发不可少的工具，很多同学在管理代码的时候需要在不同平台维护不同工程，使用CMake就可以轻松的维护一套工程即可。在基础部分，用一个完整的项目实例，给大家演示如何创建可...

本文的目的是为刚刚接触COM的程序员提供编程指南，并帮助他们理解COM的基本概念。内容包括COM规范简介，重要的COM术语以及如何重用现有的COM组件。本文不包括如何编写自己的COM对象和接口。　　COM即组件对象模型，是Component Object Model 取前三个字母的缩写，这三个字母在当今Windows的世界中随处可见。随时涌现出来的大把大把的新技术都以COM为基础。各种文档中也充斥...

解决VSCODE编辑Keil工程报宏定义错误现象在通过右键打开Keil工程文件夹编辑底层驱动的过程中,诸如uint32_t之类的宏定义总是被报错. 解决方案修改文件 .vscode/c_cpp_properties.json { "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/**",

VC/MFC

16,472

社区成员

421,731

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

VC/MFC社区版块或许是CSDN最“古老”的版块了，记忆之中，与CSDN的年龄几乎差不多。随着时间的推移，MFC技术渐渐的偏离了开发主流，若干年之后的今天，当我们面对着微软的这个经典之笔，内心充满着敬意，那些曾经的记忆，可以说代表着二十年前曾经的辉煌……
向经典致敬，或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天，我们期待着MFC技术能够恢复其曾经的辉煌，或许这个期待会永远成为一种“梦想”，或许一切皆有可能……
我们希望这个版块可以很好的适配Web时代，期待更好的互联网技术能够使得MFC技术框架得以重现活力，……

试试用AI创作助手写篇文章吧

+ 用AI写文章