专利名称：资源清单的制作方法
技术领域：
本发明一般涉及计算机应用程序和操作系统，尤其涉及用于更有效地作出并使用与可本地化用户界面(UI)资源分离地储存功能代码和语言中立数据的应用程序或操作系统的系统和方法。
背景技术：
由于计算机变得在世界上越来越流行，对为不同语言和/或场所优化或本地化的不同的各种操作系统或应用程序的需求增加，而且与生产、更新和维护大量这类不同版本关联的额外开销成本也随之增加。操作系统通常在单个二进制实体中一起包括代码、数据和语言专用UI资源，使得对任一部分的修改需要对整个实体的更新。由此，必须对每一感兴趣的语言提供诸如按照安全补丁的更新。这被称为“本地化”，每一结果版本被称为“本地化”版本。由于在大多数需要变化的情况下变化出现在代码部分而非语言专用部分，生产大多数修补、更新等单独的本地化版本是浪费且昂贵的。此外，当需要快速更新响应时，如在发表安全修补中，由生成修补的许多不同的特别本地化版本的需要所导致的延迟将使用户在不能接受的时间段内处于未保护状态。通常在这种情况下，处于低优先级场所的用户负担延迟的压力，因为通常首先生成较高优先级场所的本地化版本。
一种解决方案是从语言专用数据中分离语言不相关代码和数据，使得仅可对语言不相关代码和数据作出修改，包括安全补丁等。以这一方式，可快速并有效地开发单个安全补丁并在世界范围内分发，并仍允许操作系统和应用程序的本地化版本的制造保持不变。这一解决方案在2003年5月12日提交的名为“具有语言中立组件的分叉操作系统”的申请号10/435,858中有详细描述，其揭示通过整体引用结合于此。
不幸的是，为单独的语言中立组件和语言专用组件提供的解决方案可对甚至是仅为相对较少的市场本地化的相对简单的应用程序快速导致大量的难以管理的文件。即使是具有大约500个组件文件的简单应用程序可需要超过5000个对应的语言专用组件，而仅为欧洲市场本地化该应用程序。如此大量的文件可显著地降低有效编译并分发新版本或补丁的能力。另外并且更值得关注的，大量的文件将不利地影响应用程序或操作系统的性能，因为它们需要加载两个或更多的文件一个语言中立文件和一个或多个语言专用文件。此外，必须扩充额外的资源以保护大量的文件免遭安全破坏或其它恶意代码。最后，由于许多现代的操作系统以64千字节的粒度分配虚拟存储器，并以4千字节的粒度分配物理存储器，加载小于64千字节的大量文件将浪费并使虚拟存储器产生碎片。小于4千字节的文件将具有更负面的效果，因为它们将影响虚拟和物理存储器两者。操作系统具有大小小于4千字节的非寻常量文件(即，大于400个)并非不常见的。
发明内容
本发明的实施例允许应用程序或操作系统及其“修补”(如，在应用程序或操作系统的发布之后分发的补丁和更新)的生产，该应用程序或操作系统具有涉及代码和不可本地化数据的语言中立部分，以及涉及应用程序或操作系统使用或令其可用的可本地化资源的语言专用部分。为将对应于语言专用部分的文件的数量最小化，多个语言专用部分可储存在单个文件结构中并从其访问。
在一个实施例中，为将多个语言专用组件组合成单个二进制文件提供了一种资源工具。该资源工具可接受一配置输入，指定应当将哪些语言专用组件组合成单个文件，并可生成一适当的组合文件。
在另一实施例中，为将多个语言专用组件组合成单个二进制文件提供了一种文件格式。该文件格式可规定对个别语言专用组件的访问，并维护每一语言专用组件的完整性。
在又一实施例中，一种清单适用于提供语言专用资源查找服务，使得可利用语言专用资源的代码可查找适当的资源，包括查找适当的文件并查找文件中适当的资源位置。另外，该清单可向开发者提供确定并记录哪些资源可被本地化以及哪些资源应当保持语言中立的机会。在本发明的一个实施例中，资源加载适用于当查找并加载资源时使用清单。
在再一实施例中，更新编译器，如华盛顿州雷蒙德市的微软公司的Windows资源编译器(RC.EXE)，以读取清单信息并相应地将语言中立资源和语言专用资源编译成单独的资源文件，如.res文件。以这一方式，链接器然后可将语言中立资源和语言专用资源链接到单独的PE二元体(binary)，其一用于语言中立数据和功能代码，另一用于可本地化资源。可本地化资源然后可被进一步组合成单个或多个文件，提供了文件管理服务和操作中的提高的效率。
尽管本发明的描述主要着眼于创建和使用分叉操作系统，可以理解，本发明所描述的分叉的许多原理和好处也可应用到非操作系统的应用程序中。由此，在本发明的更多实施例中，考虑实质上具有语言中立部分和可本地化部分的分叉应用程序。当参考附图阅读以下说明性实施例的详细描述时，可以更清楚本发明的另外的特征和优点。
尽管所附权利要求书以细节阐明了本发明的特征，当结合附图阅读以下详细描述时，可以最好地理解本发明及其目的和优点，附图中图1是一般示出了可实现本发明的实施例的示例性装置体系结构的框图；图2所示是在单个二元体中具有代码部分和资源部分的现有应用程序二元体的体系结构图；图3所示是一种应用程序配置的体系结构图，其中，该应用程序在单独的二元体中具有一语言中立代码二元体部分和一语言相关资源部分；图4所示是依照本发明的一个实施例的资源压缩模式的文件格式的体系结构图；图5所示是本发明的资源清单的示例性结构的关系图；图6所示是依照本发明的一个实施例在单独的二元体中创建一语言中立代码二元体部分和一语言相关资源部分的数据流的示意图；图7所示是依照本发明的一个实施例在单独的二元体中创建一语言中立代码二元体部分和一语言相关资源部分所采取的步骤的流程图；图8所示是依照本发明的一个实施例在运行时加载语言相关资源的数据流的示意图；以及图9所示是依照本发明的一个实施例在运行时加载语言相关资源所采取的步骤的流程图。
具体实施例方式
多个元素可用于最小化随操作系统或应用程序分发并由其使用的提供语言专用功能的个别语言专用文件的量。最初，可确定语言专用的数据。例如，向用户呈现的对话框可以是语言专用的，菜单选择或拼写检查选项也可以是语言专用的。这一判定可被归档在清单中，清单可作为编译阶段的部分连同语言专用数据和语言中立代码和数据一起被编译成一个或多个对象文件和资源。
在编译阶段之后，对象文件和资源可通过链接工具链接在一起以创建可移植可执行文件和包含语言专用资源和信息的个别资源文件。资源工具可以个别语言专用资源仍由语言中立代码文件和可执行码引用的方式将多个语言专用文件组合成一个或多个更大的文件。资源工具也可接收外部输入，它可指定要被组合的精确的语言专用文件，并标识作为结果的更大的一个或多个文件。
可将各种语言专用组件压缩成单个文件的方式可包括对编译阶段的修改，如对资源编译器的修改，并可包括额外的软件的使用，如压缩应用程序，它使用预定义的结构将指定的语言专用组件压缩成单个文件，该预定义结构被设计成令语言中立代码和数据仍引用现在压缩的语言专用文件。可将各种语言专用组件压缩成单个文件的方式还可包括对指定语言中立代码和数据以及语言专用组件之间的关系的资源清单的引用，包括该语言专用组件是否被组合成单个文件。
以下描述将提供关于计算环境、代码和数据划分成语言中立和语言专用组件、多个语言专用文件压缩成单个文件、以及提供给各种机制以启用这一压缩的信息，包括这些机制使用的资源清单的描述的进一步细节。
计算环境转向附图，其中，相同的标号标识相同的元件，示出本发明在合适的计算环境中实现。尽管并非所需，但本发明将在计算机可执行指令的一般上下文环境中描述，计算机可执行指令如由个人计算机执行的程序模块。一般而言，程序模块包括例程、程序、对象、组件、数据结构等等，执行特定的任务或实现特定的抽象数据类型。此外，本领域的技术人员可以理解，本发明可以使用其它计算机系统配置来实践，包括手持式设备、多处理器系统、基于微处理器或可编程消费者电子设备、网络PC、小型机、大型机等等。本发明也可以在分布式计算环境中实践，其中，任务由通过通信网络连接的远程处理设备来执行。在分布式计算环境中，程序模块可以位于本地和远程存储器存储设备中。
本描述从可在用于实现本发明的示例性系统中使用的通用计算装置的描述开始，之后将参考图2和随后的附图更详细地描述本发明。现在转向图1，以常规个人计算机20的形式示出了通用计算装置，包括处理单元21、系统存储器22以及将包括系统存储器22的各类系统组件耦合至处理单元21的系统总线23。系统总线23可以是若干种总线结构类型的任一种，包括存储器总线或存储器控制器、外围总线以及使用各类总线结构的局部总线。系统存储器包括只读存储器(ROM)24和随机存取存储器(RAM)25。基本输入/输出系统(BIOS)26，包含如在启动时协助在计算机20内的元件之间传输信息的基本例程，可储存在ROM24中。计算机20还包括用于对硬盘60进行读写的硬盘驱动器27、用于对可移动磁盘29进行读写的磁盘驱动器28以及用于对可移动光盘31如CDROM或其它光媒质进行读写的光盘驱动器30。
磁硬盘驱动器27、磁盘驱动器28以及光盘驱动器30分别通过硬盘驱动器接口32、磁盘驱动器接口33和光盘驱动器接口34连接至系统总线23。驱动器及其相关的计算机可读媒质为个人计算机20提供了计算机可执行指令、数据结构、程序模块和其它数据的非易失存储。尽管这里描述的示例环境采用了硬盘60、可移动磁盘29以及可移动光盘31，本领域的技术人员可以理解，示例性操作环境中也可以使用用于储存数据的其它类型的计算机可读媒质，包括盒式磁带、闪存卡、数字多功能盘、Bernoulli盒式磁盘、随机存取存储器、只读存储器、存储区网络等等。
多个程序模块可储存在硬盘60、磁盘29、光盘31、ROM24或RAM25中，包括操作系统35、一个或多个应用程序36、其它程序模块37以及程序数据38。用户可以通过输入设备，如键盘40以及定位设备42向个人计算机40输入命令和信息。其它输入设备(未示出)可包括麦克风、操纵杆、游戏垫、圆盘式卫星天线、扫描仪等等。这些和其它输入设备通常通过耦合至系统总线23的串行端口接口46连接到处理单元21，但也可以通过其它接口连接，如并行端口、游戏端口或通用串行总线(USB)。监视器47或另一显示设备也通过接口，如视频适配器48连接到系统总线23。除监视器之外，个人计算机通常包括其它外围输出设备(未示出)，如扬声器和打印机。
个人计算机20可以在使用到一个或多个远程计算机，如远程计算机49的逻辑连接的网络化环境中操作。远程计算机49可以是另一个人计算机、服务器、路由器、网络PC、对等设备或其它公用网络节点，并通常包括许多或所有上述与个人计算机20相关的元件，尽管在图1中仅示出了存储器存储设备50。图1描述的逻辑连接包括局域网(LAN)51和广域网(WAN)52。这类网络环境常见于办公室、企业范围计算机网络、内联网以及因特网。
当在LAN网络环境中使用时，个人计算机20通过网络接口或适配器53连接至局域网51。当在WAN网络环境中使用时，个人计算机20可包括调制解调器54或其它装置，用于通过WAN 52建立通信。调制解调器54可以是内置或外置的，通过串行端口接口46连接至系统总线23。描述的与个人计算机20相关的程序模块或其部分可储存在远程存储器存储设备中，如果存在的话。可以理解，示出的网络连接是示例性的，也可以使用在计算机之间建立通信链路的其它装置。
在以下描述中，将参考由一个或多个计算机执行的行动和操作的符号表示来描述本发明，除非另外指明。由此，可以理解，这类行动和操作，有时称为计算机执行的，包括计算机的处理单元对以结构化形式表示数据的电信号的操纵。这一操纵转换了数据或在计算机的存储器系统中的位置上维护它，从而以本领域的技术人员都理解的方式重配置或改变了计算机的操作。维护数据的数据结构是存储器的物理位置，具有数据的格式所定义的具体特性。然而，尽管在上述的上下文环境中描述本发明，它并不意味着限制，如本领域的技术人员所理解的，后文所描述的行动和操作的各方面也可以硬件实现。此外，可以理解，尽管本发明的描述主要着眼于创建和使用分叉操作系统，本发明所描述的分叉也可应用到应用程序。
语言相关数据的分隔转向图2，示出了一个体系结构图，它示出了现有应用程序的一个实例。特别地，所示的应用程序201是包括代码部分203和资源部分205的混合的单个二元体。这一传统的体系结构导致对代码部分203或资源部分205的更新过程中的难度。特别地，代码部分203一般是语言中立的，而资源部分205一般很大程度是语言专用的。应用程序的发布之后的大多数更新涉及应用程序的代码部分203而非资源部分205的修补和补丁。由此，尽管实质上可在发布之前改变代码部分203和资源部分205，它们在发布之后以显著不同的各自的频率改变。
然而，在现有体系结构的示例中，对代码部分203的变化以以下方式使涉及代码部分203和资源部分205的变化和重安装变得必需。首先，对作为代码部分的基础的源代码作出改变。下一步，组合新源代码和旧资源以生成包含期望的修补的新的单个二元体。注意，对于资源的每一语言专用版本，必须以这一方式创建新的二进制文件。下一步，将本地化的二元体分发到适当的相应场所。对于使用多个语言的公司或实体，通常在这一阶段获取多个单独的二元体。最后，在需要修补的机器上(如上述个人计算机20或其它计算装置)安装更新的二元体。在使用多个语言的场所，必须对每一机器安装适当的语言修补。
现在参考图3，示出了依照本发明的一个实施例的分叉应用程序体系结构。特别地，示出应用程序301包括两个单独的二元体—包括代码和语言中立数据的语言中立二元体303，以及本地化或语言专用二元体305之一。语言中立二元体303包括不可本地化的资料，如不需要从应用程序的一种语言版本翻译到下一语言版本的资料。语言专用二元体305包括已本地化的资料，即，它适用于以特定的语言显示。通常可本地化的资料的非穷尽示例包括UI文本和图形以及应用程序帮助文档。
在所示的示例中，依照本发明的一个实施例，示出语言专用二元体305包括多个资源包307、309、311，分别对应于美国英语(307)、日语(309)和法语(311)，尽管也可考虑在本发明的实施例中应用程序将仅具备单个资源包，提供的资源包与用户或购买者的语言相匹配，或另外选择。可以理解，示出的具体资源包(英语、日语和法语)仅为示例性的，除图3具体示出的之外，可以感兴趣的任一语言提供资源包。注意，可本地化和不可本地化资源之间所示的分隔较佳地不仅包含在系统PE二元体(DLL、EXE、OCX、STS等)中，而且也包含在任一数据或其它形式的二元体中，如XML数据或HTML数据。
当安装时，依照本发明的一个实施例，图3的体系结构包括方便操作系统查找适当的资源的清单或其它记录313。特别地，该清单允许通过将要检索的资源的标识符映射到适当的资源包中的资源位置来本地化。例如，应用程序所驻留的机器可由日本的用户使用，并由此具有日语资源包。较佳地，系统设置指示如果存在多个资源包时使用哪一个。当检索资源，如对话框时，应用程序301的代码部分303的例示调用具有与期望的对话框关联的标识符的控制清单313的代码。控制该清单的代码可在查找该资源之后转发该调用，或可向调用实体返回位置的指示。
压缩多个语言专用文件在如图1所示的计算系统20等系统上，如图3所示的应用程序301等大量应用程序的安装可导致难以操纵的语言专用二进制文件的数量，如语言专用二进制文件305。大量的文件通过每次在例示应用程序时使大量的文件输入/输出操作成为必需，降低了计算系统20的性能。如本领域的技术人员所已知的，I/O操作很难加速，由此减少了作为提高计算系统的效率的最可行选项而执行的I/O操作的数量。此外，语言专用二进制文件305一般较小，并通常在大小上小于64千字节。因此，由于许多现代操作系统以64千字节的增量保存虚拟存储器，由于加载语言专用二进制文件305的存储器使用可显著地大于语言专用二进制文件的总计大小，因为每一文件将被加载到远大于该文件本身的存储器片段。由于系统中打开的每一文件占用系统文件句柄以及其它资源，应用程序中太多打开的文件可导致降低的系统性能以及增加的系统范围资源消耗。
如所见的，如果一个或多个语言专用二进制文件305被压缩成单个文件，则可实现由于减少的存储器使用和减少的文件I/O操作的效率。转向图4，示出了压缩资源文件401包括两个资源文件，即资源文件A(409)和资源文件B(411)。资源文件A和B可以是语言专用二进制文件305的任一个，如美国英语资源包407和日语资源包409，或者它们可以是对应于多个应用程序的语言专用二进制文件，其中，被压缩成诸如文件401等单个文件的每一语言专用二进制文件对应于一特定的语言。由于给定的用户可能周期性地仅使用一种语言，如果压缩语言专用二进制文件都是用于同一语言，并且都对应于不同的应用程序，则可消除大量的文件I/O操作。由此，以下文进一步描述的方式，如果用于两个或多个不同的应用程序的语言专用资源包含在同一文件内，该文件仅需被加载一次，从而节省了一个或多个文件I/O操作。
压缩资源文件401可包含压缩资源文件头403，它可整体提供与压缩资源文件401相关的信息。例如，头403可包含可用于核实压缩资源文件401实际上是这一文件的签名。这一签名可以标识文件401包含语言专用二进制文件的字符串开始，随后是唯一地标识每一压缩资源文件的全局标识符。压缩资源文件头403也可包含指定包含在压缩资源文件中的资源文件数量的条目。可任选地，头403也可对每一资源文件指定偏移地址以唯一地标识该资源文件在压缩资源文件内的起始处。例如，头403可包含指定两个资源文件，即资源文件A(409)和资源文件B(411)包含在压缩资源文件401内的条目，并且头403也可指定资源文件A(409)在从文件401的起始处的512字节的存储器位置开始，并且资源文件B(411)在从文件401的起始处的8096字节的存储器位置开始。可选地，包含在头403内的个别资源地址可以是到包含的资源文件409和411的起始处的任一类型的索引，而无需是实际的存储器偏移标识符。压缩资源文件头403也可指定头403的大小以及压缩资源文件401的大小，以在读头403或将文件401加载到存储器中时帮助其它进程。
包含在压缩资源文件401内的每一资源文件可具有其自己的头，以提供关于该资源文件的相关信息。该头信息可直接跟随在压缩资源文件401中的压缩资源文件头403之后，如图4所示。图4中的资源文件头，如资源文件A头405和资源文件B头407彼此相邻地定位，以方便文件401的加载。在替换的实施例中，头405和407可与其各自的资源文件，如文件409和411相邻地定位。资源文件头可包含其各自的资源文件的文件名，并也可包含资源文件的版本以及校验和以提供加载软件可通过其确保加载了正确的资源的信息。在一个较佳的实施例中，校验和是MD5资源校验和。资源文件头也可指定头的大小以及资源文件的大小，以当读资源文件头或将资源文件加载到存储器中时帮助其它进程。
如果资源文件，如资源文件409在压缩资源文件401内的定位未在压缩资源文件头403中指定，则资源文件头，如头405可包含它所涉及的个别资源文件的位置。再次，如上所述，位置信息可以是实际的存储器偏移，如从文件401的起始处的偏移，或可以是对资源文件的任一类型的索引。由于某些操作系统或其它加载机制可需要资源的起始存储器地址是偶数，可在资源之间，如资源文件A(409)和资源文件B(411)之间使用填充。在这一情况下，资源文件头，如头405可指示填充的存在，甚至可指定填充的长度。
资源文件，如资源文件A(409)或资源文件B(411)主要可包含资源数据本身。然而，资源文件中也可包含额外的信息以帮助加载或请求该文件的系统。例如，资源文件可包含签名，类似于上述文件401的签名。另外，资源文件可包含资源校验和，如果包含在资源头中的版本信息如上所述不同于请求应用程序的版本，它可用于确认资源文件。资源文件也可包含如果确定当前资源文件不是正确的资源时帮助找出适当的资源的信息。
压缩资源文件401的体系结构允许多个资源文件包含在单个文件结构中，从而减少了文件I/O操作的数量并提高了存储器的有效使用。可使用各种策略来确保最可能一起使用的资源文件储存在单个压缩资源文件中。例如，应用程序301可以是较大的应用程序的一个组件。在这一情况下，应用程序301可用构成该较大应用程序的其它组件来例示。因此，包含美国英语资源包307和构成较大应用程序的其它组件的美国应用资源包的单个压缩资源文件将是需要加载到存储器中的唯一语言专用资源文件，并且多个组件的每一个将具有对其各自的语言专用资源的访问。类似地，如果应用程序301是操作系统文件，则包含资源包307和一般用应用程序301加载的其它操作系统文件的等效资源包的单个压缩也将是需要加载到存储器中以向用应用程序301加载的所有操作系统文件提供语言专用资源的唯一资源。如所见，如果被压缩成压缩资源文件401的资源文件，如资源文件409和411是用于同一语言的语言专用文件，并且如果那些语言专用文件对应于一般共同例示或使用的应用程序，包括组件和系统文件，则可以获得更大的效率。
也可存在不涉及其它组件或文件的应用程序，使得那些组件或文件会与应用程序在同一时刻使用。在这一情况下，替代允许应用程序的语言专用资源文件作为单独的文件存在，而是可以压缩资源文件为64千字节，或64千字节的倍数的方式将这些语言专用资源文件与任何其它语言专用资源文件一起压缩。如上所述，由于操作系统通常将文件加载到大小为64千字节的存储器片段中，将每一个都小于64千字节的多个资源压缩成64千字节或稍小的压缩文件不导致任何额外的存储器使用。相反，压缩资源文件有可能节省至少一个文件I/O操作，因为总是存在压缩成该压缩资源文件的另一资源被调用而压缩资源文件仍被加载到存储器的可能性。因此，将多个资源文件，如语言专用资源文件压缩成一个或多个压缩资源文件一般是有益的。
资源清单如上所述，用户接口资源越来越多地储存在外部辅助资源文件中以方便语言中立性。该分支存储模式可增加查找外部资源的复杂度并引发标识可本地化资源的需求。由此，本发明的又一方面揭示了一种允许开发者控制应当如何本地化资源以及本地化哪些资源，并向系统给予资源文件位置、版本校验和等必需信息的系统和方法。作为结果，应用程序可执行二元体的构建过程可创建正确的语言中立映象，并且资源加载器能够有效地为在运行时请求资源的模块绑定外部资源。
为在编程代码及其资源之间创建紧密的联系，可采用先前描述的资源清单。在本发明中，资源清单是允许组件所有者描述资源信息，如资源版本、文件路径和资源类型和项目的公用格式。在一个较佳的实施例中，一种基于说明性可扩展标记语言(XML)的模式允许开发者描述本地化或语言专用资源文件及其相关的资源信息，并控制资源可本地化性。然后可以开发工具和进程以将资源清单作为格式中的嵌入式数据构建成二元体，以允许资源管理器有效并精确地跟踪组件资源信息。
资源清单采用两种形式，源形式和二元形式。在源形式中，资源清单是伴随组件的源代码的基于XML的说明性源文件。在二元形式中，资源清单是具有可嵌入到组件二元体的资源部分的二元格式的新资源类型。从源形式的观点来看，资源清单可给予组件的所有者对应当如何由构建和本地化过程处理资源以及运行时资源加载的控制。从二元形式观点来看，资源清单允许资源加载器具有更直接且精确的资源信息，由此很大程度减少了资源加载器中外部资源后退搜索的需求，并由此改进了整个资源加载器和管理性能。资源清单也允许描述更有功效的本地化信息，如本地化资源类型、给定资源类型的本地化资源项目、位置以及改进资源管理的语言。应当注意，尽管在源级别上资源清单不是强制的—如果资源清单不在源中存在，然而可在构建过程中获取默认的一个资源清单。
采用资源清单提供了多个优点，主要是语言不相关性(即，资源清单元素不需要包括可本地化数据或属性)。另外，使用基于XML的模式提供了开放、有效和灵活的管理和维护—开发者能够容易地用Notepad应用程序或任一XML处理资源清单，因为不需要专门的工具。为用最大的灵活性和有效性定义资源清单，以下是连同图5的附随说明的示例性结构化基于XML的模式的描述。
<ElementType typeId＝″localization″>
<element type＝″unmanagedResources″minOccurs＝″0″maxOccurs＝″1″/>
<element type＝″namagedResources″minOccurs＝″0″maxOccurs＝″1″/>
</ElementType>
资源清单的根元素是localization 500，并且它较佳地在每一本地化的源代码文件和资源二元体中存在。本地化元素仅包含具有不同体系结构的主要资源类型—管理的和未管理的。在源级别，一个清单文件可被多个组件共享，因此它可包含未管理和管理的资源描述。在二元体级别，它通常要么是未管理的，要么是管理的。
<ElementType typeId＝″unmanagedResources″>
<attribute type＝″filePath″required＝″no″/>
<attribute type＝″filePathType″required＝″no″/>
<attribute type＝″applyDefaultManifest″required＝″no″/>
<attribute type″fileType″required＝″no″/>
<attirbute type＝″cmfIndex″required＝″no″/>
<attribute type＝″cmfFileVersion″required＝″no″/>
<attribute type＝″cmfFileName″required＝″no″/>
<element type＝″neutralResoures″nimOccurs＝″0″maxOccurs＝″1″/>
<element type＝″localizedResources″minOccurs＝″1″maxOccurs＝″1″/>
</ElementType>
未管理资源的标记的开始是unmanagedResources 502(元素类型managedResources 504为管理资源类型保留的)。所有未管理资源可在unmanagedResurces 502元素下描述，并且它包含基本本地化信息，如文件路径、文件夹类型和版本。
filePath属性指定了本地化文件路径。资源加载器可在执行默认搜索逻辑之前搜索该路径以查找本地化文件。文件路径可以是完整的绝对文件路径或以预定义本地化文件路径(如，％SystemRoot％、％windir％、％CurrentDir％、％ProgramFiles％、％muiFallback％)组成的相对路径。
filePathType属性指定了本地化文件文件夹组织约定。指定了目录和文件命名约定。目录约定的示例包括DIR_LANG_ID(经典的Win32语言id)、DIR_LANG_NAME(符合ISO 639的语言名)以及DIR_LANG_CULTURE(符合RFC1766的语言文化名)。在一个较佳的实施例中，DIR_LANG_CULTURE是默认属性。选择LANG_NAME和LANG_CULTURE指示本地化语言文件夹上的本地化文件搜索顺序(如，当指定LANG_NAME时，将在‘en-us’之前搜索‘en’以查找英语，而LANG_CULTURE将首先搜索‘en-us’)。文件命名约定的示例包括FILE_NAME_WIN32(<文件名>.<文件扩展名>.mui)以及FILE_NAME_MANAGED(<文件名>.resources.dll)。
applyDefaultManifest属性可包含0(否)或1(是)值。在一个较佳的实施例中，如果未指定applyDefaultManifest，则该值为1。当它为1时，将用默认公共资源清单文件分析组件的清单中未指定的资源类型。
fileType属性可包含1(本地化)、2(压缩本地化格式)、4(系统)和8(应用程序)的值。系统文件类型指示该组件是将资源语言与系统本地化匹配的系统文件。
cmfFileName属性包含压缩本地化格式文件的文件名。cmfIndex属性包含压缩本地化格式文件内的本地化文件的索引值。cmfFileVersion属性包含压缩本地化格式文件版本。
neutralResources元素包含了将被包含在语言中立二元体中的资源类型信息，，localizedResources包含了将被包含在本地化二元体中的资源类型信息。
要注释若干项目。首先，本地化资源二元体和语言中立代码二元体在源级别共享同一资源清单文件。某些属性和元素仅应用到一个二元体(如，filePath和filePathType仅应用到语言中立二元体)。第二，压缩本地化格式文件属性(即，cmfIndex、cmfFileVersion和cmfFileName)将在fileType是CMF时被使用。在一个较佳的实施例中，如果fileType未指定，则默认类型是非CMF。第三，后构建过程(下文详细描述)将覆写组件的CMF信息。CMF文件版本是CMF文件的独立版本，它与本地化文件版本无关。如必需，CMF文件版本可由公钥/私钥替换来获得更好的安全性。第四，在一个较佳的实施例中，当applyDefaultManifest属性是1，并且在默认清单和组件的清单之间没有冲突时，组件清单内的信息将覆写默认信息。
<ElementType typeId＝″neutralResources″>
<attribute type＝″fileVer″required＝″no″/>
<attribute type＝″checksum″required＝″no″/>
<element type＝″resourcesType″minOccurs＝″0″maxOccurs＝″*″/>
</ElementType>
<ElementType typeId＝″localizedResources″>
<attribute type＝″fileVer″required＝″no″/>
<attribute type＝″checksum″required＝″no″/>
<element type＝″resourcesType″minOccurs＝″0″maxOccurs＝″*″/>
</ElementType>
neutralResources元素506开始语言中立代码二元体中的资源项目的描述。在一个较佳的实施例中，如果neutralResources未在组件的源清单中使用，则其默认值为localizedResources下未指定的资源项目的剩余部分。fileVer和checksum属性在源级别不使用。在中立二元体中，neutralResources将包含真实的资源项目，由此fileVer和checksum属性应当具有值。这些值由本地化工具或RC.exe在构建时生成。应当注意，如果neutralResources和localizedResources下的资源项目相互冲突，则neutralResources将具有较高的优先级，或发出一错误。
fileVer属性指定文件版本。为核实本地化文件，依赖于文件版本，但是搜索和加载版本是昂贵的，因此在清单中具有该属性能改进性能。checksum属性指定了MD5传统本地化校验和。创建的校验和基于unmanagedResources/managedResources元素中的资源类型之一。该属性从源级别清单隐藏，并仅在二元体中显示。resourcesType元素指定资源类型。
在一个较佳的实施例中，如果开发者源中使用了localizedResources，则其值应当作为可本地化资源类型或名称的resourcesType存在。如果在本地化二元体中使用了localizedResources，则其值是本地化二元体中真实的资源项目。属性fileVer和checksum应当具有值。这些值由本地化工具在构建时(下文详细描述)填充。
注意，在一个较佳的实施例中，如果开发者源中使用了localizedResources，并且它具有resourcesType值且其值与neutralResources中的值重叠，则仅提取中立二元体中的类型的项目。同样，如果开发者提供资源清单文件，则它应当在neutralResources或localizedResources中具有至少一个resourcesType元素。
<ElementType typeId＝″resourcesType″>
<attribute type＝″typeName″required＝″yes″/>
<attribute type＝″typeId″required＝″yes″/>
<attribute type＝″itemId″minOccurs＝″0″maxOccurs＝1/>
<attribute type＝″itemName″minOccurs＝″0″maxOccurs＝1/>
</ElementType>
resourceType元素表示资源类型，并且可以多次使用。typeName属性指定了串类型。typeId属性指定了id类型。itemName属性指定了资源项目名串。imteId指定了资源项目id。
应当注意，仅需要typeName和typeId的一个条目。在一个较佳的实施例中，当itemName和itemId包含多个项目时，它们应当由空格字符来分隔。
构建时转向图6和7，示出了用于构建语言中立二元体的过程。构建过程在步骤700开始，输入组件源文件600、602、604以构建实用程序(build.exe以及makefile.def构建流程控制文件)606。继续到步骤702，由构建实用程序606确定该构建是否为语言中立。在一个较佳的实施例中，构建实用程序606可接受指示启动的构建过程是语言中立(即，LANG_NEUTRAL＝1→语言中立构建)还是非语言中立(即，LANG_NEUTRAL＝0→非语言中立构建)的参数(如，LANG_NEUTRAL，未图示)。如果未指定语言中立参数，则默认为非语言中立构建。
如果构建不是语言中立的，则构建过程在步骤704、706和708继续。在步骤704，构建实用程序606调用资源编译器(RC.exe)608。下一步，在步骤706，资源编译器608创建资源文件(.res)610。最后，在步骤708，构建实用程序606调用链接器实用程序(link.exe)614来创建非语言中立PE文件616。
另一方面，如果指定构建为语言中立的，则构建过程在步骤712继续，由构建实用程序606确定是否指定了资源清单文件604。在一个实施例中，构建实用程序606可接受指示清单604的文件名的参数(如，RC_NAMIFEST，未图示)。如果未指定该参数，则使用默认清单文件名。如果在源600、602的文件夹中找到清单文件604，则构建过程在步骤716继续。如果在源600、602的文件夹中未找到文件名，则可搜索源文件600、602的父和祖父文件夹来看是否存在清单文件604。如果未找到任何清单文件604，则构建实用程序606可在继续到步骤716之前在步骤714创建默认资源清单文件。
继续到步骤716，构建实用程序606包含来自清单文件604的资源类型信息。在步骤718，如果确定清单文件604指示要调节这一资源压缩模式，则构建实用程序606可从压缩资源文件获取资源文件信息。前进到步骤720，构建实用程序606确定是否要编译并链接源文件600、602、604。
如果不要编译和链接源文件600、602、604(即，它们是现有的二元体)，则构建实用程序606可调用一本地化资源编译工具(MUIRCT.exe)来创建中立和本地化PE文件，并向两个PE文件插入资源清单标记和校验和。
另一方面，如果要编译并链接源文件600、602、604，则构建过程继续到步骤724，构建实用程序606调用资源编译器(RC.exe)608。在一个实施例中，可修改资源编译器608以接受指示包含具有要编译成单独的资源(.res)文件610、612的类型/名字的资源的清单文件604的名字的开关(如，/q清单文件路径，未图示)。因此，在步骤726，构建实用程序606然后可分析组件的源清单文件604，并调用资源编译器(RC.exe)608以依照清单文件604中的清单资源类型/名字列表将可本地化资源分裂成中立文件(.res)610和本地化文件(.mui.res)612。另外，资源编译器(RC.exe)608更新清单文件604的资源元素506、508中的校验和属性，并将清单文件604插入到中立文件(.res)610和本地化文件(mui.res)612中。最后，在步骤728，构建实用程序606两次调用链接器实用程序(link.exe)614来构建两个单独的映象—语言中立映象616和语言专用资源映象618。
构建过程在步骤730结束，构建实用程序606调用bin放置实用程序(binplace.exe)以将中立PE616放置在bin文件夹中，并将本地化PE 618放置在bin\<langid>文件夹中。
后构建(post-build)依照上文详细描述的结构，多个个别的资源文件，如语言专用资源文件，可由后构建资源工具压缩成一个或多个压缩资源文件。这一资源工具可以是可被修改成接受指示可指定资源文件的分组的控制文件的存在的开关的现有资源工具，或者该资源工具可以是设计成仅压缩资源文件的新资源工具。
控制文件可指定资源文件被分组在一起，并可指定结果的压缩资源文件。在一个实施例中，要分组在一起的资源文件和结果的压缩资源文件可以是排序的n元组，使得最后一个条目或第一个条目总是结果的压缩资源文件，并且剩余的条目和资源文件被分组在一起。可选地，控制文件可依赖于标识符来指定要分组在一起的资源文件，并指定结果的压缩资源文件。在任一情况下，控制文件仅需为简单的文本文件，尽管本领域的技术人员可以明白，也可以使用更复杂的数据格式。为避免无数控制文件的需求，考虑单个控制文件可指定资源文件的多个分组。在一个实施例中，如果由于错误或其它原因控制文件不指定一组或多组资源文件的结果压缩文件，则资源工具可绕过这些资源文件的压缩，并保留它们未压缩。
转向图8，示出了应用程序810和820，它们类似于图3所示并在上文详细描述的应用程序301。应用程序810和820分别具有语言中立二元体部分819和829，并且应用程序810具有语言相关资源部分812、814和816，应用程序820具有语言相关资源部分822、824和826。每一语言相关资源部分也包含头，如语言相关资源812的头811。应用程序810和820可以是上述的构建过程的结果，或者它们可以是从未知的构建过程衍生的二进制文件，如可从不同的公司或开发者组接收的。
资源工具，如图8所示的资源工具801可从控制文件，如控制文件803接受输入以将指定的资源压缩成压缩资源文件格式。例如，控制文件803可指定可组合应用程序810和820的语言专用资源使得美国英语资源被组合成一个压缩资源文件。尽管图8未示出，控制文件803也可指定，例如日语资源被组合成第二压缩资源文件，法语资源被组合成第三压缩资源文件。
资源工具然后分别读取应用程序810和820的美国英语资源812和822，并将头811和821分别储存为压缩资源文件830的片段832和833。美国英语资源812和822的其余信息可分别被储存为压缩资源文件830的片段834和835。如上所述，片段834和835本身可包含大批资源数据。同样如上所述，如果压缩资源文件830使用需要个别资源文件头来包含存储器偏移信息或头811中最初未找到的其它信息的格式，这一信息可由资源工具801在创建压缩资源文件830时添加。
一旦资源工具801通过读、估算以及可能性编辑或向包含在资源812和822中的信息添加而创建了片段832、833、834和835，它可创建包含上述参考压缩资源文件头403所描述的某些或所有信息的头831。资源工具801然后可使用类似的方法来创建压缩资源文件，在本示例中，该压缩资源文件可以是从如控制文件803所指定的压缩日语资源814和824以及法语资源816和826所得的文件。可选地，资源工具801可依赖于已知的并行处理技术以在几乎同一时刻创建所有指定的压缩文件。
运行时由于资源，如语言专用资源现在可包含在单个文件中，因此在语言专用资源和语言不相关二元体中不再存在一对一映射。语言专用资源和语言不相关二元体之间缺乏一对一映射将语言不相关二元体的例示复杂化。
当没有一对一映射存在时，为更好地对照运行时方法，考虑图3所示的应用程序301，它在每一语言专用二进制文件305和语言中立二元体303之间确有一对一映射。在这一情况下，每一语言专用二进制文件可被命名、储存或另外标识为仅涉及语言中立二进制文件303。例如，可创建具有包含在文件夹内的语言专用文件的语言的标题或代码的一系列文件夹。由此，可存在包含所有包含美国英语数据的语言专用二进制文件，如图3所示的美国英语资源包307的名为“美国英语”或“0404”的文件夹。在该示例性实施例中，可命名包含在该文件夹内的每一语言专用二元体以反映其对语言中立二元体的关系。例如，如果语言中立二元体被命名为“foo.exe”，则美国英语语言专用二进制文件可被称为“foo.mui”，并且它可储存在美国英语文件夹中。在这一情况下，很容易查找语言专用资源，因为它们包含在预定义的文件夹中，并且以其对语言中立二元体的关系是显而易见的方式来命名。
然而，如所见，在语言中立和语言专用文件之间没有一对一对应性的情况下，上述过程不实用。因此，图9示出了一种新加载过程，它被设计成提供压缩资源文件设计所附带的效率，并在上文中详细枚举。如本领域的技术人员理解的，图9所示的步骤可由加载资源的一个或多个组件执行。这些组件可以是操作系统35、各种应用程序，如应用程序36或其它软件或实用程序的部分。此外，如本领域的技术人员也可以理解的，一般执行图9所示的步骤，因为例示或加载进存储器的组件需要额外的资源。作为示例，应用程序301的语言中立二元体303可能需要至少一个语言专用二进制文件305的存在。
返回到图9，步骤901指示已请求资源，并且该资源加载功能可确定要加载的资源的名字和位置，如路径。如上文详细描述的，这一信息可包含在与组件，如请求组件一起储存的清单中。一旦确定了要加载的资源的名字和位置，可在步骤903加载资源，并且在步骤905，资源加载功能可确定该资源是包含在独立的文件中还是在压缩文件中、当前请求或未请求的额外资源的可能性。加载功能用以确定文件类型的方法是检查头。如上文详细描述的，压缩资源文件头可包含具有可用于标识该文件类型的字符串的签名。在替换的实施例中，例如，加载功能可通过以上文详细描述的方式检查文件名或标识包含在与请求组件一起储存的清单中的信息，在步骤903之前执行步骤905的确定。
在步骤905，如果加载功能确定请求的资源不在压缩文件中，则该资源的加载可以已知的方式前进。例如，如果仍必需，加载功能可如步骤921所示的查找独立或“未压缩”文件。随后，如步骤823所示，加载功能可将独立文件存储器映射到请求加载资源的进程的地址空间。这一进程可以是请求语言专用资源的执行语言中立二元体，如二元体303。一旦被映射到请求进程的地址空间，在步骤925可继续加载请求的资源，由此向请求进程提供其资源，如语言专用资源。
然而，如果在步骤905加载功能确定请求的资源实际上一压缩文件，则在步骤907，加载功能可从请求资源的版本块引用压缩文件信息。如后文更详细描述的，包含在请求资源的版本块中的信息可用于确定正确的资源文件是否包含在压缩资源文件中。
在步骤909，加载功能可确定压缩文件是否已由另一进程加载。如上文详细描述的，通过使用压缩资源文件可获得效率，因为这一文件可减少文件I/O操作的数量。因此，为确保不会执行不必要的文件I/O操作，加载功能首先确定是否已加载了压缩资源文件。执行步骤909的检查的一种机制是使用散列密钥，例如，该密钥可包括请求的压缩文件的完整路径名以及包含在请求的压缩文件中的请求的语言专用资源的语言或语言标识符。可将这一散列密钥与类似获得的已加载压缩资源文件的散列密钥进行比较。如果两个散列密钥相等，则请求的压缩文件已被加载。如本领域的技术人员所已知的，存在许多执行检查的其它方法以确定请求的压缩资源文件是否已加载到存储器中。这类方法可包括比较文件的起始位、文件GUID等，并可相等地用于执行步骤909。
如果步骤909确定请求的压缩资源文件已被加载进另一进程，则加载功能可执行步骤915，并获取请求的资源的偏移信息，并还可获取请求的资源的版本和校验和。如上文详细描述的，偏移信息可包含在各种位置内，包括作为请求该资源的代码的一部分的清单、压缩资源文件的头以及个别资源本身。一旦获取的偏移信息，加载功能可将位于给定偏移的资源的版本信息和校验和信息与请求的版本和请求的校验和比较，后者如上所述可储存在清单中。
在步骤917，如果确定给定偏移处的资源的版本和校验和信息与请求的版本和校验和不匹配，则加载功能可还原到步骤921，如上所述，在确定请求的资源不在压缩文件中时可执行该步骤。由此，匹配版本和校验和信息的任一个或两个的失败可导致加载功能采取已知方法。然而，如果版本或校验和信息或两者都正确，则加载功能可前进到步骤919，在该步骤，将压缩成压缩资源文件的请求的资源映射到请求进程的进程地址空间，资源的加载可在步骤925继续。
返回到步骤909，如果加载功能确定请求的资源在先前未加载的压缩资源文件中，则加载功能可如步骤911所示查找并绑定到压缩资源文件。为方便资源共享，如包含在同一压缩资源文件中的资源，加载功能可如步骤913所示跨运行进程来存储器映射压缩资源文件。步骤913考虑跨进程共享文件的各种方法的任一种，包括在存储器分页区域创建并打开压缩资源文件，以及创建持久对象。如本领域的技术人员所已知的，当文件被多个进程共享时，可维护一计数器来确保当另一进程正在访问文件时，对文件的访问不被一个进程终止。以类似的方式，当共享压缩资源文件时，可使用计数器或类似的构造来跟踪当前访问该压缩资源文件的进程数。由此，尽管未在图9中具体示出，步骤915可包括跟踪由其它进程对压缩资源文件的使用的计数器的增加。
如所见，压缩资源文件结构和资源清单通过减少文件数量、减少文件I/O操作数量并在加载这一资源文件时通过减少浪费的存储器来提高效率。可以理解，描述了一种改进的操作系统体系结构以及生成、安装并使用该改进的操作系统体系结构的方法。鉴于本发明的原理可应用的许多可能的实施例，应当认识到，本发明参考附图所描述的实施例仅为说明性的，并不应当作为对本发明的范围的局限。例如，本领域的技术人员将认识到，以软件示出了说明的实施例的某些元素可以硬件实现，反之亦然，或者可在不脱离本发明的精神的情况下在排列和细节上修改说明的实施例。因此，此处所描述的本发明考虑处于所附权利要求书及其等效技术方案的范围内的所有这样的实施例。
权利要求
1.一种为组件创建语言中立和对应的语言专用资源文件的方法，其特征在于，所述方法包括获取一资源清单文件；依照包含在所述资源清单文件中的可本地化资源信息创建一语言中立文件和一语言专用资源文件；创建一校验和数据；以及用所述校验和数据更新一所述资源清单文件中的字段。
2.如权利要求1所述的方法，其特征在于，所述资源清单文件被指定。
3.如权利要求1所述的方法，其特征在于，所述资源清单文件未指定，并且使用一默认资源清单文件。
4.如权利要求1所述的方法，其特征在于，所述资源清单文件是基于可扩展标记语言(XML)的说明性文件。
5.如权利要求1所述的方法，其特征在于，所述可本地化资源信息驻留在一压缩的资源文件中。
6.一种包含用于执行一种为组件创建语言中立和对应的语言专用资源文件的方法的指令的计算机可读媒质，其特征在于，所述方法包括获取一资源清单文件；依照包含在所述资源清单文件中的可本地化资源信息创建一语言中立文件和一语言专用资源文件；创建一校验和数据；以及用所述校验和数据更新一所述资源清单文件中的字段。
7.一种在其上储存了一资源清单模式数据结构的计算机可读媒质，其特征在于，所述数据结构包括第一数据字段，包含表示指示所述模式包含资源本地化信息的元素的数据；第二数据字段，包含表示与用户接口资源关联的元素的数据；第三数据字段，包含表示所述第二数据字段的用户接口资源元素的语言依赖性的数据；以及第四数据字段，包含表示与用户接口资源类型关联的元素的数据。
8.如权利要求7所述的计算机可读媒质，其特征在于，所述第二数据字段表示未被管理的资源。
9.如权利要求7所述的计算机可读媒质，其特征在于，所述第二数据字段表示被管理的资源。
10.如权利要求7所述的计算机可读媒质，其特征在于，所述第三数据字段表示语言中立资源。
11.如权利要求7所述的计算机可读媒质，其特征在于，所述第三数据字段表示本地化的资源。
12.如权利要求7所述的计算机可读媒质，其特征在于，所述数据结构还包括第五数据字段，包含表示所述第二数据字段的用户接口资源元素的资源文件的文件路径的数据；第六数据字段，包含表示所述文件路径的文件路径类型的数据；以及第七数据字段，包含表示所述资源文件的文件类型的数据。
13.如权利要求7所述的计算机可读媒质，其特征在于，所述数据结构还包括第八数据字段，包含表示是否引用默认资源清单的指示的数据。
14.如权利要求7所述的计算机可读媒质，其特征在于，所述数据结构还包括第九数据字段，包含表示压缩的资源文件的文件名的数据；第十数据字段，包含表示所述压缩的资源文件的文件版本的数据；以及第十一数据字段，包含表示所述压缩的资源文件内的资源本地化文件的索引值的数据。
15.如权利要求7所述的计算机可读媒质，其特征在于，所述数据结构还包括第十二数据字段，包含表示资源文件的文件版本的数据；以及第十三数据字段，包含表示一校验和值的数据。
16.如权利要求7所述的计算机可读媒质，其特征在于，所述数据结构还包括第十四数据字段，包含表示与所述第四数据字段的用户接口资源类型关联的元素的名字的数据；第十五数据字段，包含表示与所述第四数据字段的用户接口资源类型关联的元素的标识符的数据；第十六数据字段，包含表示资源项目的名字的数据；以及第十七数据字段，包含表示所述资源项目的标识符的数据。
17.如权利要求7所述的计算机可读媒质，其特征在于，所述模式是基于可扩展标记语言(XML)的说明性文件。
18.一种组件所有者用于提供组件资源本地化信息的方法，其特征在于，所述方法包括确定可本地化资源；确定一可本地化资源文件夹约定；以及创建一资源清单文件。
19.如权利要求18所述的方法，其特征在于，它还包括指定所述资源清单文件到一资源编译器程序的路径。
20.如权利要求18所述的方法，其特征在于，所述资源清单文件是基于可扩展标记语言(XML)的说明性文件。
21.如权利要求18所述的方法，其特征在于，所述可本地化资源信息驻留在一压缩的资源文件中。
全文摘要
一种改进的应用程序体系结构包括具有一语言中立部分和一可本地化部分的分叉结构，为了效率被压缩成较大文件的较小组。该分叉结构允许应用程序的较容易的分发和更新，而减少的文件组提供了更有效的文件管理。可在编译阶段指定一资源清单以标识语言专用的元素和保持语言中立的元素。此外，可在编译后使用额外的软件以将多个可本地化元素压缩成单个文件。这一压缩软件可接收指定要压缩成较大文件的语言专用资源，以及哪些较大文件的身份。另外，可使用一种文件格式，它可包含多个语言专用资源，并可方便由相关的语言的不相关代码对个别的语言专用资源的检索和访问。
文档编号G06F9/44GK1609799SQ20041008828
公开日2005年4月27日 申请日期2004年10月22日 优先权日2003年10月23日
发明者F·N·褚, J·D·贝内特, M·G·艾尔-贾马尔, S·叶, S·邱, W·吴 申请人:微软公司