手把手學習WinCE 5.0（二）

經(jīng)過前兩次的邊做邊學，我們已經(jīng)創(chuàng)建并可以自由修改自己的平臺了，這次我平來補充一點理論知識，以便加深對CE生成過程的了解。在此之前，需要說明的是CE的目錄結構是很龐大而復雜的，在以后的工作中很多事情會取決于你對目錄結構的了解程度，在此，CE5的文件夾結構未發(fā)生大的改變，因此想了解此部分內(nèi)容的朋友可直接參閱本人的《WinCE實驗教程》相關部分。與CE4稍有不同的是在CE5中你自己的平臺不在存放于Public文件夾中了，而是專門有一個PBWorkspaces的文件夾，這樣更加方便管理且結構清晰了。

我們重點要說的還是CE的生成過程，即你在編譯平臺的時候Platform Builder到底為你做了些什么?

實際上，IDE在生成CE的過程當中共經(jīng)歷了四個階段，分別是Sysgen、Build、Copy、Make，即組件生成階段，編譯階段，Release文件夾復制階段和鏡像打包階段。下面我們就分階段來說明一下。

在Public文件夾下是CE為我們提供的可用組件，我們定制自己的平臺是通過Platform Builder做的選擇就是從這里面選擇了一部分需要的組件。在這些文件夾中，包含了所有可用的庫文件，頭文件，DEF文件，當然也包括了所有可導出的函數(shù)說明。在Sysgen階段要做的就是從中選擇我們自己的平臺需要的頭文件，庫文件和導出函數(shù)以創(chuàng)建我們自己平臺需要的組件。它所完成的頭文件會以C++注釋的方式加以標記，這樣它就可以選擇需要的部分來導出，最后把所有需要的庫進行鏈接就得到了我們自己平臺所需要的東西了，它就放在Wince500pbworkspaces%ProjectName%WINCE500%CPU_TYPE%_x86cesysgen文件夾下。

經(jīng)過上一階段后，需要的頭文件庫文件就準備好了，但這只是系統(tǒng)組件部分，我們的平臺還有各種設備驅(qū)動程序等其他的東西，這些就要在Build階段來完成了。

整個Build階段都是在圍繞著DIRS文件和SOURCES文件來進行，前者決定了哪些文件夾要被編譯，后者決定了哪些文件要被如何編譯，也就是說，此階段要完成的就是各種源程序的編譯過程。下面我們就重點看一下這兩種文件的內(nèi)容。

DIRS文件可以在很多文件夾中找到，它列出了要參與編譯的子文件夾，內(nèi)容大體如下：

DIRS_CE= ceddk regenum pcibus 這樣，build.exe在編譯的時候就可以通過它來逐層找到要參與編譯文件夾了。至于其中的OPTIONAL_DIRS、DIRS_NTANSI等項目的含義可以通過幫助查到。

同樣，SOURCES文件對參與編譯的源程序的編譯方式做了規(guī)定，例如通過TARGETNAME規(guī)定編譯后的名稱，通過TARGETTYPE規(guī)定編譯的類型是EXE，DLL還是LIB，通過DLLENTRY規(guī)定DLL文件的入口點，通過INCLUDES規(guī)定編譯過程中需要的頭文件，通過SOURCES規(guī)定參與編譯的源文件等等。這些宏的用法在幫助文檔里有更加明細的說明，在這里只要理解這種編譯機制就可以了。

接下來，所有的編譯都有完成了，DLL也好，EXE也好，都是目標平臺自有的了，下一步就是一個Copy過程，也就是將你的項目文件夾下的WINCE500文件夾下的內(nèi)容復制到RELEASE文件夾下，這步就沒什么可說的了。

最后一步就是打包了，即將已經(jīng)準備好的目標平臺的文件打包成NK.bin這樣的操作系統(tǒng)鏡像文件。在這個過程當中，一個完成了文件合并、注冊表壓縮、資源文件替換和打包四個子過程。

文件合并階段重點對以下文件進行合并：

--所有的.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要好得多，你可以自己掌握讓它單獨執(zhí)行某一步驟。如果你修改了某個組件的源程序，也可以右擊這一組件然后單獨編譯此組件，最后再生成Image，總之，靈活性是比較不錯的了。

同時，經(jīng)過以上的分析也可以看出來，Platform Builder這個IDE在幫助生成CE時基本上是依賴于文件夾結構和那些文本文件以及批處理文件的，因此，對于文件夾結構還是要盡量的熟悉。同時也證明那些總說批處理文件沒用的人的無知，在微軟的操作系統(tǒng)和開發(fā)工具中，批處理文件是至關重要的，說它無用的人只是由于自己的水平不夠而已。

好了，這次我們學得多做得少，不過這些知識還是有必要了解的，別忘了對照你的文件夾結構來學習哦!

經(jīng)過以前的學習，我們已經(jīng)掌握了生成CE的過程及編譯的幾個階段，這次我們再來了解一下Platform Builder中為我們提供的組件包的管理方式以及如何管理自己的組件。

在Platform Builder(以下簡稱PB)中的右側有一個"Catalog"窗口，其中列出了所有可供使用的組件，我們可以看到其內(nèi)容是非常之多的，現(xiàn)在的疑問就產(chǎn)生了，PB是如何管理這些組的呢?如果我有一個新設備的驅(qū)動組件要如何才能放到這個組件包窗口中呢?如果我開發(fā)了一個設備驅(qū)動以供其他人使用那我要如何才能發(fā)布我的驅(qū)動呢?下面，我們就來解決這些問題。

在PB中，這些組件的管理都是能過一種組件文件(.cec文件)來實現(xiàn)的。在CE4中，系統(tǒng)自帶的CEC文件都位于PB的安裝文件夾下的CEC文件夾，我們可以在那里很容易的找到它們，但是在CE5中，它的位置變了，你可以在WINCE500PUBLICCOMMONOAKCATALOGCEC下找到他們。

如果你開發(fā)了OAL，設備驅(qū)動或其他組件，你就可以能過CEC文件來把它們加入到PB中。通過在PB環(huán)境中導入CEC文件，其他的平臺開發(fā)人員就可以使用這些組件了。CEC文件是用來描述組件信息的文本文件，它包括了一些塊的列表，主要包括以下四種信息塊：

--CECInfo塊，用來描述此CEC文件的信息，每個CEC文件只能含有一個此信息塊，從中你可以看到該CEC的名稱、GUID、版本、供應商和簡要描述。

--ComponentType塊，它描述了最高級別的組件類型，在一個CEC文件中可以有多個此信息塊，它通過Group,RequiredCEModules,ExcludeWhenSet,MaxResolvedImplsAllowed等條目來描述此組件所在的組，需要的CE組件，排除的組件及允許在一個CE平臺中存在的數(shù)量等信息。