C++字符串完全指引之一 —— Win32 字符编码


原著：Michael Dunn

翻译：Chengjie Sun

原文出处：CodeProject：The Complete Guide to C++ Strings, Part I

引言

　　毫无疑问，我们都看到过像 TCHAR, std::string, BSTR 等各种各样的字符串类型，还有那些以 _tcs 开头的奇怪的宏。你也许正在盯着显示器发愁。本指引将总结引进各种字符类型的目的，展示一些简单的用法，并告诉您在必要时，如何实现各种字符串类型之间的转换。
　　在第一部分，我们将介绍3种字符编码类型。了解各种编码模式的工作方式是很重要的事情。即使你已经知道一个字符串是一个字符数组，你也应该阅读本部分。一旦你了解了这些，你将对各种字符串类型之间的关系有一个清楚地了解。
　　在第二部分，我们将单独讲述string类，怎样使用它及实现他们相互之间的转换。

字符基础 -- ASCII, DBCS, Unicode

　　所有的 string 类都是以C-style字符串为基础的。C-style 字符串是字符数组。所以我们先介绍字符类型。这里有3种编码模式对应3种字符类型。第一种编码类型是单子节字符集（single-byte character set or SBCS）。在这种编码模式下，所有的字符都只用一个字节表示。ASCII是SBCS。一个字节表示的0用来标志SBCS字符串的结束。
　　第二种编码模式是多字节字符集（multi-byte character set or MBCS）。一个MBCS编码包含一些一个字节长的字符，而另一些字符大于一个字节的长度。用在Windows里的MBCS包含两种字符类型，单字节字符（single-byte characters）和双字节字符（double-byte characters）。由于Windows里使用的多字节字符绝大部分是两个字节长，所以MBCS常被用DBCS代替。
　　在DBCS编码模式中，一些特定的值被保留用来表明他们是双字节字符的一部分。例如，在Shift-JIS编码中（一个常用的日文编码模式），0x81-0x9f之间和 0xe0-oxfc之间的值表示"这是一个双字节字符，下一个子节是这个字符的一部分。"这样的值被称作"leading bytes",他们都大于0x7f。跟随在一个leading byte子节后面的字节被称作"trail byte"。在DBCS中，trail byte可以是任意非0值。像SBCS一样，DBCS字符串的结束标志也是一个单字节表示的0。
　　第三种编码模式是Unicode。Unicode是一种所有的字符都使用两个字节编码的编码模式。Unicode字符有时也被称作宽字符，因为它比单子节字符宽（使用了更多的存储空间）。注意，Unicode不能被看作MBCS。MBCS的独特之处在于它的字符使用不同长度的字节编码。Unicode字符串使用两个字节表示的0作为它的结束标志。
　　单字节字符包含拉丁文字母表，accented characters及ASCII标准和DOS操作系统定义的图形字符。双字节字符被用来表示东亚及中东的语言。Unicode被用在COM及Windows NT操作系统内部。
　　你一定已经很熟悉单字节字符。当你使用char时，你处理的是单字节字符。双字节字符也用char类型来进行操作（这是我们将会看到的关于双子节字符的很多奇怪的地方之一）。Unicode字符用wchar_t来表示。Unicode字符和字符串常量用前缀L来表示。例如：

wchar_t wch = L''1''; // 2 bytes, 0x0031
wchar_t* wsz = L"Hello"; // 12 bytes, 6 wide characters

字符在内存中是怎样存储的

　　单字节字符串：每个字符占一个字节按顺序依次存储，最后以单字节表示的0结束。例如。"Bob"的存贮形式如下：

Unicode的存储形式，L"Bob"

使用两个字节表示的0来做结束标志。

　　一眼看上去，DBCS 字符串很像 SBCS 字符串，但是我们一会儿将看到 DBCS 字符串的微妙之处，它使得使用字符串操作函数和永字符指针遍历一个字符串时会产生预料之外的结果。字符串" " ("nihongo")在内存中的存储形式如下（LB和TB分别用来表示 leading byte 和 trail byte）

