专利名称：以存储技术抽象方式在文件内创建文件系统的制作方法
技术领域：
本发明一般涉及诸如具有嵌入式操作系统的那些设备等计算设备，尤其涉及配置计算设备的非易失存储。
背景技术：
诸如个人数字助理、当代移动电话和手持式及袖珍计算机等移动计算设备正在变为重要且流行的用户工具。一般而言，它们变得足够小，使得它们极度方便，而消耗较少的电池功率，且在同时变得能够运行更强大的应用程序。
在制造这类设备的过程中，嵌入式操作系统映象通常被内建到每一设备的单块映象文件中，并储存在非易失存储中(如，NAND或NOR闪存、硬盘等等)。作为结果，必须从构成操作系统的各种部件预配置单块映象文件。此外，更新这一设备有时是必需或期望的，并需要对操作系统作出改变。
然而，当处理单块映象时，有许多缺点，包括为安装任一更新，需要替换整个映象(或可能其预定的子集)，这需要大量的资源，包括临时存储和带宽。迄今为止，使用了单块替换用于更新这类设备，因为更新操作系统的单独组件是一项困难的任务，这是由于各种冲突和依赖性。此外，任一这样的组件化会导致另一问题，因为仍需要初始映象用于制造，但是迄今为止初始映象本质上只是传输到设备上的比特的单块组。需要一种将操作系统映象组件转换成适合用作初始映象的基于文件系统的制造映象，而仍被设计成方便设备的组件化更新的机制。
发明内容
简言之，本发明提供了一种一般针对创建包含分区和文件系统布局的单个制造映象文件的方法和系统，在构建时，将个别的操作系统组件包安装到该映象文件中。该过程以一种存储技术抽象方式完成，使得该系统和方法无需关注底层存储(如，闪存)的类型，和/或底层存储强加在映象布局上的任何要求。相反，在单独的步骤中，对结果映象文件进行后处理(post-process)，包括定制该映象文件用于存在的实际类型的存储设备。
在一个实现中，在文件内创建各种类型的分区，每一分区对应于一个文件系统。将操作系统映象组件的集合(称为包)转换成基于文件系统的制造映象的分区。从该文件，可在制造过程中以使得映象更新技术稍后可利用设备上的同样的分区和文件模型的方式在设备上建立初始操作系统映象。
为将各种包转换成初始制造映象，创建单个制造映象文件，其中，按分区和文件系统布局排列映象。然后在需要时对该文件进行后处理，以在需要时添加用于在制造时安装其内容的元数据。
为构建最终被写入虚拟闪存中的该文件，创建各种分区。注意，总闪存的某些可由设备制造商为各种目的而保留，而让剩余的存储器可用，作为由操作系统组件和可任选用户存储使用的虚拟存储器。每一分区具有某一目的，并可被认为是其自己的文件系统。例如，可以有诸如用于更新加载器的二进制分区，以及用于内核(NK)分区的RAMIMAGE/ROMIMAGE分区。IMGFS分区可包含操作系统文件，用户存储分区可被指定为用于用户数据存储。在文件中创建主引导记录以指定分区。可在文件中包括另外的数据。
在一个实现中，盘映象实用程序创建该文件，并且映象后处理器添加元数据来准备用于写入期望的存储媒质中的文件。盘映象实用程序负责取出操作系统包，并基于如何在存储中排列分区的存储器描述(存储器配置文件)以及包应当如何被映射到该分区结构的描述(分区映射文件)，生成包含各种分区的输出文件，使每一包的内容储存在适当的分区中。此外，将可执行代码修正到适当的基于虚拟地址空间的地址。存储器配置文件为非易失存储和系统RAM都提供了操作系统运行时虚拟地址空间存储器映射。分区映射文件包含唯一地标识的包的列表，并用于将包映射到指定的分区。
后处理过程在输出文件上行动，以如特定存储技术所需的引入对分区和文件系统布局的任何修改。例如，可需要作出调整以处理不同的闪存部分管理闪存中的扇区级信息的不同方式。
当结合附图阅读以下详细描述时，可以清楚其它优点。
图1是一般表示可结合本发明的计算机系统的框图；图2所示是依照本发明的一个方面，用文件中用于维护作为映象写入嵌入式设备或其它媒质中的数据的相异分区构建的输出文件的框图；图3所示是依照本发明的一个方面用于配置输出文件的各种组件的框图；图4所示是依照本发明的一个方面配置输出文件的盘映象实用程序的总体流程的流程图；图5所示是依照本发明的一个方面确认存储器配置文件的逻辑的流程图；图6所示是依照本发明的一个方面负责核实包-分区映射文件并负责将指定的分区与包匹配的过程的流程图；图7所示是依照本发明的一个方面处理闪存元件的过程的流程图；图8所示是依照本发明的一个方面用于构造基于ROM/RAM的分区的过程的流程图；图9所示是依照本发明的一个方面用于写系统分区的过程的流程图；以及图10A和10B所示是依照本发明的一个方面，如由后处理过程所处理的在闪存中排列扇区和块的不同方法的框图。
具体实施例方式
示例性操作环境图1示出了一个这样的手持式计算设备120的功能组件，包括处理器122、存储器124、显示屏126和键盘128(可以是物理或虚拟键盘，或表示两者)。可存在麦克风129以接收音频输入。存储器124一般包括易失存储器(如，RAM)和非易失存储器(如，ROM、PCMCIA卡等等)。操作系统130驻留在存储器124中，并在处理器122上执行，如微软公司的Windows操作系统或另一操作系统。
一个或多个应用程序132被加载到存储器124中，并在操作系统130上运行。应用程序的示例包括电子邮件程序、调度程序、PIM(个人信息管理)程序、文字处理程序、电子表格程序、因特网浏览器程序等等。手持式个人计算机120也可包括加载到存储器124中的通知管理器134，它在处理器122上执行。通知管理器134处理如来自应用程序132的通知请求。同样，如下所述，手持式个人计算机120包括适用于将手持式个人计算机120连接到网络(包括作出电话呼叫)的网络软件136(如，硬件驱动程序等)和网络组件138(如，无线电和天线)。
手持式个人计算机120具有电源140，它被实现为一个或多个电池。电源140还可包括忽略内置电池或对其重新充电的外部电源，如AC适配器或加电对接托架。
图1所示的示例性手持式个人计算机120被示出为具有三种类型的外部通知机制一个或多个发光二极管(LED)142和音频生成器144。这些设备可直接耦合至电源140，使得当被激活时，即使手持式个人计算机处理器122或其它组件被关闭以保存电池能量时，它们也保留一段由通知机制指示的持续时间。LED 142较佳地不限时间地持亮，直到用户采取行动。注意，音频生成器144的当代版本使用当今手持式个人计算机电池的太多能量，因此它被配置成当系统的剩余部分被关闭时，或者在激活后的一段确定的持续时间之后被关闭。
注意，尽管示出了基本手持式个人计算机，然而，为实现本发明的目的，实际上能够以可由程序使用的某一方式接收数据通信和处理数据的任何设备都是等效的。
在文件内创建文件系统本发明一般针对安装和/或更新储存在基于微软WindowsCE.NET的便携式设备等小型移动计算设备上的软件，这些设备包括在其中将初始软件或软件更新写入诸如闪存等嵌入式设备的非易失存储器的那些设备。尽管如此，本发明提供了在总体上计算的益处，并由此可应用到其它计算设备和其它类型的存储，包括各种类型的存储器和/或其它类型的存储媒质，如硬盘驱动器。为简化目的，术语“闪存”在后文参考设备的可更新存储来使用，尽管可以理解，任一存储机制都是等效的。此外，术语“映象”一般包括初始软件安装映象以及对该映象的随后的软件更新的概念，即使仅更新该映象的一部分。
包含可执行代码和数据两者的映象可被应用到存储。可执行代码在安装时被定制到嵌入式设备的虚拟地址空间。依照本发明的一个方面，一般而言，映象更新技术将操作系统映象分裂成可单独更新的可更新组件，而维持任何跨组件的依赖性。如可以理解的，以方便对设备的初始安装以及对其随后的更新的方式排列初始映象。
依照本发明的一个方面，提供了一种将操作系统映象组件的集合(称为包)转换成基于文件系统的制造映象的系统和方法。这通过分区和文件系统模型来完成，使得能够创建一输出文件。从该文件，可在制造过程中以使得映象更新技术可稍后利用设备上同样的分区和文件系统模型的方式在设备上建立初始操作系统映象。这方便了对个别组件、对整个分区或如需要时对整个映象的安全且故障保险的更新。
为将各种包转换成初始制造映象，提供了一种一般针对创建单个制造映象文件的方法和系统，该映象文件进而包含按分区和文件系统布局排列的映象。然后如需要对该文件进行后处理，来准备用于在构建时安装的内容。由此，个别的操作系统组件包被写入这一制造文件。整个文件构造过程以存储(如，闪存)技术抽象的方式完成，使得该系统和方法无需关注底层存储的类型，和/或底层存储在映象的布局上强加的要求。相反，在单独的步骤中，对结果映象文件进行后处理，包括定制映象文件用于所存在的实际类型的存储设备，使得随后可如期望的将初始映象应用到任何设备。
图2提供了设备存储(如，闪存)的一个实例，在该存储中，以由本发明的各个方面方便的方式布局制造映象，如后文所描述的。在图2中，总闪存202的某一些(如，总共64兆字节中的32兆字节)由设备制造商为各种目的而保留，(如，用于涉及设备无线电的代码)。剩余部分(如，32兆字节)是可作为由操作系统和(可任选的)用户存储使用的虚拟存储器204的闪存。如后文所描述的，该文件将考虑保留的分段。
依照本发明的一个方面，如后文所描述的，在文件206中创建各种分区，文件206是要写入虚拟闪存204的文件。每一分区具有某一目的，并且(或可被认为是)包含其自己的文件系统。例如，在图2的示例中，有用于更新加载器的分区209、内核(NK)分区210、系统分区211和用户存储分区212(如，为用户数据存储格式化的)。在文件中创建主引导记录(MBR)213来指定分区，如后文所描述的。此外，如图2所示，为完整性目的，可如通过预先向其挂起数据在文件206中包括另外的数据，如预先存在的引导加载器214(用于旧设备，尽管可任选地用于新设备)，以及初始程序加载器(IPL)215。如可容易地理解的，这一另外的数据的某些或全部可被闪存到独立于其它分区的设备中，由此，可将文件206闪存到剩余的虚拟闪存中，然而，在制造文件206中包括这些比特消除了这一额外的制造步骤。注意，图2的分区并非按比例示出的，并且还应当注意，总存储器和/或可用存储器的量仅为示例。
如可以理解的，本发明提供了在单个文件中使用标准文件系统概念且以存储抽象的方式创建制造映象的能力。结果，可以直接的方式并在对核心过程只有极少/没有影响的情况下，令嵌入式或其它解决方案在变为可用时适用于任何新存储技术。例如，通过后处理，闪存文件系统映象可适用于变为硬盘映象。
另外，能够在构建时在个别的文件内创建文件系统意味着不需要在制造时环境中实现复杂的分区、格式化和其它文件系统逻辑。相反，当今用于将映象写入存储的标准方法(如，闪存群程序员、JTAG或字节流复制)仍能够起作用，即使底层映象可能是复杂的分区以及稍后可由操作系统映象在构建时使用的基于文件系统的模式。
为实现本发明的各方面，在一个示例实现中(参考图2在上文一般描述的)，提供了两个主要组件，即盘映象实用程序230和映象后处理器232。盘映象实用程序230负责取出包装的操作系统组件的集合(或包)234，以及用户(如，制造商)希望分区/文件系统如何在存储中布局的描述(文件236)，和应当如何将包234映射到该分区结构的描述(文件238，也称为包-分区映射文件和/或映象清单文件)。根据这一信息，盘映象实用程序230生成包含各种分区209-212的单个输出文件206，使得每一包的内容储存在适当的分区中，并且使可执行代码被修正到适当的基于虚拟地址空间的地址上。
一旦在这一输出文件状态中，后处理器232在这一输出文件上行动，以引入特定的存储技术所需的对分区和文件系统布局的任何修改。例如，可需要作出调整以处理不同的闪存部分管理闪存中的扇区级信息的不同方式，如后文参考后处理过程一般描述的。
在图2的示例中，由此，盘映象实用程序230由两个输入文件236和238驱动，即，存储器配置文件236(如，memory.cfg.xml)和包-分区映射文件238(如，*.sku.xml，其中，*表示有效文件名)。一般而言，分区映射文件238包含将每一特定操作系统组件(如，包)映射到存储器配置文件236中指示的特定分区的信息。
分区209-212可以是(并通常是)不同的类型。例如，在一个实现中，可以有BINARY分区(BINARY分区具有简单地照原样复制到其上的比特)，如压缩的更新加载器分区209；一个或多个RAMIMAGE或ROMIMAGE分区，如NK分区210；一个或多个IMGFS(映象更新文件系统)分区，如系统分区211；和/或USERSTORE分区，如TFAT或其它分区212。尽管对分区和/或分区类型可以有任意的数量，然而一个当前的实现为保持该机制容易配置的目的将总数限制到四，如在图2中所示的更新加载器(BINARY)、NK分区(RAMIMAGE或ROMIMAGE)、系统分区(IMGFS)和用户分区(USERSTORE)。注意，即使采用了这一任意的限制，也可以有重复的类型，如，采用四个分区的限制，三个二进制类型和一个IMGFS也是可接受的，并且还应当注意，其它类型的分区是可行的。
存储器配置文件236表示用于非易失存储和系统RAM的操作系统运行时虚拟地址空间存储器映射。数据表示实用程序的用户希望如何通过指定可在其上储存信息的一个或多个分区，并向储存在分区中的数据分配特征来利用指定的存储资源。
在一个实现中，存储器配置文件228是对照以下XSD确认的XML格式的文件
<p>然后，通过与实施例16相同的过程制备一种锂二次电池，并用与实施例16相同的方法测试。结果，没有发现放电容量的降低。对于评价快速充放电性能，在0.3mA/cm2的恒定电流下进行充电，然后在0.5、2.0、4.0和6.0mA/cm2的变化的放电电流下进行放电。所说的放电容量表示于表5。
实施例21通过与实施例16的过程制备一种试样电极，但是把压制时的压力改变为140MPa。在这样获得试样电极中，所说的石墨颗粒和PVDF的混合物的厚度为80μm，其密度为1.93g/cm3。
然后，通过与实施例16相同的过程制备一种锂二次电池，并用与实施例16相同的方法测试。结果，观察到15.7％的放电容量的降低。对于评价快速充放电性能，在0.3mA/cm2的恒定电流下进行充电，然后在0.5、2.0、4.0和6.0mA/cm2的变化的放电电流下进行放电。所说的放电容量表示于图5。
表5
如表5所示，可以明显看出，使用本发明的第二种用于锂二次电池的负极的锂二次电池的放电容量高，快速充放电性能优异。
在实施例22～29中，研究了使用本发明的第三种用于锂二次电池的
一个示例存储器配置描述如下
如可从本示例见到的，存储器配置文件的硬件段提供了RAM位置和所保留的每一闪存部分的完整描述，并也用于要由盘映象实用程序作为存储来管理的每一闪存部分。NOR和NAND标签一般用于分别指线性(类似RAM)或基于块的存储。向每一存储部分提供唯一的标识符/名字。分区段表示应当如何在基于分区的抽象中使用指定的存储部分。
例如，ROMIMAGE意味着分区的内容应当被修正/重定位(如后文所描述的)，以从存储部分实际执行，(原地执行，或XIP)，这是线性类型存储设备的特征。注意，如果使用ROMIMAGE，则盘映象实用程序确保任何原地执行代码不被压缩，还确保模块的各个代码段在物理空间中是连续的，即，原地执行代码的这些代码段将不跨越保留的区域。RAMIMAGE标签指示内容应当被修正/重定位，以用尽RAM(假定加载器在适当的时刻将代码从存储移至RAM)。除映象存储之外，可表示额外的分区类型；在上述示例中，将用户存储定义为用于数据存储的分区。
分区映射文件(或SKU)238包含唯一地标识的包的列表，并用于将包映射到指定的分区中。分区映射文件是对照以下XSD确认的XML文件
一个示例分区映射(SKU)文件238如以下XML格式的数据
在这一特定的示例中，一个示例包文件(“oem”)被映射到名为“NK”的分区，在以上存储器配置文件236中，它被定义为具有修正/重定位的代码以在闪存本身上原地执行的ROMIMAGE分区，这与RAM相反。如从本示例可见到的，指定的分区在硬盘扇区中记录的单个NOR闪存部分上存在，它在虚拟地址0x8000.0000处，并且长度为0x380.0000字节。如同样可从本示例中见到的，名为“lang”的包被映射到IMGFS分区(由称为“IMGFS”文件系统驱动程序管理的分区)中的被称为“OS”的第二分区，并也驻留在硬件扇区中指定的单个NOR部分上(但是不与前一NK分区重叠)。
基于两个输入文件236和238中提供的配置信息，盘映象实用程序230处理记录的包的内容。位于给定包中的每一可执行码通过修正或重定位过程被适当地定位到一唯一的虚拟地址空间范围。根据分区内容是意味着在RAM外执行还是在闪存中原地执行，盘映象实用程序230使用该地址空间信息以及关于在总体的虚拟地址空间上可将可执行文件的子段置于何处的已知的限制(如，基于CPU体系结构等)，来处理每一可执行文件并将其内容定位到非重叠的虚拟地址空间范围。
如在图3中一般表示的，修正过程由称为Romimage的组件(如，链接到盘映象实用程序230或在其之内，或与其相关联)302处理。在示例实现中，Romimage302是DLL(动态链接库)，它也在包安装过程中在设备上使用以在安装时将代码修正/重定位到设备上。在被构建时，使用运行时在设备上使用的相同的文件系统代码，将结果文件206储存在构建文件的台式机上所储存的文件内的适当的分区中。注意，该代码对设备以及主机构建系统都是可构建的，以将不兼容问题最小化。
在构建文件之前，盘映象实用程序230请求某一大小的文件的创建，如大小为64兆字节。在FSDMGR 304创建了文件之后，盘映象实用程序230处理存储器配置文件236，以令FSDMGR 304划分出保留的分段，使得它们保持完整。剩余的存储器，如32MB现在通过FSDMGR 304可用。在这一时刻，该文件也准备好用需要的分区来构建。
如可从以上示例存储器配置文件中所见到的，期望一BINARY分区。更具体地，图3示出了盘映象实用工具230如何与romimage.dll功能以及文件系统设备驱动程序管理器304(FSDMGR.dll)一起工作来构建文件206的示例。为在文件中创建分区，盘映象实用程序230结合FSDMGR 304一起工作，以创建一主引导记录(因为还没有该记录)。将数据添加到主引导记录以指示之后为BINARY分区，即，数据创建该分区。在这一实现中，不指定大小，由此，对于现在，剩余的闪存的整个大小用于该BINARY分区。
在本示例中，盘映象实用程序230将通过Romimage 302请求FSDMGR 304将更新加载器写入BINARY分区中，由图3中通过用带圈的一(1)标签的箭头所一般表示的。如上述名为“以故障保险方式向非易失存储应用自定义软件映象更新”的相关专利申请中所描述的，更新加载器本质上是操作系统代码的一个特殊分段，当设备被更新时，设备启动到该分段(而非正常的操作系统代码)。由于从盘映象实用程序的观点来看，更新加载器是比特的二进制大数据块(binary blob)，因此安装该分区，并且FSDMGR 304使用rawFS dll 308将这些二进制比特写入BINARY分区209中(写入主引导记录213之后的空间中)。
一旦被写入，通过调用FSDMGR 304获取实际写入的数据量。在自动确定大小的操作中，下一分区的起点的新偏移基于该实际大小，由此，更新加载器分区209本质上仅消耗文件中它所需要的空间量。
盘映象实用程序230再次以类似的方式调用以在文件中创建NK分区(即，通过将数据写入主引导记录213中)，然后通过以将数据写入NK分区的请求调用romimage.dll写NK分区。注意，romimage.dll用于构建NK分区所需的从盘映象实用程序230发送的参数包括要构建的文件列表以及用于分配闪存空间和虚拟地址空间的分配器，如后文所描述的。romimage.dll 302将该数据修正到一组比特中，然后将它们提供给FSDMGR 304，FSDMGR 304然后通过rawFS dll 308写NK分区，如在图3中由用带圈的数字二(2)标签的箭头所表示的。注意，该物理修正以及虚拟修正可为任何原地执行代码所需。
再次，不指定大小，因此整个剩余空间用于该NK分区，直到被调整大小。然而，在本示例中，并非基于对NK分区所写的确切大小将偏移从文件的末端移回，而是可将NK比特之后的某些额外空间量(缓冲区)留在NK分区中，如由图3中的阴影区所表示的。这一空闲空间缓冲区在存储器XML文件中指定，并本质上将偏移稍微移至实际所写入的字节量之前，并由此令对NK分区的未来更新能够消耗比当前NK分区所消耗的更多的空间，即，允许随后的更新的增长。
如在图3中由用带圈的数字三(3)标签的箭头所表示的，通过romimage.dll，下一步创建并写IMGFS分区(再次延伸到文件的末尾)。注意，在这一时刻，这是IMGFS分区，而非二进制分区，如由FSDMGR 304所识别的。由此，使用imgfs.dll308来写入系统分区，因为这是在运行时在设备上处理该特定分区的驱动程序。此外，注意，通过imgfs.dll 308抽象任何物理修正，由此，对于系统分区，romimage过程302仅如指定的执行虚拟地址修正。然后如上所述地执行自动调整大小，以将下一分区的偏移移至写入的数据量(加上任一期望等空闲空间缓冲区，尽管在当前的示例中没有空闲空间缓冲区)。
下一分区是USERSTORE，它可以是任何类型的分区，在本示例中为类型4的分区。USERSTORE分区通过写入主引导记录中来创建，并被扩展到文件的末端。然而，注意，在这一时刻不写入任何数据，由此，该分区未被安装。当用户稍后希望访问该分区时，FSDMGR将通过适当的驱动程序来完成这一过程，如，如果分区对应于该特定的文件系统格式，则通过TFAT.dll 310来完成。由此，不需要TFAT.dll 310来构建初始文件，但是在图3中作为可用于在运行时访问用户分区数据的驱动程序的示例示出。
转向本发明的操作的解释，作为概述，盘映象实用程序230是采用平台存储器配置文件236(如memory.cfg.xml)和映象清单文件238(如，platform.sku.xml)作为输入，并输出表示设备的完整ROM映象的数据文件206的台式机实用程序。由于盘映象实用程序230负责重定位模块数据，一个设计目标是能够与设备侧更新应用程序共享代码。
除其它操作之外，盘映象实用程序230分析定义设备的存储器布局的存储器配置文件236、任何保留的区域、以及包含预构建BIN/NB0文件(其中，NB0文件是所有.bin文件如它们在ROM中所出现的布局)的一个或多个闪存分区的位置和大小。盘映象实用程序230也分析声明基于包的分区及其内容的映象清单文件238。
在图3中一般表示的实现中，盘映象实用程序230能够构造各种类型的分区，包括BINARY、RAMIMAGE、ROMIMAGE、IMGFS和USERSTORE分区。BINARY分区包括包含任意数据，但不包含包的预构建NB0文件。如由名字所暗示的，RAMIMAGE分区被修正到RAM，而ROMIMAGE分区被修正以从储存它们的NOR部分原地执行。IMGFS分区包括由盘映象实用程序230支持的分区类型，并可简单地通过作出对IMGFS.dll 308的合适版本的调用(通过FSDMGR 304)来构造。USERSTORE分区可以是任何自定义分区类型，并且当前用作主引导记录213中用于在启动时创建的分区的占位符。
下表概述了盘映象实用程序230的输入文件和输出文件
盘映象实用程序230负责在基于包的分区的任一个中重定位模块。为实现这一功能，盘映象实用程序230采用一虚拟地址(VA)分配器。盘映象实用程序230也能够为在设备的每一闪存部分中包含分区的每一闪存部分输出BIN/NB0文件(后文描述)，以及主引导记录(MBR)。输出文件可通过使用MSPart台式机组件来创建。此外，盘映象实用程序230中的大多数代码(如，VA分配器、IMGFS交互、模块重定位)也可用于设备侧更新应用程序，由此，盘映象实用程序230考虑到设备限制和代码可移植性。
图4表示盘映象实用程序230的整体流程。注意，盘映象实用程序230可包括台式机组件，也可包括用于执行各种操作的单独组件。例如，盘映象实用程序可通过命令行来运行，由此，为如块400所示地处理命令行自变量，盘映象实用程序230可包括一命令行处理器。单独的CFG文件分析器可处理存储器配置文件(块402)，单独的sku/包分析器可如块404所示地处理分区映象(SKU)文件。组件及其功能在图4中由BINARY分区构建器/过程(块406)、RAMIMAGE/ROMIMAGE分区构建器/过程(块408)、IMGFS分区构建器/过程(块412)和后处理器(块414)表示。盘映象实用程序230使用的后处理器和数据结构在后文单独的小节中描述。
如如上所述，盘映象实用程序230(如，dskimage.exe)可通过命令行自变量来调用，如命令行dskimage CFGfile SKUfile如应当容易地清楚的，CFGfile参数是到存储器配置文件236的路径，如上所述，该输入文件详细描述当前平台的RAM和闪存布局，并定义分区。SKUfile参数是到分区映射/映象清单文件238的路径，如上所述，该文件列出了包的集合并将它们分配到分区。在一个实现中，盘映象实用程序230在分析输入文件时不考虑文件扩展名，但是在被调用时(如，通过脚本)期望具有以下名字的输入CFGFile＝Memory.cfg.xmlSKUFile＝％_TGTPLAT％.sku.xml当前，命令行处理器仅检查CFGfile和SKUfile命令行自变量的存在，并将它们传递到其各自的(如，XSD)确认器。如果用相对路径指定了自变量，则盘映象实用程序230相对于从其调用盘映象实用程序230的目录查找文件。如果用绝对路径指定了自变量，则盘映象实用程序230使用绝对路径查找该文件。在盘映象实用程序230中，path1是Environment.CurrentDirectory，path2是CFGfile或SKUfile。如果自变量不存在，则命令行处理器采取适当的行动(如，在C#中抛出异常、打印使用消息和退出)。
memory.cfg.xml分析器/过程被设计成给予制造商描述硬件和向闪存部分分配分区的很大的灵活性。在一个当前的实现中，存储器配置分析器/过程分析器(图4的块402)在memory.cfg.xml文件上采用两级确认，如图5中一般表示的。首先，通过C# XMLValidatingReader类，核实memory.cfg.xml文件正确句法；如由步骤500所示的，XML ValidatingReader确保momory.cfg.xml包含有效的XML和需要的标签，否则步骤502分支到输出错误条件。第二级确认由盘映象实用程序230执行。在第二级确认中，创建RAM、闪存部分和分区的内部表示。使用XML串行化来创建内部表示，然后在该内部结构上执行确认(如在图5中由步骤504和506所示的)，以检测无效的配置，如将分区映射到不存在的闪存部分。
在一个实现中，(如，基于WindowsCE的实现)，为使硬件配置有效，文件中的RAM START属性需要引用有效的高速缓存内核虚拟地址(0x80000000-0x9FFFFFFF)；START+LENGTH也需要有效。任意RAM RESERVE分段需要在由父RAM元素的START和LENGTH属性所指定的内核虚拟地址范围内开始和结束。RAM_RESERVE元素无法重叠(START到START+LENGTH应当对每一RAM_RESERVE是唯一的)，并需要具有唯一的、非空的ID串。
在本示例实现中，可实施各种规则，包括NOR/NAND(被总称为FLASH)需要具有唯一的“ID”属性，并不能被命名为“RAM”。FLASH RESERVE元素需要唯一的“ID”，并不能具有长于8个字符的名字。FLASH元素LENGTH属性需要被BLOCKSIZE均匀可分，BLOCKSIZE进而需要被SECTORSIZE均匀可分。对于NOR元素，VASTART需要是块对齐的。FLASH RESERVE元素LENGTH属性需要被父FLASH BLOCKSIZE均匀可分。对于NOR_RESERVE元素，VASTART是块对齐的，NOR VASTART和VASTART+LENGTH应当不与RAM或任意其它NOR元素重叠，并且应当是有效的高速缓存内核虚拟地址。
此外，为有效，NOR_RESERVE元素需要在由父NOR元素的VASTART和LENGTH属性指定的高速缓存内核虚拟地址范围内开始和结束。可使用Allocator(分配器)类分层结构来核实HARDWARE条件，如后文所描述的。为有效的高速缓存内核地址范围创建一全局分配器，将其用于检测RAM和NOR标签的有效地址，以及RAM和NOR部分之间的任何冲突。类似地，对每一RAM和FLASH部分创建分配器，以检测有效的RESERVE区域。分配器可储存在关联的RAM/FLASH对象中，用于容易的检索。
分区数据也储存在MemoryCFG分层结构中。PARTITONS确认的规则包括分区具有唯一ID属性、PARTITION的STORAGE_ID属性需要匹配FLASH部分的ID属性、以及ROMIMAGE分区的STORAGE_ID属性不能引用NAND闪存。对于RAMIMAGE/BINARY，COMPRESS属性是布尔类型，并由此只能是以下之一{0，1，true，false}。
也确认RAMIMAGE/ROMIMAGE/IMGFS(总称为PACKAGE分区)，并且在当前的实现中，只能有一个RAMIMAGE/ROMIMAGE分区。如果指定了两个，则确认失败。FSRAMPERCENT和ROMFLAGS属性对应于RAMIMAGE/ROMIMAG分区的目录中的字段(如，在基于WindowsCE的实现中)。RAMIMAGE分区的FIXUP_ADDRESS涉及该分区应当在RAM中何处开始。该属性需要指向RAM中的有效位置，其后紧跟至少空闲的0x1000字节。当前，每一FLASH部分上不能有一个以上USERSTORE分区。
如上所述，映象清单(包-分区映射或SKU)文件238包含由分区组织的包的列表。XML模式(上文示出)相对直接。映象清单文件分析器/过程负责核实SKU文件包含有效XML，并负责将PACKAGE_LIST中指定的分区与memory.cfg.xml中的PACKAGE分区ID进行匹配。PACKAGE_LIST标签的PARTITION_ID属性需要与PACKAGE分区元素的ID属性相匹配；如果无法找到匹配，则SKU分析器将抛出异常。图6的步骤600、602和604概述了这些各种操作。
每一PACKAGE_LIST标签具有需要的PARTITION_ID属性。将包与分区进行匹配包括取出PARTITION_ID并使用它作为对C#散列表的查找。如果找到匹配，则将子PACKAGE_FILE标签转化成数组列表，并与PACKAGE分区的现有包列表合并。提取包可以以下方式完成
注意，盘映象实用程序230检查FLATRELEASEDIR环境变量的存在，并且如果找到，则使用它作为当前的工作目录。这与传统的构建系统的行为相一致，它允许用户从任一目录执行“makeimg(制造映象)”，而仅在FLATRELEASEDIR中处理文件。
分区由MSPart的台式机(构建系统)版本创建并管理，(如在传统的WindowsCE构建系统中)。MSPart接口允许盘映象实用程序230从分区的实际构造中抽象关于底层硬件的细节。对由MSPart创建的NB0文件的任何硬件专用调整在后处理过程中完成。MSPart可由盘映象实用程序230工具的剩余部分使用，如果是这样，则在创建任何分区之前，对每一FLASH部分创建一MSPart卷，并且划分出任何RESERVE分段，如后文所描述的。盘映象实用程序230维护一单独的类fsdmgr.cs，它包装所需要的未管理的功能。该过程维护闪存部分的一全局散列表，使得其每一个可由名字访问并通过其重复。上述过程通过在每一FLASH部分的FLASHREXERVE元素上重复并调用fsdmgr.dll来完成，如图7中一般表示的。RESERVE区域在实际被创建时用数据来填充。为此，FSDMgr类将来自盘映象的数据汇集到fsdmgr_nt.dll以填充RESERVE区域。
构建NB0的第一个步骤是向MSPart安装的卷添加BINARY分区。首先处理BINARY分区，因为它们是完全自包含的(即，它们不需要修正，也不需要NOR上的SectorData元数据)。如上文一般描述的，构建BINARY分区相对较直接；该过程重复通过BinaryPartitions(二进制分区)数组，并调用其Create()方法。由于每一分区对象指向其父闪存部分，检索正确的卷句柄也是非常直接的。
在一个实现中，PartitionInfo(分区信息)类(MemoryCFG分层结构的一部分)包含名为CreateAllPartitions(创建所有分区)的函数，它通过在BinaryPartition对象上重复，并调用其Create()方法来开始。BinaryPartition.Create()函数在指定的闪存块上创建并安装新的分区、打开memory.cfg.xml的DATAFILE属性中指定的文件、并调用FSDMgr以将数据写入该分区。这一特征的伪代码描述如下(使用某些MSPartAPI)
如上所述，盘映象实用程序提供了用于分别创建ROMIMAGE和RAMIMAGE类型的分区-从ROM和RAM原地执行的分区的“romimage”。这些分区通常包含构成IMGFS文件系统所需的系统组件的最小组nk、coredll、filesys、fsdmgr、mspart、imgfs和任何需要的块驱动程序。
ROMIMAGE/RAMIMAGE过程一般可被分裂成各种步骤(其中八个在当前实现中列出，如也由图8的步骤801-808所示的)构建并排序模块和文件的列表(步骤801)；
向所有模块分配虚拟地址空间(步骤802)；执行模块修正(步骤803)；压缩所有数据段和文件(步骤804)；执行物理布局(步骤805)；分配复制分段(步骤806)；执行内核模块修正(步骤807)；以及输出实际分区(步骤808)。
上述每一步骤可通过对romimage.dll作出调用来执行，允许容易地访问各种(如，C和C#)应用程序的分配和重定位功能。盘映象实用程序可通过称为ROMImage.cs的包装类与romimage.dll接口。
romimage.dll包含用于创建并管理多个分配器的Allocator类分层结构和功能、用于创建并管理文件列表的File(文件)类和功能、以及用于执行ROMIMAGE/RAMIMAGE分区构建过程的步骤的函数。
Allocator类分层结构用于管理RAM和FLASH中的可用物理空间。它展现作出任意分配和固定保留的功能。Allocator类(和子AllocNode)定义如下
romimage.dll导出用于操纵分配器的以下功能
Allocate函数的有效标志包括BOTTOMUP_ALLOC和TOPDOWN_ALLOC。如名字所暗示的，这些都是分别查找从当前分配窗的底部和顶部开始的空闲空间的首次满足(first-fit)算法。它们需要线性搜索(并由此可在请求大量的分配时产生性能瓶颈)。
File类分层结构用于储存关于文件或模块的所有元数据，并定义如下
在构建文件的台式机中，每一文件的内容由File和Section类的数据成员作出存储器映射和指向它。定义以下数据结构用于操作File类分层结构
提供以下函数用于构建RAMIMAGE/ROMIMAGE分区HRESULT BuildNKPartition(HANDLE hFileList，HANDLE hVolume，HANDLE hSlot0Alloc，
HANDLE hSlot1 Alloc，HANDLE hPhysAlloc，DWORD dwReserved)；其中hFileList是到FileList对象的句柄-FileList对象的创建在下一节中讨论；hVolume是到MSPart卷的句柄，由DskImage在分区创建过程中创建；hSlot0Alloc是到起点为0x600000，长度为0x1A00000的分配器的句柄；hSlot1Alloc是到起点为0x2100000，长度为0x1F00000的分配器的句柄；hPhysAlloc是物理分配器(对ROMIMAGE分区为闪存部分，对RAMIMAGE分区为RAM)；hRAMAlloc是RAM分配器，它对应于memory.cfg.xml中的RAM元素；以及dwReserved是到MiscNKInfo结构的指针，定义如下typedef struct_MiscNKInfo{USHORT cbSize；USHORT usCPUType；DWORD dwROMFlags；DWORD dwFSRAMPercent；BOOL fCompressPartition；}MiscNKInfo；为构建并排序模块和文件的列表，(图8的步骤801)，romimage.dll管理文件和模块的多个链接的列表。为构建列表，romiimage.dll提供以下函数HRESULT CreateFileList(PHANDLE phFileList)；HRESULT DestroyFileList(HANDLE hFileList)；HRESULT AddFileToList(Handle hFileList，wchar_t*szFileName，DWORD dwFlags，wchar_t *szPathToFile，BOOL fLoadData，
PHANDLE phFile)；也可以有将File对象从一个文件对象移动到另一个的API。这一函数可为以下形式HRESULT SpliceFile(HANDLE hSrcList，HANDLE hDstList，HANDLE hFile)；为向模块分配虚拟地址空间，(图8的步骤802)，插槽0/1虚拟地址分配需要文件列表、用于插槽0的分配器和用于插槽1的分配器。文件列表已以正确的顺序排序-内部DoVAAlloc方法然后需要依照以下逻辑执行分配
对除内核模块之外的每样东西执行模块修正，如图8的步骤803所示的。为此，提供了FileList类中的以下函数HRESULT DoVAFixups(BOOL fReverse)；fReverse自变量指定了模块应当是被修正还是返回重新基于其原始值。这一功能为设备侧更新应用程序所需，但是在构建该文件的台式机上，fReverse总为FALSE(调用者仅需指定文件列表)。注意，较早的romimage.exe重复通过.rel文件，并立即修正整个模块，然而，采用组件化的更新，需要仅修正分段的指定页的能力。Module(模块)类中的FixupBlob函数支持取出到模块数据的任意指针，并通过重复通过creloc分段和仅找出应用到该数据的修正来修正它。盘映象实用程序230在每一模块分段上仅调用一次该函数。设备侧更新应用程序将在它所重建的每一二进制差页之后调用它。注意，在这一点上，模块的重定位信息储存在模块内(在.creloc分段中)。结果，对于设备侧更新，不再需要重复通过重定位文件，因为需要的信息在模块中自包含。
在图8的步骤808执行物理布局之前，如图8的步骤804所示的压缩模块数据段。注意，盘映象实用程序230不支持模块的代码段的压缩，因为ROMIMAGE和RAMIMAGE分区打算原地执行。然而，如有需要，可容易地添加代码压缩。
提供了FileList(文件列表)类中的以下函数用于压缩目的HRESULT DoCompression()；DoCompression在指定的文件列表上重复，并压缩除内核模块之外的所有东西的数据段。更新储存在Section(分段)类中的o32rom头部的psize成员以反映压缩的数据长度。可使用任一合适的压缩算法，如一个当前的romimage.exe实现使用被优化用于解压的算法。然而，由于romimage.dll由设备侧更新应用程序使用，可使用其它算法作为替代。
一旦压缩了数据段，过程具有执行物理布局所需的信息。为此，提供了FileList类中的以下函数HRESULT DoPhysicalLayout(Allocator &Alloc)；图8的步骤805表示输出分区。对于ROMIMAGE分区，使用关联的FLASH部分的分配器。该分区的起始位置通过查询MSPart来确定。对于RAMIMAGE分区，使用物理布局的RAM分配器。该分区的起始位置由分区的RAMIMAGE元素的FIXUP_ADDRESS属性来确定。
DoPhysicalLayout使用首次满足算法并以以下顺序重复通过文件列表的内容1.代码段(页对齐的)2.数据段(包括.creloc和所有文件)3.TOC(目录，包括所有TOC条目)4.所有e32头部5.所有o32头部块6.复制段块7.文件名在这一阶段，生成目录(TOC)的大部分内容。这对储存模块头部的物理位置的地方是必需的。通过在布局模块头部时生成TOC，避免了创建另一数据结构来保留该元数据的需要。
为向kdata分配复制段(图8的步骤807)和空间，使用RAM分配器。注意，对于ROMIIMAGE分区，该步骤可较早执行，但是不顺序执行，以保持ROMIMAGE和RAMIMAGE过程尽可能地相似。类似于插槽0/1分配，在FileList类中提供了一个函数HRESULT DoCopySectionAlloc(Allocator &Alloc)；一旦该步骤完成，过程可填满pToc的RAMStart、RAMFree和RAMEnd属性。
一旦分配了复制段，修正内核和内核模块，如图8的步骤806所示的。类似于插槽0/1修正，在FileList类中提供了以下函数HRESULT DoKemelVAFixups(BOOL fReverse)；DoKemelVAFixups重复通过内核模块的列表，并通过调用每一Module(模块)对象的DoKemelFixups方法来执行必需的修正。
在这一点上，已修正了所有东西，并且已执行了物理分配。盘映象实用程序230已与MSPart通信，并具有到分区搜寻数据的句柄。为输出最终的映象，提供了用于写分区的函数HRESULT DoWriteNKPartition(HVOL hVolume，Allocator &Alloc)；对于RAMIMAGE和ROMIMAGE分区，DoWriteNKPartition创建RAM中分区的表示，然后将该存储器块作为单个文件输出，类似于盘映象实用程序230本身处理BINARY分区的方法。Alloc自变量对ROMIMAGE分区是必需的，它需要在写出时跳过RESERVE区域。
在ROMIMAGE和RAMIMAGE分区之间只有相对较小的差异，包括RAMIMAGE分区的物理布局使用RAM分配器，而ROMIMAGE的物理布局使用父闪存部分的分配器。同样，对于RAMIMAGE分区，DoWriteNKPartition也可能失败，因为在闪存部分上可能没有足够的空间。由于ROMIMAGE分区使用父闪存部分的分配器，对于ROMIMAGE分区，DoWriteNKPartition应当从不失败。可以用C和C#来实现，令管理的dskimage.exe作出对未管理的romimage.dll的调用。
盘映象实用程序230负责重复通过FLATRELEASEDIR\DskImage\Partition中的清单(DSM)文件，并将DSM文件条目(和DSM文件本身)添加到文件列表，以由romimage.dll处理。对于ROMIMAGE分区，盘映象实用程序230调用MSPart以在尝试物理布局之前创建新分区；(对于RAMIMAGE，它可在任何时刻创建分区)。在输出分区之后，盘映象实用程序230如上所述地调整其大小。其它操作由romimage.dll处理。
如上所述，构建的另一包分区类型是IMGFS。鉴于多种原因，这在其它分区之后构建，包括由于Windows CE内核强加的限制，对RAMIMAGE/ROMIMAGE区域的分配需要首先出现，以及IMGFS分区需要NOR上的SectorInfo。样本NOR闪存媒体驱动程序假定组织闪存使得包含SectorInfo的分区在没有SectorInfo的分区之后到来。构建IMGFS分区的步骤类似于ROMIMAGE/RAMIMAGE分区的步骤。以下步骤本质上从ROMIMAGE/RAMIMAGE分区构建器中重复利用构建并排序模块和文件的列表；向所有模块分配虚拟地址空间；执行模块修正；以及输出实际分区。
IMGFS的物理布局由IMGFS和MSPart处理。类似于RAMIMAGE/ROMIMAGE分区，存在用于写IMGFS分区的BuildIMGFSPartitionAPIHRESULT BuildIMGFSPartition(HANDLE hFileList，HANDLE hVolume，HANDLE hSlot0Alloc，HANDLE hSlot1Alloc，DWORD dwReserved)；期望指定的插槽0和插槽1分配器与早先用于构建RAMIMAGE/ROMIMAGE分区的分配器相同。
IMGFS负责压缩。默认地，压缩文件和模块数据段。
注意，IMGFS分区服务不能包含内核模块(在ce.bib中具有K标志的模块)。由此，在执行VA分配之前，BuildIMGFSPartition核实指定的FileList不包含任何内核模块。
接下来，调用以下FileList成员函数1.DoVAAlloc2.DoVAFixups3.DoWriteIMGFSPartition(图9)如图9中一般表示的，在执行模块修正之后，过程重复(步骤900和918)通过指定的文件列表，为每一条目创建IMGFS中的新文件。注意，如果当前列表项目是模块(步骤902)，则它在各个分段上依次处理(步骤904到912)。否则，创建文件(步骤914)，并写数据(步骤916)。
构建的另一分区类型是USERSTORE，它本质上是用户期望的任一类型的文件系统。它理想地被设计成用于FAT或扩展分区(PART_TYPE 0x04和0x05)。由于在一个当前实现中，memorycfg.xsd不允许用户为USERSTORE指定长度，该分区跨越剩余的闪存。为构建USERSTORE，过程调用FSDMGR来创建指定PART_TYPE的分区，并指令FSDMGR使用闪存部分上的剩余空间，即，通过指定它应当被自动确定大小(由此，在一个实现中，有每一闪存部分一个USERSTORE的限制)。
后处理过程依照本发明的一个方面，当完成时，盘映象实用程序已在构建系统(如，台式机)上生成了单个文件206，它包含对应于不同文件系统的一个或多个分区。在那些分区内，将安装包内容，在适当时在虚拟地址空间修正可执行模块。注意，在这一点上，用户仅指示硬件的某些细节，即RAM和存储位置(地址)、其大小和该存储是线性还是基于块的。尚未指定的是闪存是NOR闪存还是NAND闪存，或硬盘驱动器或某些其它类型的存储的细节。存储技术可在映象上施加影响，取决于它如何被管理。
例如，闪存通常被划分成块，并进一步被细分成页或扇区，如图10A和10B中一般表示的。这些子组件的每一个的大小和存储技术标识其每一个的方式(如数字地)，以及管理每一页或扇区的坏/保留/只读状态的方式是存储技术专用的。
后处理过程步骤的目的是将这一管理信息以不违反映象布局的要求的方式引入到映象中，如在盘映象实用程序的输入文件中所指定的。例如，如果分区之一要在NOR闪存外执行，则有指定它能够以CPU页增量被映射到CPU的CPU要求，并且由于存储管理要求，这无法被改变。
盘映象实用程序230工具的后处理过程阶段用于对MSPart生成的NB0文件作出存储硬件专用调整。例如，如图10A中所示的，NAND闪存具有在单独的空间内伴随扇区的扇区信息(每一扇区的元数据m)。然而，NOR硬件需要修改IMGFS分区以在每一扇区的块内包括SectorInfo，如在图10B中由在每一块的剩余扇区中维护的四扇区块的三个扇区的元数据(m)所一般表示的。注意，为进行块对齐，某些空间未使用，如由图10B的阴影区所表示的。具有成对闪存的设备制造商也可希望将NB0分离成用于每一闪存部分的单独的文件。
后处理器232(图2，如postproc.exe)可由盘映象实用程序230在memory.cfg.xml的任一NOR闪存元素上自动执行。给定NOR元素的ID、VASTART、BLOCKSIZE和SECTORSIZE属性，后处理器输出ID.nb0.postproc和ID.bin。为进一步后处理盘映象实用程序230的输出，用户(如，OEM)可创建一postdiskimage.bat文件，它由buildpkg脚本在盘映象实用程序230过程完成之后调用。
在操作中，后处理器232打开NB0，并找出主引导记录，并使用其中的数据来查找IMGFS分区。后处理器232然后以(例如，NOR)块驱动程序能够理解的格式向每一扇区添加扇区数据。后处理器232也移动USERSTORE(如果存在的话)的起始，并保存修改的NB0，因为在向IMGFS添加了扇区数据之后，它不再对应于闪存块的起始。后处理器232还可将修改的NB0转换成用于传统引导加载器的二进制文件。
如可从以上详细描述所见到的，提供了一种将操作系统映象组件转换成基于文件系统的制造映象的机制。该映象文件独立于任一特定的存储技术，并适合用作初始映象，同时方便了设备的组件化更新，尽管本发明易受各种修改和替换构造的影响，仍在附图中示出了某些说明的实施例并在上文详细描述了它们。然而应当理解，这并非将本发明限于所揭示的具体形式，而是相反，本发明覆盖落入本发明的精神和范围之内的所有修改、替换构造和等效技术方案。
权利要求
1.在计算环境中，一种方法，其特征在于，它包括访问包含要安装到第一存储媒质上的映象数据的包；访问将向其写入所述包内容的分区的描述；以及生成一向第二存储媒质的输出文件，所述输出文件包含分区，使所述每一包的内容基于所述描述储存在所述分区之一中。
2.如权利要求1所述的方法，其特征在于，它还包括访问一存储器配置文件以确定所述输出文件内所述分区的至少一个的位置。
3.如权利要求1所述的方法，其特征在于，所述至少一个包的内容对应于一操作系统组件，其中，所述分区之一包括一系统分区，且所述方法还包括基于所述描述将所述操作系统组件写入所述系统分区中。
4.如权利要求1所述的方法，其特征在于，所述至少一个包的内容对应于一内核组件，其中，所述分区之一包括一基于RAM的映象分区，且所述方法还包括基于所述描述将所述内核组件写入所述基于RAM的映象分区中。
5.如权利要求1所述的方法，其特征在于，所述至少一个包的内容对应于一内核组件，其中，所述分区之一包括一基于ROM的映象分区，并且所述方法还包括基于所述描述将所述内核组件写入所述基于ROM的映象分区中。
6.如权利要求1所述的方法，其特征在于，所述至少一个包的内容对应于一更新加载器组件，其中，所述分区之一包括一二进制映象分区，且所述方法还包括基于所述描述将所述更新加载器组件写入所述二进制映象分区中。
7.如权利要求1所述的方法，其特征在于，生成所述输出文件包括向扩展到所述文件的末端的分区写入数据、以及基于所写入的实际数据量调整所述分区的大小。
8.如权利要求1所述的方法，其特征在于，生成所述输出文件包括向扩展到所述文件的末端的分区写入数据、在所写入的数据的末端之后添加一空闲空间缓冲区、以及基于所写入的实际数据量和所述空闲空间缓冲区调整所述分区的大小。
9.如权利要求1所述的方法，其特征在于，它还包括向所述文件中的一主引导记录写入数据以定义分区。
10.如权利要求1所述的方法，其特征在于，向主引导记录写入数据包括定义一用户存储分区。
11.如权利要求1所述的方法，其特征在于，它还包括向所述输出文件写入额外的数据。
12.如权利要求1所述的方法，其特征在于，它还包括执行一后处理过程以准备将数据从所述输出文件传输到所述第一存储媒质中。
13.如权利要求12所述的方法，其特征在于，所述第一存储媒质包括闪存，其中的代码可原地执行，且所述方法还包括访问一存储器配置文件以修正所述分区的至少一个，使得其中的代码将在原地执行。
14.如权利要求1所述的方法，其特征在于，它还包括访问一存储器配置文件以确定所述第一存储媒质的哪些区段被保留。
15.一个或多个具有计算机可执行指令的计算机可读媒质，当所述指令被执行时，执行权利要求1所述的方法。
16.在计算环境中，一种方法，其特征在于，它包括访问一包含分区的文件，所述分区包含要安装到一存储媒质的映象数据；以及处理所述文件以在所述分区和文件系统布局中引入一特定存储技术所要求的任何修改。
17.如权利要求16所述的方法，其特征在于，它还包括将数据从所述文件传输到对应于所述特定存储技术的存储媒质中。
18.如权利要求16所述的方法，其特征在于，它还包括访问一存储器配置文件以确定所述输出文件内所述分区的至少一个的位置。
19.如权利要求16所述的方法，其特征在于，所述映象数据对应于包，并且所述方法还包括根据一分区—包映射文件和一存储器配置文件生成所述文件。
20.一个或多个具有计算机可执行指令的计算机可读媒质，当所述指令被执行时，执行权利要求17所述的方法。
21.在计算环境中，一种系统，其特征在于，它包括一个盘映象实用程序过程，它输入一包含分区信息和包信息的分区—包映射文件，并基于所述文件中的数据，使用所述包信息中标识的包输出一映象文件，所述映象文件包括所述分区信息中标识的多个分区，使所述每一包的内容基于所述描述储存在所述分区之一中；以及一后处理过程，它处理所述映象文件以在所述映象中引入一特定存储技术所要求的任何修改。
22.如权利要求21所述的系统，其特征在于，所述盘映象实用程序过程还输入一包含指示如何配置设备的存储器的数据的存储器配置文件。
23.如权利要求22所述的系统，其特征在于，所述设备用其代码可在原地执行的存储器来配置，并且其中，访问所述存储器配置文件以修正所述分区的至少一个，使得其中的代码将在原地执行。
24.如权利要求22所述的系统，其特征在于，访问所述存储器配置文件以确定设备存储器的哪些区段被保留。
25.如权利要求21所述的系统，其特征在于，所述至少一个包的内容对应于一操作系统组件，其中，所述分区之一包括一系统分区，并且其中，所述盘映象实用程序基于所述描述将所述操作系统组件写入所述系统分区中。
26.如权利要求21所述的系统，其特征在于，所述至少一个包的内容对应于一内核组件，其中，所述分区之一包括一基于RAM的映象分区，并且其中，所述盘映象实用程序基于所述描述将所述内核组件写入所述基于RAM的映象分区中。
27.如权利要求21所述的系统，其特征在于，所述至少一个包的内容对应于一内核组件，其中，所述分区之一包括一基于ROM的映象分区，并且其中，所述盘映象实用程序基于所述描述将所述内核组件写入所述基于ROM的映象分区中。
28.如权利要求21所述的系统，其特征在于，所述至少一个包的内容对应于一更新加载器组件，其中，所述分区之一包括一二进制映象分区，并且其中，所述盘映象实用程序基于所述描述将所述更新加载器写入所述二进制映象分区中。
29.如权利要求21所述的系统，其特征在于，所述盘映象实用程序向扩展到所述文件的末端的分区写入数据，并基于所写入的实际数据量调整所述分区的大小。
30.如权利要求21所述的系统，其特征在于，所述盘映象使用程序向扩展到所述文件的末端的分区写入数据、在所写入的数据的末端之后添加一空闲空间缓冲区、并基于所写入的实际数据量和所述空闲空间缓冲区调整所述分区的大小。
31.如权利要求21所述的系统，其特征在于，所述盘映象实用程序向所述文件中的一主引导记录写入数据，以定义分区。
32.如权利要求31所述的系统，其特征在于，所述盘映象实用程序通过向所述主引导记录写入数据定义一用户存储分区。
33.在其上储存了一数据结构的至少一个计算机可读媒质，其特征在于，它包括包括定义所述数据结构中的分区的一主引导记录的第一组数据，每一分区对应于一文件系统；包括一二进制分区的第二组数据；包括一基于存储的分区的第三组数据；包括一系统分区的第四组数据；以及其中，处理所述数据结构以在一存储媒质上创建一操作系统映象。
34.如权利要求33所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，所述二进制分区包含更新加载器代码。
35.如权利要求34所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，所述更新加载器代码在所述二进制分区中被压缩。
36.如权利要求33所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，所述基于存储的分区包括一包含内核代码的RAM映象分区。
37.如权利要求36所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，所述内核代码在所述RAM映象分区中被压缩。
38.如权利要求33所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，所述基于存储的分区包括一包含内核代码的ROM映象分区。
39.如权利要求33所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，所述系统分区包含操作系统组件。
40.如权利要求33所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，所述第一组数据中的主引导记录将一用户存储分区定义为所定义的分区之一。
41.如权利要求33所述的在其上储存了所述数据结构的计算机可读媒质，其特征在于，它还包括包含初始程序加载器代码的第五组数据。
全文摘要
所描述的是一种用于制造计算机设备的系统和方法，其中，单个制造映象文件包含可向其写入个别的操作系统组件包的内部分区和文件系统布局。该映象文件独立于任何特定的存储技术。为生成该文件，盘映象实用程序输入一存储器配置文件和一包—分区映射文件，以在该映象文件内创建该分区/文件系统。操作系统组件(包)被写入分区中。为在一特定存储设备上储存(如，闪存)该映象文件的数据，后处理过程该映象文件以定制用于特定存储设备的数据。
文档编号G06F9/445GK1645323SQ20041010201
公开日2005年7月27日 申请日期2004年12月16日 优先权日2003年12月16日
发明者A·罗杰斯, J·格劳姆, M·同科洛维茨 申请人:微软公司