经过前两次的边做边学，我们已经创建并可以自由修改自己的平台了，这次我平来补充一点理论知识，以便加深对CE生成过程的了解。在此之前，需要说明的是CE的目录结构是很庞大而复杂的，在以后的工作中很多事情会取决于你对目录结构的了解程度，在此，CE5的文件夹结构未发生大的改变，因此想了解此部分内容的朋友可直接参阅本人的《WinCE实验教程》相关部分。与CE4稍有不同的是在CE5中你自己的平台不在存放于Public文件夹中了，而是专门有一个PBWorkspaces的文件夹，这样更加方便管理且结构清晰了。
　　 我们重点要说的还是CE的生成过程，即你在编译平台的时候Platform Builder到底为你做了些什么？
　　 实际上，IDE在生成CE的过程当中共经历了四个阶段，分别是Sysgen、Build、Copy、Make，即组件生成阶段，编译阶段，Release文件夹复制阶段和镜像打包阶段。下面我们就分阶段来说明一下。
　　 在Public文件夹下是CE为我们提供的可用组件，我们定制自己的平台是通过Platform Builder做的选择就是从这里面选择了一部分需要的组件。在这些文件夹中，包含了所有可用的库文件，头文件，DEF文件，当然也包括了所有可导出的函数说明。在Sysgen阶段要做的就是从中选择我们自己的平台需要的头文件，库文件和导出函数以创建我们自己平台需要的组件。它所完成的头文件会以C++注释的方式加以标记，这样它就可以选择需要的部分来导出，最后把所有需要的库进行链接就得到了我们自己平台所需要的东西了，它就放在Wince500\pbworkspaces\%ProjectName%\WINCE500\%CPU_TYPE%_x86\cesysgen文件夹下。
　　 经过上一阶段后，需要的头文件库文件就准备好了，但这只是系统组件部分，我们的平台还有各种设备驱动程序等其他的东西，这些就要在Build阶段来完成了。
　　 整个Build阶段都是在围绕着DIRS文件和SOURCES文件来进行，前者决定了哪些文件夹要被编译，后者决定了哪些文件要被如何编译，也就是说，此阶段要完成的就是各种源程序的编译过程。下面我们就重点看一下这两种文件的内容。
　　 DIRS文件可以在很多文件夹中找到，它列出了要参与编译的子文件夹，内容大体如下：
　　DIRS_CE= ceddk regenum pcibus 这样，build.exe在编译的时候就可以通过它来逐层找到要参与编译文件夹了。至于其中的OPTIONAL_DIRS、DIRS_NTANSI等项目的含义可以通过帮助查到。
　　 同样，SOURCES文件对参与编译的源程序的编译方式做了规定，例如通过TARGETNAME规定编译后的名称，通过TARGETTYPE规定编译的类型是EXE，DLL还是LIB，通过DLLENTRY规定DLL文件的入口点，通过INCLUDES规定编译过程中需要的头文件，通过SOURCES规定参与编译的源文件等等。这些宏的用法在帮助文档里有更加明细的说明，在这里只要理解这种编译机制就可以了。
　　 接下来，所有的编译都有完成了，DLL也好，EXE也好，都是目标平台自有的了，下一步就是一个Copy过程，也就是将你的项目文件夹下的WINCE500文件夹下的内容复制到RELEASE文件夹下，这步就没什么可说的了。
　　 最后一步就是打包了，即将已经准备好的目标平台的文件打包成NK.bin这样的操作系统镜像文件。在这个过程当中，一个完成了文件合并、注册表压缩、资源文件替换和打包四个子过程。
　　 文件合并阶段重点对以下文件进行合并：
　　 --所有的.bib文件合并成CE.BIB
　　 --所有的.reg文件合并成REGINIT.INI
　　 --所有的.dat文件合并成INITOBJ.DAT
　　 --所有的.db文件合并成INITDB.INI
　　 知道这几个合并以后便于你在RELEASE下查找你做的修改是否确实被置入了目标平台。
　　 注册表压缩会将REGINIT.INT文件压缩成DEFAULT.FDF文件。
　　 资源替换就是将EXE或DLL中的资源替换成本地语言如简体中文。

　　 接下来才是把这些CE.BIB等二进制文件制作NK.BIN文件，这才是我们需要的文件，不过在CE5中好像可以在项目设置中改变这个文件的名称，读者可以自己试试。

　　 以上说的这些编译过程，在Platform Builder中的Build OS菜单下分得比较明确，这一点比CE4要好得多，你可以自己掌握让它单独执行某一步骤。如果你修改了某个组件的源程序，也可以右击这一组件然后单独编译此组件，最后再生成Image，总之，灵活性是比较不错的了。