93 FA	96 7B	8C EA	00
LB TB	LB TB	LB TB	EOS
			EOS

值得注意的是，"ni"的值不能被解释成WORD型值0xfa93，而应该看作两个值93和fa以这种顺序被作为"ni"的编码。

使用字符串处理函数

　　我们都已经见过C语言中的字符串函数，strcpy(), sprintf(), atoll()等。这些字符串只应该用来处理单字节字符字符串。标准库也提供了仅适用于Unicode类型字符串的函数，比如wcscpy(), swprintf(), wtol()等。
　　微软还在它的CRT(C runtime library)中增加了操作DBCS字符串的版本。Str***()函数都有对应名字的DBCS版本_mbs***()。如果你料到可能会遇到DBCS字符串（如果你的软件会被安装在使用DBCS编码的国家，如中国，日本等，你就可能会），你应该使用_mbs***()函数，因为他们也可以处理SBCS字符串。（一个DBCS字符串也可能含有单字节字符，这就是为什么_mbs***()函数也能处理SBCS字符串的原因）
　　让我们来看一个典型的字符串来阐明为什么需要不同版本的字符串处理函数。我们还是使用前面的Unicode字符串 L"Bob"：

　　因为x86CPU是little-endian，值0x0042在内存中的存储形式是42 00。你能看出如果这个字符串被传给strlen()函数会出现什么问题吗？它将先看到第一个字节42，然后是00，而00是字符串结束的标志，于是strlen()将会返回1。如果把"Bob"传给wcslen()，将会得出更坏的结果。wcslen()将会先看到0x6f42，然后是0x0062，然后一直读到你的缓冲区的末尾，直到发现00 00结束标志或者引起了GPF。
　　到目前为止，我们已经讨论了str***()和wcs***()的用法及它们之间的区别。Str***()和_mbs**()之间的有区别区别呢？明白他们之间的区别，对于采用正确的方法来遍历DBCS字符串是很重要的。下面，我们将先介绍字符串的遍历，然后回到str***()与_mbs***()之间的区别这个问题上来。

正确的遍历和索引字符串

　　因为我们中大多数人都是用着SBCS字符串成长的，所以我们在遍历字符串时，常常使用指针的++-和-操作。我们也使用数组下标的表示形式来操作字符串中的字符。这两种方式是用于SBCS和Unicode字符串，因为它们中的字符有着相同的宽度，编译器能正确的返回我们需要的字符。
　　然而，当碰到DBCS字符串时，我们必须抛弃这些习惯。这里有使用指针遍历DBCS字符串时的两条规则。违背了这两条规则，你的程序就会存在DBCS有关的bugs。

　　我们先来阐述规则2，因为找到一个违背它的真实的实例代码是很容易的。假设你有一个程序在你自己的目录里保存了一个设置文件，你把安装目录保存在注册表中。在运行时，你从注册表中读取安装目录，然后合成配置文件名，接着读取该文件。假设，你的安装目录是C:\Program Files\MyCoolApp，那么你合成的文件名应该是C:\Program Files\MyCoolApp\config.bin。当你进行测试时，你发现程序运行正常。
　　现在，想象你合成文件名的代码可能是这样的：

bool GetConfigFileName ( char* pszName, size_t nBuffSize )
{
    char szConfigFilename[MAX_PATH];
 
    // Read install dir from registry... we''ll assume it succeeds.
 
    // Add on a backslash if it wasn''t present in the registry value.
    // First, get a pointer to the terminating zero.
    char* pLastChar = strchr ( szConfigFilename, ''\0'' );
 
    // Now move it back one character.
    pLastChar--;  
 
    if ( *pLastChar != ''\\'' )
        strcat ( szConfigFilename, "\\" );
 
    // Add on the name of the config file.
    strcat ( szConfigFilename, "config.bin" );
 
    // If the caller''s buffer is big enough, return the filename.
    if ( strlen ( szConfigFilename ) >= nBuffSize )
        return false;
    else
        {
        strcpy ( pszName, szConfigFilename );
        return true;
        }
}      

43	3A	5C	83 88	83 45	83 52	83 5C	00
			LB TB	LB TB	LB TB	LB TB
C	:	\					EOS

　　当使用 GetConfigFileName() 检查尾部的''\\''时，它寻找安装目录名中最后的非0字节，看它是等于''\\''的，所以没有重新增加一个''\\''。结果是代码返回了错误的文件名。
　　哪里出错了呢？看看上面两个被用蓝色高量显示的字节。斜杠''\\''的值是0x5c。'' ''的值是83 5c。上面的代码错误的读取了一个 trail byte，把它当作了一个字符。
　　正确的后向遍历方法是使用能够识别DBCS字符的函数，使指针移动正确的字节数。下面是正确的代码。（指针移动的地方用红色标明）

bool FixedGetConfigFileName ( char* pszName, size_t nBuffSize )
{
    char szConfigFilename[MAX_PATH];
 
    // Read install dir from registry... we''ll assume it succeeds.
 
    // Add on a backslash if it wasn''t present in the registry value.
    // First, get a pointer to the terminating zero.
    char* pLastChar = _mbschr ( szConfigFilename, ''\0'' );
 
    // Now move it back one double-byte character.
    pLastChar = CharPrev ( szConfigFilename, pLastChar );
 
    if ( *pLastChar != ''\\'' )
        _mbscat ( szConfigFilename, "\\" );
 
    // Add on the name of the config file.
    _mbscat ( szConfigFilename, "config.bin" );

     // If the caller''s buffer is big enough, return the filename.
    if ( _mbslen ( szInstallDir ) >= nBuffSize )
        return false;
    else
        {
        _mbscpy ( pszName, szConfigFilename );
        return true;
        }
}

2a. 永远不要使用减法去得到一个字符串的索引。

违背这条规则的代码和违背规则2的代码很相似。例如，

char* pLastChar = &szConfigFilename [strlen(szConfigFilename) - 1];

这和向后移动一个指针是同样的效果。

回到关于str***()和_mbs***()的区别

　　现在，我们应该很清楚为什么_mbs***()函数是必需的。Str***()函数根本不考虑DBCS字符，而_mbs***()考虑。如果，你调用strrchr("C:\\ ", ''\\'')，返回结果可能是错误的，然而_mbsrchr()将会认出最后的双字节字符，返回一个指向真的''\\''的指针。
　　关于字符串函数的最后一点：str***()和_mbs***()函数认为字符串的长度都是以char来计算的。所以，如果一个字符串包含3个双字节字符，_mbslen()将会返回6。Unicode函数返回的长度是按wchar_t来计算的。例如，wcslen(L"Bob")返回3。

Win32 API中的MBCS和Unicode

两组 APIs：
　　尽管你也许从来没有注意过，Win32中的每个与字符串相关的API和message都有两个版本。一个版本接受MBCS字符串，另一个接受Unicode字符串。例如，根本没有SetWindowText()这个API，相反，有SetWindowTextA()和SetWindowTextW()。后缀A表明这是MBCS函数，后缀W表示这是Unicode版本的函数。
　　当你 build 一个 Windows 程序，你可以选择是用 MBCS 或者 Unicode APIs。如果，你曾经用过VC向导并且没有改过预处理的设置，那表明你用的是MBCS版本。那么，既然没有 SetWindowText() API，我们为什么可以使用它呢？winuser.h头文件包含了一些宏，例如：

BOOL WINAPI SetWindowTextA ( HWND hWnd, LPCSTR lpString );
BOOL WINAPI SetWindowTextW ( HWND hWnd, LPCWSTR lpString );
 
#ifdef UNICODE
#define SetWindowText  SetWindowTextW
#else
#define SetWindowText  SetWindowTextA
#endif      

#define SetWindowText SetWindowTextA