　　 同时，经过以上的分析也可以看出来，Platform Builder这个IDE在帮助生成CE时基本上是依赖于文件夹结构和那些文本文件以及批处理文件的，因此，对于文件夹结构还是要尽量的熟悉。同时也证明那些总说批处理文件没用的人的无知，在微软的操作系统和开发工具中，批处理文件是至关重要的，说它无用的人只是由于自己的水平不够而已。
　　 好了，这次我们学得多做得少，不过这些知识还是有必要了解的，别忘了对照你的文件夹结构来学习哦！ 


    经过以前的学习，我们已经掌握了生成CE的过程及编译的几个阶段，这次我们再来了解一下Platform Builder中为我们提供的组件包的管理方式以及如何管理自己的组件。
    在Platform Builder（以下简称PB）中的右侧有一个"Catalog"窗口，其中列出了所有可供使用的组件，我们可以看到其内容是非常之多的，现在的疑问就产生了，PB是如何管理这些组的呢？如果我有一个新设备的驱动组件要如何才能放到这个组件包窗口中呢？如果我开发了一个设备驱动以供其他人使用那我要如何才能发布我的驱动呢？下面，我们就来解决这些问题。
    在PB中，这些组件的管理都是能过一种组件文件(.cec文件)来实现的。在CE4中，系统自带的CEC文件都位于PB的安装文件夹下的CEC文件夹，我们可以在那里很容易的找到它们，但是在CE5中，它的位置变了，你可以在WINCE500\PUBLIC\COMMON\OAK\CATALOG\CEC下找到他们。
    如果你开发了OAL，设备驱动或其他组件，你就可以能过CEC文件来把它们加入到PB中。通过在PB环境中导入CEC文件，其他的平台开发人员就可以使用这些组件了。CEC文件是用来描述组件信息的文本文件，它包括了一些块的列表，主要包括以下四种信息块：
    --CECInfo块，用来描述此CEC文件的信息，每个CEC文件只能含有一个此信息块，从中你可以看到该CEC的名称、GUID、版本、供应商和简要描述。
    --ComponentType块，它描述了最高级别的组件类型，在一个CEC文件中可以有多个此信息块，它通过Group,RequiredCEModules,ExcludeWhenSet,MaxResolvedImplsAllowed等条目来描述此组件所在的组，需要的CE组件，排除的组件及允许在一个CE平台中存在的数量等信息。
    --Implementation块，用来描述此组件在编译时需要的各种信息，每个CEC文件中也可以有多个此信息块，它是 ComponentType块的一部分，其中的BSPPlatformDir,Children,OptionalChildren,DefaultDrivers,ExcludeWhenSet,FeatureVariable,ImplSize等条目的具体含义可以在PB的帮助文档中找到，在此不一一细述。
    --BuildMethod块，描述了编译的方法，也是ComponentType块的一部分，为了加深对上一次编译阶段的理解，我们详细说一下此块中Step和Action两个条目。
    Step用来说明编译此组件将要在哪一步中进行，对照上一次的内容，它的取值为：CESYSGEN,BSP,BUILDREL,MAKEIMG。所以如果你自己开发了OAL或驱动之类的组件，你就需要自己决定让PB在什么阶段来编译它，就要在CEC中通过Step来描述。其实在具体的编译过程中，上述的每一阶段又有PRE和POST两个子阶段，也就是说对于每个阶段其实都有三步，即PRECESYSGEN,CESYSGEN,POSTCESYSGEN,PREBSP,BSP,POSTBSP……一般不用具体到这样详细的程度。
    Action则描述了组件编译的行为，有效的行为与编译阶段的对应关系如下表所示：
ActionCESYSGENBSPBUILDRELMAKEIMG#BUILD(DIR,...)NoYesNoNo#BUILD(SOURCES)NoYesNoNo#BUILD(MAK,...)NoYesNoNo#CUSTOM(...,...)NoYesYesNo#COPY(...,...)YesNoYesNo#ENV(...,...)NoYesNoYes#SRCCODE(...)NoNoNoNo
    这些Action的意义如下：
    --#BUILD（）：使用DIRS文件或SOURCES文件或MAKE文件来调用build.exe，在完全编译平台的时候被使用；
    --#CUSTOM（）：在编译的时候运行批处理文件或可执行文件；
    --#COPY（）：从一个位置复制文件到另一个位置；
    --#ENV（）：设置环境变量；
    --#SRCCODE（）：指定了包含源程序文件的文件夹，只在编译所选组件时应用。
    对于以上每个条目的具体用法可以参阅PB的帮助文档。为了获得感性认识，我们最好用记事本打开几个CEC文件来看一下。比如打开serial.cec看看串口驱动组件的实现方法等。
    以上我们了解了CEC文件，我们再来解决后面的问题，即假设我从别的供应商处拿到了一个设备的驱动程序，它带了CEC文件，那么我要如何把这个组件加入到PB的组件包中呢？这个问题其实很简单，只要在PB的File菜单下使用"Manage Catalog Items"命令即可。在这个弹出的对话框中的内容和使用方法就不用我说了吧。
    再来解决下一个问题，我要如何为我开发的组件编写CEC文件呢？这个也好办，在Tools菜单下使用"CEC Editor"命令即可，如果不会写，可以先打开一个现有的CEC文件看看是如何组织的，然后再仿照它来写自己的就可以了，别忘了写完后要保存哦，同时也要注意GUID的问题。
    此次内容的最后，我们再来看一下BSP。什么是BSP呢，其实就是为某一种开发板实现了设备驱动的软件包，它包含了源程序文件，二进制文件等，还有OAL适配层，Bootloader和其他有关的配置文件。比如CE5的评估版就带了x86的BSP,AMD的BSP和Emulator的BSP。
    通常对BSP的操作都在BSP向导中进行，它位于Platform菜单中，利用它可以新建自己的BSP，复制现存的BSP，修改现存的BSP或创建全局的驱动程序。如果你准备好了BSP所需要的那些东西就可以用它来生成你的BSP了，它会选择必须的CE内核组件。
    好了，已经写了不少了，唉，写这东西真是费时啊，不说了，希望我们能一起获得更多的知识。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。