　　这个宏定义把所有对SetWindowText的调用都转换成真正的API函数SetWindowTextA。（当然，你可以直接调用SetWindowTextA() 或者 SetWindowTextW()，虽然你不必那么做。）
　　所以，如果你想把默认使用的API函数变成Unicode版的，你可以在预处理器设置中，把_MBCS从预定义的宏列表中删除，然后添加UNICODE和_UNICODE。(你需要两个都定义，因为不同的头文件可能使用不同的宏。) 然而，如果你用char来定义你的字符串，你将会陷入一个尴尬的境地。考虑下面的代码：

HWND hwnd = GetSomeWindowHandle();
char szNewText[] = "we love Bob!";
SetWindowText ( hwnd, szNewText );

在预处理器把SetWindowText用SetWindowTextW来替换后，代码变成：

HWND hwnd = GetSomeWindowHandle();
char szNewText[] = "we love Bob!";
SetWindowTextW ( hwnd, szNewText );

　　看到问题了吗？我们把单字节字符串传给了一个以Unicode字符串做参数的函数。解决这个问题的第一个方案是使用 #ifdef 来包含字符串变量的定义：

HWND hwnd = GetSomeWindowHandle();
#ifdef UNICODE
wchar_t szNewText[] = L"we love Bob!";
#else
char szNewText[] = "we love Bob!";
#endif
SetWindowText ( hwnd, szNewText );

你可能已经感受到了这样做将会使你多么的头疼。完美的解决方案是使用TCHAR.

使用TCHAR

　　TCHAR是一种字符串类型，它让你在以MBCS和UNNICODE来build程序时可以使用同样的代码，不需要使用繁琐的宏定义来包含你的代码。TCHAR的定义如下：

#ifdef UNICODE
typedef wchar_t TCHAR;
#else
typedef char TCHAR;
#endif

所以用MBCS来build时，TCHAR是char，使用UNICODE时，TCHAR是wchar_t。还有一个宏来处理定义Unicode字符串常量时所需的L前缀。

#ifdef UNICODE
#define _T(x) L##x
#else
#define _T(x) x
#endif

　　##是一个预处理操作符，它可以把两个参数连在一起。如果你的代码中需要字符串常量，在它前面加上_T宏。如果你使用Unicode来build，它会在字符串常量前加上L前缀。

TCHAR szNewText[] = _T("we love Bob!");

　　像是用宏来隐藏SetWindowTextA/W的细节一样，还有很多可以供你使用的宏来实现str***()和_mbs***()等字符串函数。例如，你可以使用_tcsrchr宏来替换strrchr()、_mbsrchr()和wcsrchr()。_tcsrchr根据你预定义的宏是_MBCS还是UNICODE来扩展成正确的函数，就像SetWindowText所作的一样。
　　不仅str***()函数有TCHAR宏。其他的函数如， _stprintf（代替sprinft()和swprintf()）,_tfopen（代替fopen()和_wfopen()）。 MSDN中"Generic-Text Routine Mappings."标题下有完整的宏列表。

字符串和TCHAR typedefs

　　由于Win32 API文档的函数列表使用函数的常用名字（例如，"SetWindowText"），所有的字符串都是用TCHAR来定义的。（除了XP中引入的只适用于Unicode的API）。下面列出一些常用的typedefs，你可以在msdn中看到他们。

何时使用 TCHAR 和 Unicode

　　到现在，你可能会问，我们为什么要使用Unicode。我已经用了很多年的char。下列3种情况下，使用Unicode将会使你受益：

　　Windows 9x 中大多数的 API 没有实现 Unicode 版本。所以，如果你的程序要在windows 9x中运行，你必须使用MBCS APIs。然而，由于NT系统内部都使用Unicode，所以使用Unicode APIs将会加快你的程序的运行速度。每次，你传递一个字符串调用MBCS API，操作系统会把这个字符串转换成Unicode字符串，然后调用对应的Unicode API。如果一个字符串被返回，操作系统还要把它转变回去。尽管这个转换过程被高度优化了，但它对速度造成的损失是无法避免的。
　　只要你使用Unicode API，NT系统允许使用非常长的文件名（突破了MAX_PATH的限制，MAX_PATH=260）。使用Unicode API的另一个优点是你的程序会自动处理用户输入的各种语言。所以一个用户可以输入英文，中文或者日文，而你不需要额外编写代码去处理它们。
　　最后，随着windows 9x产品的淡出，微软似乎正在抛弃MBCS APIs。例如，包含两个字符串参数的SetWindowTheme() API只有Unicode版本的。使用Unicode来build你的程序将会简化字符串的处理，你不必在MBCS和Unicdoe之间相互转换。
　　即使你现在不使用Unicode来build你的程序，你也应该使用TCHAR及其相关的宏。这样做不仅可以的代码可以很好地处理DBCS，而且如果将来你想用Unicode来build你的程序，你只需要改变一下预处理器中的设置就可以实现了。

作者简介
　　Michael Dunn：居住在阳光城市洛杉矶。他是如此的喜欢这里的天气以致于想一生都住在这里。他在4年级时开始编程，那时用的电脑是Apple //e。1995年，在 UCLA 获得数学学士学位，随后在Symantec 公司做 QA 工程师，在 Norton AntiVirus 组工作。他自学了 Windows 和 MFC 编程。1999-2000年，他设计并实现了 Norton AntiVirus 的新界面。　
　　Michael 现在在 Napster（一个提供在线订阅音乐服务的公司）做开发工作，他还开发了UltraBar，一个IE工具栏插件，它可以使网络搜索更加容易，给了 googlebar 以沉重打击；他还开发了 CodeProject SearchBar；与人共同创建了 Zabersoft 公司，该公司在洛杉矶和丹麦的 Odense 都设有办事处。
　　他喜欢玩游戏。爱玩的游戏有 pinball, bike riding，偶尔还玩 PS, Dreamcasth 和 MAME 游戏。他因忘了自己曾经学过的语言：法语、汉语、日语而感到悲哀。
]]> 6783323@http://cww0403.bokee.com/ 编程知识 2008-08-18T13:43:13Z http://cww0403.bokee.com/6782088.html

复制以下内容，保存为copy.reg，双击运行即可在鼠标右键菜单添加“复制到”“移动到”功能。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AllFilesystemObjects\shellex\ContextMenuHandlers\Copy To]

@="{C2FBB630-2971-11D1-A18C-00C04FD75D13}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AllFilesystemObjects\shellex\ContextMenuHandlers\Move To]

@="{C2FBB631-2971-11D1-A18C-00C04FD75D13}"

复制以下内容，保存为delcopy.reg，双击运行即可删除鼠标右键菜单添加的“复制到”“移动到”功能。

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AllFilesystemObjects\shellex\ContextMenuHandlers\Copy To]

@="{C2FBB630-2971-11D1-A18C-00C04FD75D13}"

[-HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AllFilesystemObjects\shellex\ContextMenuHandlers\Move To]

@="{C2FBB631-2971-11D1-A18C-00C04FD75D13}"

最近用outlook收发邮件时总是出现一个问题，就是在每次关闭outlook express时，都会提示：“要释放磁盘空间，outlook express可以压缩邮件。这可能需要几分钟”，然后会让你选择确定或者是取消，如果你点击确定的话，压缩过程比较慢(如果本身邮件数量很多的话会更慢)，会出现机器假死的情况，如果你没有耐心而非法关机了，就可能导致部分邮件丢失(甚至全部丢失)。点取消才可以正常关闭！　

点开始 -》运行 -》输入regedit，确定，打开注册表，找到HKEY_CURRENT_USER\IDENTITIES\{C010EA75-8A22-4DC2-BC9F-37BDFDC60112}\SOFTWARE\MICROSOFT\OUTLOOK EXPRESS\5.0      找到其中的compact check count项，把值改成1问题就可以解决啦!

{C010EA75-8A22-4DC2-BC9F-37BDFDC60112}这个GUID每台电脑可能会不一样，需要自己找一下。 当compact check count项的值超过100（十进制）或者64（十六进制），outlook就会出现上面的提示，每开关一次outlook，compact check count项的值就会加1.

对于WindowMobile 上面的程序，微软有一个很详细的要求文件“Designed for WindowsMobile™ Software Application Handbook for Smartphone”。

 

 

这份文件大体来说还是很清楚的，里面把程序的方方面面都说得很清楚，但是有关参数NoUninstall地方是非常费解的。

 

首先根据：

Required: Packages Must Have Setup XML (Smartphone WAP Provisioning)

The Setup XML is generated automatically by CABWizSP. If you wish to create your CAB

manually, you will also have to create this Setup XML manually.

我们可以通过CABWizSP和自己写的一个inf文件生成一个cab文件。

命令如：cabwizsp d:\gbcab\fordopod.inf /dest d:\gbcab /cpu ARM4

inf文件的格式可以参照：

http://msdn.microsoft.com/library/en-us/wcesetup/html/_wcesdk_Creating_an_inf_File_for_the_CAB_Wizard.asp?frame=true

但是一看第二个要求：

Required: Provisioning XML File Must Include Install CSP XML with NoUninstall

The provisioning XML file should include an Install CSP section at the start of the

document, just below the <wap-provisioningdoc> element. This Install CSP XML should

also include the NoUninstall parm.

麻烦了！

CABWizSP生成的cab文件中没有NoUninstall参数！

 

从微软的资料来看，NoUninstall参数是为了使应用程序在安装的时候不生成任何卸载相关的信息而设置的，如果cab文件的_setup.xml中如果没有这个参数的话，则默认是生成卸载信息的，如果_setup.xml中有该参数，而且值为1的话，那么安装包安装之后则不回生成任何的卸载信息，那么在设置的“删除程序”里面是找不到你的安装的cab。

 

查资料后，你会发现CABWizSP是可以带一个参数/nouninstall, 不过使用过这个参数后你会发现，加入这个参数CABWizSP是可以生成一个带NoUninstall参数的_setup.xml，但是实际上，这个参数的值为1，导致你的应用程序不能卸载！

 

不能卸载的程序显然不能通过测试！

因为微软有这样的要求：

Required: Application Must Install/Uninstall Correctly

 

最后只好把CABWizSP生成的cab文件的内容解出来（windows自己就可以解压，当然你也可以使用winrar）。把里面_setup.xml文件修改好（在<characteristic type="Install">后面加入如下：<parm name="NoUninstall" value="0" />），然后在使用makecab来重新打包文件，当然可能你还需要cabsigner来对你的cab文件进行签名。

 

 

使用makecab之前，你需要生成一个有以下内容的ddf文件：

 

.Set Cabinet=ON

.Set Compress=OFF

.Set CabinetFileCountThreshold=0    ; no files per cabinet threshold

.Set FolderFileCountThreshold=0     ; no files per folder threshold

.Set FolderSizeThreshold=0          ; no folder size threshold

.Set MaxCabinetSize=0               ; no max size for the cabinet

.Set MaxDiskFileCount=0

.Set MaxDiskSize=0

.Set ReservePerCabinetSize=6144        ; for web signing

.Set ReservePerDataBlockSize=0

.Set ReservePerFolderSize=0

.Set UniqueFiles=OFF

 

.Set DiskDirectory1=d:\gbcab

.Set DiskLabel1=Setup

 

;

; to be filled out by the CABWIZ.exe program

;.Set InfFileName=

;.Set RptFileName=

;.Set CabinetName1=

;

; followed by the list of files

.Set InfFileName=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\wiz4EC.tmp

.Set RptFileName=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\wiz4ED.tmp

.Set CabinetName1=yourtarget.cab

.Set ReservePerFolderSize=32

.Set Compress=on

;这下面是_setup.xml文件的路径和setup文件的路径

;格式为： 源文件全路径 _setup.xml里面对应的文件名

d:\gbcab\_setup.xml _setup.xml

D:\gbcab\Setup.dll 000Setup.999

.New Folder

;这下面是你的文件的列表

;格式为： 源文件全路径 _setup.xml里面对应的文件名

D:\gbcab\eb_en.ebd 000eb_en.004

D:\gbcab\eb_sc.ebd 000eb_sc.003

 

然后使用命令：

makecab /F d:\gbcab\your.ddf

你就可以生成yourtarget.cab；然后就可以使用cabsigner对你自己的cab进行签名。

 

Designed for WindowsMobile™ Software Application Handbook for Smartphone 还对其他的方面提出了要求，我感觉我们还需要注意的是：

1．  Dll文件只能放入到\storage\windows目录或者程序本身的目录下（当然我只是针对非rom程序）。

2．  \storage\windows和\windows目录只能放置dll。

3．  程序的目录必须在\storage\program file下面。

4．  程序必须能够正常安装卸载，请注意：如果你的程序总是保持一个或者多个你通过cab文件安装上去的文件的可写句柄或者FILE *，你的程序是不能够正常卸载的，但是只读的没有问题。

5．  程序卸载之后应该能够自动清除所有文件（包括程序安装之后才产生的文件）和注册表项。

6．  界面上必须遵循Smartphone的风格，如右键菜单，spinner控件等等。

7．  任何程序都不能阻止用户接电话。

 

其它部分就不多说了，大家仔细对照Designed for WindowsMobile™ Software Application Handbook for Smartphone就是了。

1、编写inf文件
可以参考POCKET PC 2003的AppInst例子，以及Windows Mobile 5.0 SDK帮助文档Deploying Windows Mobile Applications > How to Package and Distribute Windows Mobile Applications

sample.inf

[Version]
Signature   = "$Windows NT$"        ; required as-is
Provider    = "Microsoft"           ; maximum of 30 characters, full app name will be " "
CESignature = "$Windows CE$"        ; required as-is
 
[CEStrings]
AppName     = "Mine Sweeper"        ; maximum of 40 characters, full app name will be " "
InstallDir  = %CE1%\%AppName%       ; Program Files\Mine Sweeper

; Directory Identifier Pocket PC Directory
; %CE1% \Program Files
; %CE2% \Windows
; %CE4% \Windows\StartUp
; %CE5% \My Documents
; %CE8% \Program Files\Games
; %CE11% \Windows\Start Menu\Programs
; %CE14% \Windows\Start Menu\Programs\Games
; %CE15% \Windows\Fonts
; %CE17% \Windows\Start Menu
 
[SourceDisksNames]                  ; directory that holds the application's files
1 = , "Common Files",,Common        ; disk_id = ,comment,,path (absolute or relative paths)
 
[SourceDisksFiles]                  ; list of files to be included in .cab
bigexpl.wav = 1
miniwin.wav = 1
winmine.exe = 1
 
[DefaultInstall]                    ; operations to be completed during install
CopyFiles   = CopyToProgramFiles
AddReg      = RegData
CEShortcuts = Shortcuts  
 
[DestinationDirs]                   ; default destination directories for each operation section
CopyToProgramFiles    = 0, %InstallDir%
Shortcuts   = 0, %CE14%             ; \Windows\Start Menu\Programs\Games
 
[CopyToProgramFiles]                ; copy operation file list
"winmine.exe", winmine.exe
"miniwin.wav", miniwin.wav
"bigexpl.wav", bigexpl.wav
 
[RegData]                           ; registry key list
HKCU,Software\%AppName%,MajorVersion,0x00010001,1
HKCU,Software\%AppName%,MinorVersion,0x00010001,0
 
[Shortcuts]                         ; Shortcut created in destination dir, %CE14%
%AppName%,0,winmine.exe

 

2、用cabwiz命令生成cab文件
cabwiz sample.inf /compress
/compress命令只能用在Windows Mobile以后的版本