klg1
OAL（OEM Adaptation Layer）既OEM 適配層，從邏輯上講位于Windows CE內(nèi)核和硬件之間，從物理上講OAL各個模塊代碼被編譯后（.lib）和其它內(nèi)核庫鏈接到一起形成Windows CE的內(nèi)核可執(zhí)行文件nk.exe。Windows CE內(nèi)核在OAL層暴露了大量的函數(shù)和全局變量，利用這些函數(shù)和全局變量OEM可以編寫中斷處理、RTC、電源管理、調(diào)試端口、通用I/O控制代碼等。圖1更直觀地描述了OAL的結構。CE安裝目錄的子目錄中包含了OAL的部分源碼，大多數(shù)情況下開發(fā)者對OAL只要修改即可，甚至無需修改。通過閱讀本篇文章，開發(fā)者能夠了解OAL的結構、暴露的接口的功能，可以在此基礎上實現(xiàn)甚至增強OAL的功能。
因為OAL層代碼大多數(shù)和CE啟動時系統(tǒng)初始化工作有關，所以本篇文章以CE的啟動順序為線索。其它OAL知識在下一篇文章中講解。
一、在Boot Loader解壓CE內(nèi)核鏡像文件（nk.bin）后開始跳轉到StartUp()，StartUp函數(shù)屬于OAL層，此時CE操作系統(tǒng)內(nèi)核還沒有運行。StartUp函數(shù)的功能主要有兩個，一是初始化CPU為已知狀態(tài)（known state），二是調(diào)用內(nèi)核初始化函數(shù)（x86平臺為KernelInitialize，其它平臺為KernelStart）。初始化CPU工作因CPU的不同而不同，如果是ARM系列，包括設置CPU為管理員模式、禁止IRQ和FIQ、禁止MMU、清空指令和數(shù)據(jù)緩沖、檢測啟動原因、配置GPIO和內(nèi)存控制器、初始化RTC、保存OEMAddressTable地址等。執(zhí)行完畢后調(diào)用KernetStart。如果是x86系列，包括設置CPU為保護模式、初始化內(nèi)存控制器、保存OEMAddressTable地址等。執(zhí)行完畢后調(diào)用KernetInitialize。
二、內(nèi)核初始化函數(shù)的功能也因CPU的不同而不同，不過有一些功能是相同的，如初始化串口（為了輸出調(diào)試信息）、調(diào)用OEMInit函數(shù)等。對于x86系列，初始化工作除了上述的功能外還包括讀取OEMAddressTable內(nèi)容、確定分頁大小、內(nèi)核重定位、初始化中斷分配表、初始化分頁表、內(nèi)存初始化和其它初始化。對于其它系列CPU請參考CE幫助文檔。
1. 串口調(diào)試：
串口調(diào)試函數(shù)包括OEMInitDebugSerial、OEMReadDebugByte、OEMWriteDebugByte等。從OEMInitDebugSerial的源碼可以看出，系統(tǒng)從BOOT_ARG_PTR_LOCATION為首地址的結構中判斷當前連接的串口是哪個，然后配置這個串口。如果你的設備的串口I/O地址設置和CE默認的一致的話，就能在CE內(nèi)核得到CPU控制權到啟動完畢這段時間里通過串口得到調(diào)試信息。
2. OEMInit
一般在OEMInit中初始化所有外圍的硬件、初始化系統(tǒng)時鐘（system tick）和RTC（real time clock）、初始化KITL（Kernel Independent Transport Layer）。例如I486平臺的OEMinit函數(shù)，它先關聯(lián)所有的IRQ和中斷ID，然后初始化PCI總線、網(wǎng)絡適配器、電源管理、PIC（可編程中斷控制器）、系統(tǒng)時鐘，最后檢測是否有擴展內(nèi)存。另外如果OEM要通過OAL暴露的函數(shù)指針或者全局變量來增強功能的話，就要在此函數(shù)中實現(xiàn)（在下面詳細講解）。
3. 檢測擴展內(nèi)存
我們都知道在config.bib配置文件中設置CE系統(tǒng)使用RAM總量（如果不知道請參考我的文章Platform Builder之旅系列），注意這個RAM總量不是總的物理內(nèi)存的大小。PB編譯的內(nèi)核包含一個變量ulRAMEnd，將在config.bib中定義的RAM的起始地址 ＋ RAM大小的和賦值給ulRAMEnd。在CE內(nèi)核的啟動過程中，ulRAMEnd的值賦值給全局變量MainMemoryEndAddress，CE內(nèi)核通過訪問MainMemoryEndAddress得到RAM的總量信息。假如基于CE的設備附加了RAM，而MainMemoryEndAddress的值沒有包括這段附加的RAM，結果CE內(nèi)核無法知道已經(jīng)附加了RAM。為了讓CE內(nèi)核了解附加RAM的信息，OEM應該編寫一個函數(shù)檢測RAM的總量，并把總量值賦給MainMemoryEndAddress。OAL暴露了一個函數(shù)指針pNKEnumExtensionDRAM，OEM應該把編寫好的函數(shù)地址賦給這個函數(shù)指針。如果OEM不準備自己編寫內(nèi)存檢測函數(shù)的話也可以調(diào)用OEMGetExtensionDRAM。從幫助文檔中看出OEMGetExtensionDRAM這個函數(shù)能夠檢測內(nèi)存的總量，但是CE的針對X86 平臺的源碼中沒有具體編寫這個函數(shù)的實現(xiàn)代碼（見%_WINCEROOT%\PUBLIC\COMMON\OAK\CSP\I486\OAL\cfwpc.c）。也就是說在X86平臺上調(diào)用OEMGetExtensionDRAM是檢測不到RAM的。如果OEM有興趣編寫檢測RAM總量的函數(shù)，可以調(diào)用現(xiàn)成的函數(shù)IsDRAM。這個函數(shù)也保存在cfwpc.c中。
三、內(nèi)核初始化函數(shù)執(zhí)行完畢后開始按如下步驟執(zhí)行：
1. 內(nèi)核創(chuàng)建用于與filesys.exe同步的事件對象SYSTEM/FSReady，之后啟動filesys.exe。啟動filesys.exe的意義是讓filesys.exe讀取注冊表數(shù)據(jù)。
2. 內(nèi)核等待事件SYSTEM/FSReady被觸發(fā)，這個事件是由filesys.exe在做完一系列工作后觸發(fā)。這一系列的工作內(nèi)容如下：
2.1 先檢測這是一次冷啟動還是熱啟動，如果是冷啟動，那么初始化對象存儲內(nèi)存區(qū)域。
2.2 調(diào)用OEMIoControl函數(shù)，I/O控制代碼為IOCTL_HAL_INIT_RTC，也就是初始化RTC。
2.3 初始化數(shù)據(jù)庫子系統(tǒng)和API、文件系統(tǒng)API、消息隊列API。
2.4 如果操作系統(tǒng)鏡像（nk.bin）包括RAM文件系統(tǒng)，那么讀取Initobj.dat文件內(nèi)容后創(chuàng)建一個RAM文件系統(tǒng)。
2.5 初始化注冊表（在內(nèi)存中形成注冊表）。
2.6 如果此時device.exe沒有啟動，那么讀取HKEY_LOCAL_MACHINE\System\StorageManager下“Dll”的值（這個值為存儲管理器所在的.dll的文件名）并加載到內(nèi)存。加載之后創(chuàng)建一個線程專用于初始化存儲管理器，初始化之后此線程結束。
2.7 初始化NLS（national language support）。關于NLS請參見我的文章《CE下中文輸入法編輯器》。
2.8 為數(shù)據(jù)庫引擎設置本地ID。
2.9 讀取Initdb.ini文件，安裝在對象存儲中的數(shù)據(jù)庫。
2.10 觸發(fā)SYSTEM/FSReady事件，之后filesys.exe處于等待狀態(tài)，等待內(nèi)核發(fā)通知給它。
3. 此時注冊表已經(jīng)存在于內(nèi)存當中，內(nèi)核開始讀取如下位置數(shù)據(jù)：
HKEY_LOCAL_MACHINE\Loader\SystemPath
HKEY_LOCAL_MACHINE\SYSTEM\OOM\cbLow and cpLow
HKEY_LOCAL_MACHINE\SYSTEM\KERNEL\InjectDLL
HKEY_LOCAL_MACHINE\MUI\Enable and SysLang
HKEY_CURRENT_USER\MUI\CurLang
4. 內(nèi)核設置低內(nèi)存處理（out of memory）。低內(nèi)存處理是指當前可用的內(nèi)存非常少時，內(nèi)核所做的解決方案（CE幫助文檔中有詳細說明）。
5. 內(nèi)核在做好了上述工作后通知filesys.exe，由filesys.exe做其余工作。filesys.exe所做的工作內(nèi)容如下：
5.1 讀取HKEY_LOCAL_MACHINE\System\Events 下包含的所有事件對象名稱并一一創(chuàng)建。
5.2 讀取HKEY_LOCAL_MACHINE\Init 下包括的所有應用程序名稱并一一啟動。如果device.exe在列表中并且此時它已經(jīng)啟動了，那么觸發(fā)SYSTEM/BOOTPHASE2事件，這會使device.exe重新讀取注冊表數(shù)據(jù)來完成最后的驅動程序初始化。
5.3 初始化時間區(qū)域（time zone）。
?WinCE應用程序的開發(fā)相對桌面Windows應用程序的開發(fā)有一些特點，如下：
??? 1. UNICODE編碼。WinCE中的應用程序只能使用UNICODE編碼，桌面系統(tǒng)則支持UNICODE和ANSI碼。在移植PC端程序到設備上時需要注意這一點。
??? 2.SDK。SDK即軟件開發(fā)支持包，軟件開發(fā)都少不了這個，但在WinCE應用程序的開發(fā)中尤為重要。因為WinCE系統(tǒng)本身是一個非標的操作系統(tǒng)，它的組件特性和可裁剪性決定了不同的系統(tǒng)支持的API是不同的。而桌面系統(tǒng)相對標準，SDK的作用就弱化了。WinCE中的SDK由系統(tǒng)開發(fā)人員在編譯完系統(tǒng)后，通過Platform Builder導出。應用程序的開發(fā)人員安裝此SDK，并編寫應用程序，最終將應用程序下載到目標平臺上運行測試。一般來說，SDK是應用程序和操作系統(tǒng)之間的紐帶，但他們之間也并不是完全一一對應的。譬如，在硬件和操作系統(tǒng)都沒調(diào)試好時，我們可以先用標準的SDK或者自己定制一個模擬器的SDK進行應用程序的開發(fā)，等硬件和系統(tǒng)調(diào)試完成后再做聯(lián)調(diào)。應用程序基于新的SDK編譯一下，甚至無需重新編譯也可運行。當然，一個應用程序在別的設備上跑得很好，但到另外一個設備上卻不能工作也是很正常的。就像很多WM上的應用程序在WinCE中不能跑一樣，雖然內(nèi)核相同，但系統(tǒng)不同，支持的API也是不同的。
??? 最后說說開發(fā)語言，WinCE應用程序的開發(fā)有Win32、MFC和Managed等幾種方式。對于開發(fā)者來說，選擇使用哪一個主要看效能，開發(fā)的效能和運行的效能。根據(jù)能量守恒定律，開發(fā)效能和運行效能應該是一個此消彼長的關系。呵呵，跟能量守恒定律有關系么？勉強找個有力證據(jù)吧。托管代碼的開發(fā)效率很高，但執(zhí)行效率相對就低了。這在物資還不是極大豐富的嵌入式系統(tǒng)上，就顯得尤為突出，實時性也得不到保證。MFC是基于Window32的一個基礎類庫，封裝了很多Win32的API，方便開發(fā)者使用，但它也是有缺點的，似乎也沒再更新。Win32是這三者中最底層的一個，編譯出的程序小，沒有額外的包袱，運行起來快，所以開發(fā)的難度自然就大了，代碼量也很大。我們在開發(fā)應用程序時應根據(jù)實際情況選擇更合適的。?
世界上存在著多種編碼方式，同一個二進制數(shù)字可以被解釋成不同的符號。因此，要想打開一個文本文件，就必須知道它的編碼方式，否則用錯誤的編碼方式解讀，就會出現(xiàn)亂碼。為什么電子郵件常常出現(xiàn)亂碼?就是因為發(fā)信人和收信人使用的編碼方式不一樣。
可以想象，如果有一種編碼，將世界上所有的符號都納入其中。每一個符號都給予一個獨一無二的編碼，那么亂碼問題就會消失。這就是 Unicode，就像它的名字都表示的，這是一種所有符號的編碼。
歷史上存在兩個試圖獨立設計 Unicode 的組織，即國際標準化組織(ISO)和一個軟件制造商的協(xié)會(unicode.org)。ISO 開發(fā)了 ISO 10646 項目，Unicode 協(xié)會開發(fā)了 Unicode 項目。
在1991年前后，雙方都認識到世界不需要兩個不兼容的字符集。于是它們開始合并雙方的工作成果，并為創(chuàng)立一個單一編碼表而協(xié)同工作。從 Unicode2.0 開始，Unicode 項目采用了與 ISO 10646-1 相同的字庫和字碼。
目前兩個項目仍都存在，并獨立地公布各自的標準。Unicode 協(xié)會現(xiàn)在的最新版本是2005年的 Unicode 4.1.0。ISO 的最新標準是 10646-3:2003。
Unicode 是一個很大的集合，現(xiàn)在的規(guī)模可以容納100多萬個符號。每個符號的編碼都不一樣，比如，U+0639表示阿拉伯字母Ain，U+0041表示英語的大寫字母A，U+4E00表示漢字"一"。具體的符號對應表，可以查詢 unicode.org，或者專門的漢字對應表。
Unicode的問題
需要注意的是，Unicode 只是一個符號集，它只規(guī)定了符號的二進制代碼，卻沒有規(guī)定這個二進制代碼應該如何存儲。
比如，漢字"一"的 unicode 是十六進制數(shù)4E00，轉換成二進制數(shù)足足有15位(100111000000000)，也就是說這個符號的表示至少需要2個字節(jié)。而表示其他更大的符號，可能需要3個字節(jié)或者4個字節(jié)，甚至更多。
這里就有兩個的問題，一個是，如何才能區(qū)別 unicode 和 ascii?計算機怎么知道三個字節(jié)表示一個符號，而不是分別表示三個符號呢?第二個問題是，我們已經(jīng)知道，英文字母只用一個字節(jié)表示就夠了，如果unicode統(tǒng)一規(guī)定，每個符號用三個或四個字節(jié)表示，那么每個英文字母前都必然有二到三個字節(jié)是0，這對于存儲空間來說是極大的浪費，文本文件的大小會因此大出二三倍，這是難以接受的。
它們造成的直接結果是:出現(xiàn)了unicode 的多種存儲方式，也就是說有許多種不同的二進制格式，可以用來表示 unicode 。另外 unicode 在很長一段時間內(nèi)無法推廣，直到互聯(lián)網(wǎng)的出現(xiàn)。
網(wǎng)絡上流行的utf-8就是unicode編碼的一類應用.
如何查詢 Unicode 編碼
在 Windows 系統(tǒng)下，你可以在運行欄輸入 "eudcedit.exe"調(diào)用 TrueType 造字程序，在其中的窗口--參照頁，在"代碼"欄輸入 Unicode 編碼可以查找到相應的字符;在"形狀"欄輸入字符則可以查找到相應的 Unicode 編碼 。
Debug?? 和?? Release??編譯方式的本質(zhì)區(qū)別?? Debug?? 通常稱為調(diào)試版本，它包含調(diào)試信息，并且不作任何優(yōu)化，便于程序員調(diào)試程序。Release?? 稱為發(fā)布版本，它往往是進行了各種優(yōu)化，使得程序在代碼大小和運行速度上都是最優(yōu)的，以便用戶很好地使用。
1 Windows CE驅動介紹
??? 驅動程序是介于操作系統(tǒng)和設備之間的一個代碼層，它的主要作用是為操作系統(tǒng)提供一個接口，以操作不同的硬件，包括物理的和虛擬的設備。雖然驅動程序有很多種，但從編程的角度來看，無非是往一個固定的框架中添加相應的代碼。這里的框架指的是一個接口，面向操作系統(tǒng)。代碼實現(xiàn)的宗旨是，在正確的時間往正確的寄存器中寫正確的值。
??? 驅動程序的分類，從不同的角度有不同的分法。拿串口驅動來說，你可以說它是一個分層驅動，你也可以說它是一個流驅動，你還可以說它是開機時自動加載的驅動……這似乎有點亂。如果你也這么認為，那建議往下看。如果這些你都了如指掌，那就不浪費時間了，當然，您愿意找茬，我會很感謝！
??? 先說本地驅動(Native Drivers)和流驅動(Stream Drivers)。WinCE下的驅動都可以歸類到這兩個里面，二者必居其一。這是從驅動程序提供給操作系統(tǒng)的接口來區(qū)分的。流驅動為操作系統(tǒng)提供了流接口函數(shù)，如XXX_Init()、XXX_Open()、XXX_Read()、XXX_Write()、XXX_Close()等等。這一類的驅動由Device Manager來管理，它調(diào)用ActivateDeviceEx()函數(shù)來加載流驅動。ActivateDeviceEx()的參數(shù)是注冊表中相應的鍵，用來設定加載流驅動的屬性，如Index、Order、Prefix等等。流驅動的注冊表配置信息一般存放在[HKEY_LOCAL_MACHINE\Drivers\BuiltIn]下。流驅動加載成功后，應用程序通過調(diào)用CreateFile()、ReadFile()、WirteFile()等來訪問流驅動的設備。流驅動可以動態(tài)管理，驅動調(diào)試助手就是用來幫助調(diào)試這一類驅動的。
與流驅動相反，本地驅動提供給操作系統(tǒng)的不是標準的流接口，而是事先約定好的特定接口。不同的設備，接口也不一樣。WinCE中，常見的本地驅動有LCD顯示驅動、觸摸屏驅動、鼠標和鍵盤驅動及打印機驅動等。可以看到，本地驅動主要是人機界面相關的驅動。它們由GWES管理，在系統(tǒng)啟動時加載。他們在注冊表中也有各自相應的配置信息。如鍵鼠的注冊表配置如下：
[HKEY_LOCAL_MACHINE"System"CurrentControlSet"Control"Layouts"00000409]
"LayoutFile"="kbdmouse.dll"
"LayoutText"="US"
"PS2_AT"="kbdmouse.dll"
"Matrix"="kbdmouse.dll"
本地驅動由操作系統(tǒng)調(diào)用，應用程序不能訪問。對于這類驅動，驅動調(diào)試助手是無能為力的，只能老老實實的編譯、下載、驗證。
WinCE驅動中經(jīng)常會聽到MDD(Model Device Driver)和PDD(PlatformDependent Driver)的概念，這是從驅動代碼實現(xiàn)的結構來區(qū)分的。WinCE的驅動可以是單層的，也可以是PDD+MDD。這沒有硬性規(guī)定，一個驅動程序可以采用分層結構，也可以采用單層結構。一般來說，單層結構的驅動執(zhí)行效率更高，而分層結構的驅動方便代碼維護和移植。拿串口驅動來說，完全可以采用單層結構。而把它分為PDD和MDD，作為一般的開發(fā)者，我們只需實現(xiàn)PDD層就可以了，MDD層由微軟實現(xiàn)。這樣，驅動開發(fā)的工作量少很多，而代碼的可靠性則有了更好的保證。至于采用哪一種結構的驅動，主要看你的需求。
WinCE 6.0引入了內(nèi)核態(tài)驅動和用戶態(tài)驅動的概念。在WinCE5.0及先前的版本中，驅動工作在用戶態(tài)。從代碼方面看，內(nèi)核態(tài)驅動和用戶態(tài)驅動沒太大差別。如果驅動中沒有采用什么特別的技術，內(nèi)核態(tài)驅動和用戶態(tài)驅動甚至是二進制兼容的。內(nèi)核態(tài)驅動被加載到內(nèi)核空間，用戶態(tài)驅動被加載到特定的用戶進程空間中。從執(zhí)行效率來看，內(nèi)核態(tài)的驅動效率比用戶態(tài)的驅動高。從穩(wěn)定性方面考慮，用戶態(tài)的驅動不會對系統(tǒng)產(chǎn)生致命影響，而內(nèi)核態(tài)的驅動相對危險。同樣，采用哪一種類型的驅動，也是看你的需求。
從驅動加載的時間來看，可分為兩種：系統(tǒng)啟動時加載和需要時加載。一般來說本地驅動都是在啟動時加載的，所以這里說的主要是流驅動。如果想要驅動在系統(tǒng)啟動時加載，只需將它的注冊表配置信息放到[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\]下，如[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Battery]，系統(tǒng)啟動時，Device Manager會自動加載它。需要時加載，顧名思義，就是想加載就加載，想卸載就卸載，很靈活。這里很有必要說一下USB設備的驅動加載，如USB攝像頭驅動，它也屬于需要時加載的驅動。從驅動的接口來看，它屬于流驅動，但相對普通的流驅動，它增加了幾個函數(shù)：USBDeviceAttach()、USBInstallDriver()、USBUnInstallDriver()等。USB攝像頭驅動的加載在USBDeviceAttach()中完成。所以，它無須，也不能，用驅動調(diào)試助手加載。需要時加載的驅動還有一個作用，在無法修改系統(tǒng)的情況下，應用程序中動態(tài)加載該驅動，以完成對硬件的操作。
綜上所述，WinCE驅動的分類，主要有以下幾種分法：
按驅動接口分，可分為本地驅動和流驅動；
按驅動結構分，可分為單層驅動和分層驅動；
按驅動加載的空間分，可分為內(nèi)核態(tài)驅動和用戶態(tài)驅動；
按驅動加載的時間分，可分為啟動時加載和需要時加載兩種。
此文檔主要針對流接口驅動進行詳細介紹，結合我在6410開發(fā)板上實現(xiàn)的PWM驅動來詳細介紹如何在Windows CE中編寫一個流接口驅動。
2 流接口驅動介紹
在計算機系統(tǒng)中，很多硬件設備都在不斷的制造或使用二進制制數(shù)據(jù)，這些設備可以被抽象成流式設備。流式設備的最典型例子是串口。我們在使用串口的時候，二進制數(shù)據(jù)會像流水一樣，從一臺設備經(jīng)過串口線流到另外一臺設備上。應用程序使用文件 API 對設備進行訪問，文件 API 都會被操作系統(tǒng)轉發(fā)到FileSys.exe 進程中，FileSys.exe 發(fā)現(xiàn)是對設備的操作，然后就會把執(zhí)行交給設備管理器處理。設備管理器會根據(jù)具體的請求，調(diào)用不同的流式接口驅動程序中暴露的接口。最終，驅動程序會負責與硬件交互。
2.1 流式接口函數(shù)
通過前面的內(nèi)容我們知道，應用程序通過操作系統(tǒng)對流式接口驅動程序進行訪問。對于操作系統(tǒng)而言，最基本的文件操作原語有 open, close, read,write, seek 五個，分別用來對文件進行打開、關閉、讀取、寫入和移動文件指針操作。但是對于驅動程序，僅有這五個基本的操作原語顯然是不夠的，驅動程序還需要加載/卸載等附加操作。因此，Windows CE 中定義的流式接口函數(shù)有 12 個，有些函數(shù)是直接與某個文件操作 API 對應的，而有些函數(shù)是為了某些特殊的目的，例如電源管理函數(shù)。流式接口函數(shù)的列表如下：
函數(shù)名稱
XXX_Colse
在驅動程序關閉時，應用程序通過CloseHandler()函數(shù)調(diào)用這個函數(shù)
XXX_Deinit
當設備管理器卸載一個驅動程序時調(diào)用這個函數(shù)
XXX_ Init
當設備管理器初始化一個具體的設備式調(diào)用這個函數(shù)
XXX_IOControl
應用程序通過DeviceControl()函數(shù)可以調(diào)用這個函數(shù)
XXX_Open
再打開一個設備驅動程序時，應用程序通過CreateFile()函數(shù)調(diào)用這個函數(shù)
XXX_PowerDown
在系統(tǒng)掛起前調(diào)用這個函數(shù)
XXX_PowerUp
在系統(tǒng)重新啟動時調(diào)用這個函數(shù)
XXX_Read
在一個設備驅動程序處于打開狀態(tài)時，由應用程序通過ReadFile()函數(shù)調(diào)用這個函數(shù)
XXX-_Seek
對設備的數(shù)據(jù)指針進行操作時，由應用程序通過SetFilePointer()函數(shù)調(diào)用這個函數(shù)
XXX_Write??????
在一個設備驅動程序處于打開狀態(tài)時，由應用程序通過WriteFile()調(diào)用這個函數(shù)
XXX_PreClose
通知驅動程序把打開的句柄設置為無效，而避免某些競態(tài)。
XXX_PreDeinit
通知程序把設備句柄設置為無效，而避免某些競態(tài)。
其中 XXX 是驅動程序的設備名稱，例如對于串口驅動程序，串口的設備名稱是 COM，因此，XXX_Open 在串口當中就被替換成了 COM_Open。驅動程序的設備名稱我們可以在注冊表中指定。
2.2 流接口函數(shù)具體介紹
下面具體來介紹上面的接口函數(shù)
1、? XXX_Init 與 XXX_Deinit
XXX_Init該函數(shù)在DllEntry后被調(diào)用. 但不是被應用程序調(diào)用,而是在一定的情況下被設備管理器調(diào)用. 那么"一定情況下"是指什么呢. 是指當用戶開始用一個設備時，設備管理器調(diào)用該函數(shù)初始化設備. 當要實現(xiàn)多個流接口驅動的實例時(串口是個典型的例子, COMx就是COM的多個實例),XXX_Init應該被調(diào)用多次。該函數(shù)要返回設備句柄來為其它的接口函數(shù)能使用,XXX_Deinit是設備被卸載時調(diào)用。函數(shù)聲明如下：
// 初始化設備，在設備被加載的時候調(diào)用，返回設備的上下文句柄
DWORD XXX_Init(
LPCTSTR pContext,???? // 字符串，指向注冊表中記錄活動驅動程序的鍵
LPCVOID lpvBusContext? //ActivateDeviceEx函數(shù)的第四個參數(shù)，VOID 指針
);
// 釋放設備，在設備被卸載的時候調(diào)用，返回設備卸載是否成功
BOOL XXX_Deinit(
DWORD hDeviceContext???????? //XXX_Init函數(shù)返回的設備上下文
);
2、 XXX_Open 與 XXX_Close
XXX_Open與 XXX_Close分別在用戶調(diào)用CreateFile和CloseHandle時被調(diào)用. XXX_Open的參數(shù)hDeviceContext是由XXX_Init返回的值.是一個指向設備context的句柄. 另外, 用CreateFile打開設備時要用”XXX1:”的形式. 后面的數(shù)字根據(jù)注冊表active下的鍵值確定。這兩個函數(shù)的聲明如下：
// 打開設備進行讀寫，返回設備的打開上下文
DWORD XXX_Open(
DWORD hDeviceContext,??? // 設備上下文，由 XXX_Init 函數(shù)創(chuàng)建
DWORD AccessCode,??????? // 設備的訪問模式，從 CreateFile 函數(shù)傳入
DWORD ShareMode????????? // 設備的共享模式，從 CreateFile 函數(shù)傳入
// 關閉設備，返回設備關閉是否成功
BOOL XXX_Close(
DWORD hOpenContext?????? //設備的打開上下文，由XXX_Open 函數(shù)返回
);
通常，在XXX_Open 函數(shù)中，需要為設備申請資源，一般是一些用于管理設備的數(shù)據(jù)結。而在 XXX_Close 函數(shù)中，這些數(shù)據(jù)結構可以被釋放。
3、XXX_Read、XXX_Write 與XXX_Seek
對于設備的主要操作都是通過 ReadFile()，WriteFile()與SetFilePointer()函數(shù)進行的，他們負責對設備進行讀、寫和移動當前指針。在流式接口驅動層面，XXX_Read、XXX_Write與XXX_Seek 三個函數(shù)就提供了對這些操作的支持。這三個函數(shù)的聲明如下所示：
// 從設備中讀取數(shù)據(jù)，返回 0 表示文件結束，返回-1 表示失敗，返回讀取的字節(jié)數(shù)表示成功
DWORDXXX_Read(
DWORD hOpenContext,// XXX_Open 返回的設備打開上下文
LPVOID pBuffer, // 輸出，緩沖區(qū)的指針，讀取的數(shù)據(jù)會被放在該緩沖區(qū)內(nèi)
DWORDCount// 要讀取的字節(jié)數(shù)
);
// 向設備中寫入數(shù)據(jù)，返回-1 表示失敗，返回寫入的字節(jié)數(shù)表示成功
DWORDXXX_Write(
DWORD hOpenContext,// XXX_Open 返回的設備打開上下文
LPCVOID pBuffer, // 輸入，指向要寫入設備的數(shù)據(jù)的緩沖
DWORDCount// 緩沖中的數(shù)據(jù)的字節(jié)數(shù)
);
// 移動設備中的數(shù)據(jù)指針，返回數(shù)據(jù)的新指針位置，-1 表示失敗
DWORDXXX_Seek(
DWORD hOpenContext,// XXX_Open 返回的設備打開上下文
longAmount, // 要移動的距離，負數(shù)表示前移，正數(shù)表示后移
WORDType// 移動的相對位置，有FILE_BEGIN、FILE_CURRENT 和FILE_END
);
4、XXX_IOControl
XXX_IOControl是當用戶用DeviceIOControl定義要完成的操作時, 系統(tǒng)用該函數(shù). dwCode是操作碼，特定于不同的設備.可通過頭文件傳給應用程序. 這兩個參數(shù)是必須的, 其它幾個可為NULL, pBufIn輸入buffer, pBufOut是輸出buffer. 輸入輸出是相對設備的, pdwActualOut是實際輸出的字節(jié)數(shù). 這個函數(shù)的功能比較強大，為什么這么說呢, 因為它的上層DeviceIOControl比較強大, 事實上，DeviceIOControl可以完成幾乎所有的操作其中就包括讀寫操作,函數(shù)的原形如下：
// 向驅動程序發(fā)送控制命令
BOOL XXX_IOControl(
DWORD hOpenContext, // 由 XXX_Open 返回的設備打開上下文
DWORD dwCode, // 要發(fā)送的控制碼，一個 32 位無符號數(shù)
PBYTE pBufIn, // 輸入，指向輸入緩沖區(qū)的指針
DWORD dwLenIn, // 輸入緩沖區(qū)的長度
PBYTE pBufOut, // 輸出，指向輸出緩沖區(qū)的指針
DWORD dwLenOut, // 輸出緩沖區(qū)的最大長度
PDWORD pdwActualOut// 輸出，設備實際輸出的字節(jié)數(shù)
);
對于 XXX_IOControl 函數(shù)，在流式接口中應用非常廣泛，一些不適合于像文件一樣進行讀寫的設備，都可以通過 XXX_IOControl 函數(shù)來控制。
5、 XXX_PowerUp 與 XXX_PowerDown
XXX_PowerDown與XXX_PowerUp這兩個函數(shù), 是在系統(tǒng)掉電與上電時執(zhí)行的, 所以很顯然，你不能調(diào)用它. 它是在內(nèi)核模式下執(zhí)行的. 為了避免死機, 這兩個函數(shù)最好什么都不要做，盡快返回。
6、XXX_PreClose 與 XXX_PreDeinit
這兩個函數(shù)是在Windows CE 5.0 中新引入的函數(shù)，目的是為了防止多線程操作時可能引發(fā)的一些競態(tài)（Race Condition）。這兩個函數(shù)都是可選的，但是如果驅動實現(xiàn)了其中的一個，那么也必須實現(xiàn)另外一個，否則驅動就無法被加載。它們的函數(shù)原形如下：
BOOLXXX_PreClose(
DWORDhOpenContext// 設備的打開上下文
）;
BOOLXXX_PreDeinit(
DWORDhDeviceContext // 設備的上下文
);
設備管理器在對設備進行管理的時候，對于對 XXX_Init、XXX_Deinit、XXX_Open 和
XXX_Close 的調(diào)用，設備管理器內(nèi)部會維持一個全局的 Critical Section 來保證操作的原子性，但是出于效率的考慮，在調(diào)用 XXX_Read、XXX_Write、XXX_Seek 與 XXX_IOControl 的時候，并沒有對這些調(diào)用加鎖，這就導致了引發(fā)競態(tài)的可能。
設想這樣一種情況，系統(tǒng)中有多個線程同時訪問某個驅動程序，當某個線程調(diào)用了XXX_Read 來讀取打開的設備的時候，另外一個線程調(diào)用了 XXX_Close 關閉了打開的設備，因為正如前文所述，設備管理器對 XXX_Read 的調(diào)用是沒有 Critical Section 的保護的，因此有可能調(diào)用 XXX_Read 的線程在沒有執(zhí)行完之前就被執(zhí)行 XXX_Close 的線程搶占，并且關閉了設備，那么當 XXX_Read 的線程重新占有處理器的時候，它所要讀取的設備已經(jīng)被關閉了，這極有可能導致驅動程序崩潰。同樣的問題也發(fā)生在設備卸載的時候。如圖所示：
添加了這兩個函數(shù)之后，就可以有效防止前面的情況發(fā)生。XXX_PreClose 在設備管理器調(diào)用 XXX_Close 之前被調(diào)用，在這個函數(shù)里，驅動程序需要喚醒在等待對設備進行操作的線程，并且釋放申請的資源。這時，還會把 hOpenContext 設置為無效，因此后面的對設備的訪問都會直接返回失敗，而不會使整個驅動程序崩潰。同樣 XXX_PreDeinit 在設備管理器調(diào)用 XXX_Deinit 之前被調(diào)用，可以防止應用程序打開一個已經(jīng)被卸載的設備。
2.3 流接口函數(shù)調(diào)用示例
Windows CE里任何暴露了流式接口函數(shù)的驅動程序都可以被稱作流式接口驅動程序（也就是在驅動程序的 DLL 中把這些函數(shù)作為 DLL的導出函數(shù)）。在流式接口驅動程序中，驅動程序負責把外設抽象成一個文件，而應用程序則可以使用操作系統(tǒng)提供的文件 API 對外設進行訪問。舉例來說，串口驅動程序是典型的流式驅動，如果應用程序希望打開串口，則可以通過如下的語句：
ANDLE hComm;????????????????????????????????????????????
hComm = CreateFile (TEXT("COM1:"), GENERIC_READ |GENERIC_WRITE,
0, NULL, OPEN_EXISTING, 0, NULL);??????????
if (hComm == INVALID_HANDLE_VALUE)????????????????????????
// error opening port; abort????????????????????????????????????????
CreateFile()函數(shù)的第一個參數(shù)不再是文件名稱，而是驅動程序的名字，在這個例子中為“COM1”。同樣的道理如果需要向串口寫入數(shù)據(jù)，只需要使用 WriteFile()函數(shù)，代碼如下：
INT rc;
DWORD cBytes;
BYTE ch;
ch = TEXT ('a');
rc = WriteFile(hSer,&ch, 1, &cBytes, NULL);
當然如果想要讀取串口的數(shù)據(jù)可以調(diào)用WriteFile（）函數(shù)。
2.4 流驅動加載過程
下面是流驅動加載過程：
(1)加載驅動。在當系統(tǒng)啟動時，設備管理器搜尋注冊HKEY_LOCAL_MACHINE\Driver\BuiltIn鍵下面的子鍵，并逐一加載子鍵下的每個驅動，此過程叫BusEnum。
(2)設備管理器從注冊表的dll鍵值中獲取驅動程序所在的DLL文件名。
(3)設備管理器調(diào)用LoadDriver()函數(shù)把DLL加載到自己的虛擬地址空間內(nèi)。
(4)設備管理器在注冊表的HKEY_LOCAL_MACHINE\Driver\Active下面，記錄所有已經(jīng)加載的驅動程序[2]。
(5)設備管理器調(diào)用驅動中的XXX_Init()函數(shù)。
(6)在XXX_Init()中，通常對硬件進行一些基本的初始化操作。通過以上6步，流接口驅動被成功加載。
(7)應用程序使用該設備。首先它調(diào)用CreateFile()打開設備。CreateFile()是在FileSys.exe中實現(xiàn)的。但是FileSys.exe只作簡單判斷，如果發(fā)現(xiàn)打開的設備驅動程序而不是一個文件，那么就重新把主動權交還給設備管理器。
(8)設備管理器調(diào)用驅動程序中的XXX_Open()函數(shù)打開設備。在XXX_Open()中，驅動程序可能會對硬件進行一些額外的初始化工作，使硬件進入工作狀態(tài)。
(9)XXX_Open()函數(shù)把打開設備的結果返回給設備管理器。
(10)設備管理器把XXX_Open()返回的結果，再返回給應用程序的CreateFile()函數(shù)調(diào)用。通過7-10步，設備已被成功打開，至此就可以對設備進行讀寫和控制操作。
(11)應用程序使用第7步CreateFile()函數(shù)返回的句柄作為 ReadFile() / WriteFile()的第一個參數(shù)，向設備發(fā)送讀請求。同樣ReadFile()/WriteFile()要經(jīng)過FileSys.exe轉發(fā)給設備管理器。
(12)設備管理器調(diào)用驅動程序中的XXX_Read() /XXX_Write() 函數(shù)，讀取設備的數(shù)據(jù)信息或向設備寫信息。
(13)在流驅動程序中，XXX_Read() / XXX_Write() 函數(shù)可與硬件交互，從硬件中讀取必要的信息或向硬件寫必要的信息。然后返回給設備管理器，再返回給應用程序。
當應用程序不再使用該設備時，它可調(diào)用CloseHandle()將設備關閉。當系統(tǒng)不再使用設備時，應用程序可調(diào)用DeactivateDevice()函數(shù)把該驅動程序卸載。
2.5 PWM流式接口驅動的實現(xiàn)
??? 至此，我以我在6410 開發(fā)板上實現(xiàn)的PWM驅動程序為例，介紹如何實現(xiàn)流式接口驅動程序。
實現(xiàn)流式接口驅動程序通常只需四個步驟：
1、為流式接口驅動程序選擇一個前綴。
2、實現(xiàn)流式接口驅動 DLL 所必需的接口函數(shù)。
3、編寫 DLL 的導出函數(shù)定義文件.DEF。
4、為驅動程序配置注冊表
正如前文介紹，應用程序通常需要通過設備的名稱來對驅動程序進行訪問。這里我們采用由三個大寫的英文字母，然后加一個 0 到 9 之間的數(shù)字構成的傳統(tǒng)方式命名。PWM驅動的前綴定義為“PWM”。下面就需要為步進電機編寫代碼了，這一步可以在 Platform Builder 或者 eMbeddedVisual C++或者Visual Studio 2005 中進行。Windows CE 的驅動程序就是一個用戶態(tài)的 DLL，因此，任何可以編寫Windows CE DLL 的工具都可以用來開發(fā)驅動程序。我們以使用 PlatformBuilder 為例，介紹開發(fā)驅動程序的過程。
1、我使用的是Windows CE 6.0的開發(fā)環(huán)境，首先要到我們進入選定的BSP的驅動文件夾中創(chuàng)建一個自己的驅動文件夾：
2、進入設備驅動的目錄C:\WINCE600\PLATFORM\SMDK6410\SRC\DRIVERS，創(chuàng)建一個名為My_PWM的文件夾。
3、打開當前路徑下的dirs文件，并添加我們剛創(chuàng)建的文件夾名稱，這樣在編譯驅動的時候我們的驅動程序就可以編譯到系統(tǒng)中去了，如圖2.5所示：
4、進入My_PWM文件夾，創(chuàng)建一個.cpp文件，命名為MyPWMDriver。此文件為驅動程序的源文件，主要用于實現(xiàn)標準的流接口函數(shù)。因為驅動的前綴被定義為“PWM”，因此在流式驅動程序中就必須實現(xiàn)一些 PWM打頭的函數(shù)。首先在MyPWMDriver.cpp中添加必要的頭文件：
#include<ceddk.h>
#include<nkintr.h>
#include<pm.h>
#include<DrvLib.h>
#include<s3c6410_gpio.h>
#include<s3c6410_base_regs.h>
#include<s3c6410_pwm.h>
#include"pmplatform.h"
#include"Pkfuncs.h"
#include"ioctl_cfg.h"
#define Start 2;?????????????????????????//宏定義，用于啟動PWM輸出
#define Stop? 3;?????????????????????? //宏定義，用于關閉PWM輸出
然后，增加 GPIO 端口寄存器和PWM寄存器的聲明：
staticvolatile S3C6410_GPIO_REG * g_pGPIOReg = NULL;??????? //指向IO地址塊的指針
staticvolatile S3C6410_PWM_REG * g_pPWMReg = NULL;?????? //指向定時控制器塊的指針
接下來要先實現(xiàn)驅動程序的入口函數(shù)DllEntry，這個函數(shù)是動態(tài)鏈接庫的入口，每個動態(tài)鏈接庫都需要輸出這個函數(shù)，它只在動態(tài)庫被加載和卸載時被調(diào)用，也就是設備管理器調(diào)用LoadLibrary而引起它被裝入內(nèi)存和調(diào)用UnloadLibrary將其從內(nèi)存釋放時被調(diào)用，因而它是每個動態(tài)鏈接庫最早被調(diào)用的函數(shù)，一般用它做一些全局變量的初始化。函數(shù)實現(xiàn)如下：
BOOLWINAPI
DllEntry(HANDLE?? hinstDLL,
?????????? DWORD dwReason,
?????????? LPVOID /* lpvReserved*/)
{
??? switch(dwReason)
??? {
??? case DLL_PROCESS_ATTACH:
??????DEBUGREGISTER((HINSTANCE)hinstDLL);
?????? return TRUE;
??? case DLL_THREAD_ATTACH:
?????? break;
??? case DLL_THREAD_DETACH:
?????? break;
??? case DLL_PROCESS_DETACH:
?????? break;
#ifdefUNDER_CE
??? case DLL_PROCESS_EXITING:
?????? break;
??? case DLL_SYSTEM_STARTED:
?????? break;
#endif
??? }
??? return TRUE;
}
下面要就要具體的實現(xiàn)幾個流式接口了。首先，是 PWM_Init 和 PWM_Deinit 兩個函數(shù)。這兩個函數(shù)在驅動程序加載和卸載的時候被調(diào)用，在這兩個函數(shù)中通常放置一些初始化工作代碼，我們在這兩個函數(shù)里面做一些相關的物理寄存器映射工作。
DWORDPWM_Init(DWORD dwContext)
{
???RETAILMSG(1,(TEXT("My_PWM_Init----\r\n")));
Virtual_Alloc(); //映射物理寄存器到虛擬空間，因為WinCE使用的是虛擬地址，
//此函數(shù)也是在當前文件實現(xiàn)
??? PWMInit();?????? // 配置PWM端口
??? return TRUE;
}
BOOLPWM_Deinit(DWORD hDeviceContext)
{
??? BOOL bRet = TRUE;
??? if (g_pGPIOReg) {
??????DrvLib_UnmapIoSpace((PVOID)g_pGPIOReg);?//釋放虛擬地址空間
??? }
??? if (g_pPWMReg) {
??????DrvLib_UnmapIoSpace((PVOID)g_pPWMReg);?//釋放虛擬地址空間
??? }
??? g_pGPIOReg = NULL;
??? g_pPWMReg = NULL;
???RETAILMSG(1,(TEXT("USERPWM:PWM_Deinit\r\n")));
??? return TRUE;
}
接下來是PWM_IOControl（）函數(shù)，此函數(shù)也是本驅動的關鍵函數(shù)，由應用程序的DeviceIOControl()調(diào)用，實現(xiàn)指令和數(shù)據(jù)的傳遞：
BOOL(DWORD hOpenContext,
??????????????? DWORD dwCode,
??????????????? PBYTE pBufIn,
??????????????? DWORD dwLenIn,
??????????????? PBYTE pBufOut,
??????????????? DWORD dwLenOut,
??????????????? PDWORDpdwActualOut)
{
??? unsigned char temp[4];???????????????? //用于數(shù)據(jù)接受的臨時數(shù)組
??? DWORD Freq,dutyfactor;
???RETAILMSG(1,(TEXT("My_PWM_IOControl----\r\n")));
??? temp[0] = pBufIn[0];?????????????????? //數(shù)據(jù)接收
??? temp[1] = pBufIn[1];
??? temp[2] = pBufIn[2];
??? temp[3] = pBufIn[3];
??? //memcpy(&temp,&pBufIn, dwLenIn);
??? Freq = temp[3]*256 +temp[2];????????? //獲取應用程序傳遞過來的頻率值
??? dutyfactor = temp[1]*256 +temp[0];??? //獲取應用程序傳遞過來的占空比的//值
??? switch(dwCode)
??? {
??? case 2:
????? {????
PWMSet(Freq,dutyfactor );???? //此函數(shù)在本文件中實現(xiàn)，用于根據(jù)所獲得
//的值設置相應的控制寄存器，以實現(xiàn)我們
//所需要的PWM輸出
?????? break;
?????? }
??? case 3:
?????? PWMStop();???????????????????? ?//關閉PWM輸出
?????? break;
??? default:
?????? break;???
??? }
???RETAILMSG(1,(TEXT("PWM:Ioctl code =0x%x\r\n"), dwCode));
??? return TRUE;
}
剩余的幾個流式接口函數(shù)不進行任何實質(zhì)性的操作，只是實現(xiàn)了一個框架，僅僅輸出一些調(diào)試信息，以便觀查調(diào)用：
DWORD PWM_Open(DWORD hDeviceContext, DWORD AccessCode, DWORD ShareMode)
{
???RETAILMSG(1,(TEXT("USERPWM:PWM_Open\r\n")));
??? return TRUE;
}
//-------------------------------------------------------------------------
BOOL PWM_Close(DWORD hOpenContext)
{
???RETAILMSG(1,(TEXT("USERPWM:PWM_Close\r\n")));
??? return TRUE;
}
//-------------------------------------------------------------------------
Void PWM_PowerDown(DWORD hDeviceContext)
{
???RETAILMSG(1,(TEXT("USERPWM:PWM_PowerDown\r\n")));
}
//-------------------------------------------------------------------------voidPWM_PowerUp(DWORDhDeviceContext)
{
???RETAILMSG(1,(TEXT("USERPWM:PWM_PowerUp\r\n")));
}
//-------------------------------------------------------------------------
DWORD PWM_Read(DWORD hOpenContext, LPVOID pBuffer, DWORD Count)
{
??? RETAILMSG(1,(TEXT("USERPWM:PWM_Read\r\n")));
??? return TRUE;
}
//-------------------------------------------------------------------------
DWORD PWM_Seek(DWORD hOpenContext, long Amount, DWORD Type)
{
???RETAILMSG(1,(TEXT("USERPWM:PWM_Seek\r\n")));
??? return 0;
}
//-------------------------------------------------------------------------
DWORDPWM_Write(DWORD hOpenContext, LPCVOID pSourceBytes, DWORDNumberOfBytes)
{
???RETAILMSG(1,(TEXT("USERPWM:PWM_Write\r\n")));
??? return 0;
}
這樣，所有流式接口驅動程序的導出函數(shù)就實現(xiàn)完畢了。但是現(xiàn)在還不能進行編譯。我們知道，如果要在 DLL 中導出一個函數(shù)，有兩種方法，一種是使用編譯器擴展關鍵字__declspec(dllexport)，如果采用這種關鍵字，還要注意 C++編譯器會對函數(shù)名稱進行修飾，因此還要加上 extern “C”。另外一種更為簡便的方式是使用.DEF 文件。
2.6 編寫 DLL 的導出函數(shù)定義文件.DEF
.DEF 文件定義了 DLL 的導出函數(shù)列表。在My_PWM文件夾中插入一個文本文件，命
名為MyPWMDriver.def，然后在該文件中輸入如下內(nèi)容：
LIBRARY pwm
EXPORTS
??? PWM_Close
??? PWM_Deinit
??? PWM_Init
??? PWM_IOControl
??? PWM_Open
??? PWM_PowerDown
??? PWM_PowerUp
??? PWM_Read
??? PWM_Seek
??? PWM_Write
添加Makefile文件
??? 在此文件夾下新建一個記事本文件添加如下內(nèi)容：
!INCLUDE$(_MAKEENVROOT)\makefile.def
然后重命名為makefile即可。
添加Source文件
???在此文件夾下新建一個記事本文件并添加如下內(nèi)容：
SYNCHRONIZE_DRAIN=1
RELEASETYPE=PLATFORM
TARGETNAME=MyPWMDriver
TARGETTYPE=DYNLINK
SOURCES=MyPWMDriver.cpp
TARGETLIBS=\
??$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib??? \
??$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\DriverLib.lib
INCLUDES_PATH=$(_TARGETPLATROOT)\src\drivers\MyPWMDriver
??? 然后另存為source即可。Source文件將會告訴編譯器要編譯的源文件有哪些，要連接的庫文件有哪些，以及生成的文件類型和文件名。
??? 至此，我們的驅動程序編寫完畢，接下來我們還需要修改一下配置文件和注冊表，讓系統(tǒng)加載我們的驅動程序。
修改配置文件和注冊表
1、修改配置文件
打開platform.bib文件，在文件中加入如下代碼：
$(_FLATRELEASEDIR)\??? ???????NK???SH
這一步的工作是把前面生成的dll加進wince的系統(tǒng)內(nèi)核中。
2、修改注冊表
打開platform.reg文件，在文件中加入如下代碼：
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\MyPWMDriver]
??"Prefix"="PWM"
??"Dll"="MyPWMDriver.dll"
??"Order"="200"
然后要做的工作就是編譯我們的驅動程序到內(nèi)核中，并驗證我們的驅動是否有效，接下來就是一系列的調(diào)試工作。
那么驅動是什么呢？驅動的英文就是Driver，簡單的說來驅動程序就是用來向操作系統(tǒng)提供一個訪問、使用硬件設備的接口，實現(xiàn)操作系統(tǒng)和系統(tǒng)中所有的硬件設備的之間的通信程序，它能告訴系統(tǒng)硬件設備所包含的功能，并且在軟件系統(tǒng)要實現(xiàn)某個功能時，調(diào)動硬件并使硬件用最有效的方式來完成它。
說的形象一點，驅動程序就是軟件與硬件之間的“傳令兵”，這個環(huán)節(jié)可是大大的重要，一旦出現(xiàn)了問題，那么軟件提出的要求就要無人響應，而硬件卻空有一身力氣但無從發(fā)揮，那種狀況下朋友們會發(fā)現(xiàn)自己那本來性能強大且多姿多彩的電腦竟然如同一洼死水，什么都做不來了。因此有人說驅動是硬件的靈魂，可毫不為過。
DLL文件Dynamic Link Library 又稱“應用程序拓展”，是軟件文件類型。在Windows中，許多應用程序并不是一個完整的可執(zhí)行文件，它們被分割成一些相對獨立的動態(tài)鏈接庫，即DLL文件，放置于系統(tǒng)中。當我們執(zhí)行某一個程序時，相應的DLL文件就會被調(diào)用。一個應用程序可使用多個DLL文件，一個DLL文件也可能被不同的應用程序使用，這樣的DLL文件被稱為共享DLL文件。在 Windows操作系統(tǒng)中，每個程序都可以使用該 DLL 中包含的功能來實現(xiàn)“打開”對話框。這有助于促進代碼重用和內(nèi)存的有效使用。
通過使用 DLL，程序可以實現(xiàn)模塊化，由相對獨立的組件組成。例如，一個記賬程序可以按模塊來銷售。可以在運行時將各個模塊加載到主程序中（如果安裝了相應模塊）。因為模塊是彼此獨立的，所以程序的加載速度更快，而且模塊只在相應的功能被請求時才加載。
???? 此外，可以更為容易地將更新應用于各個模塊，而不會影響該程序的其他部分。例如，您可能具有一個工資計算程序，而稅率每年都會更改。當這些更改被隔離到 DLL 中以后，您無需重新生成或安裝整個程序就可以應用更新。Windows操作系統(tǒng)中的一些作為 DLL 實現(xiàn)的文件
·ActiveX 控件 (.ocx) 文件
ActiveX控件的一個示例是日歷控件，它使您可以從日歷中選擇日期。
·控制面板 (.cpl) 文件
.cpl 文件的一個示例是位于控制面板中的項。每個項都是一個專用 DLL。
·設備驅動程序(.drv) 文件
設備驅動程序的一個示例是控制打印到打印機的打印機驅動程序
一、 使用較少的資源
當多個程序使用同一個函數(shù)庫時，DLL 可以減少在磁盤和物理內(nèi)存中加載的代碼的重復量。這不僅可以大大影響在前臺運行的程序，而且可以大大影響其他在 Windows操作系統(tǒng)上運行的程序。
二、 推廣模塊式體系結構
DLL 有助于促進模塊式程序的開發(fā)。這可以幫助您開發(fā)要求提供多個語言版本的大型程序或要求具有模塊式體系結構的程序。模塊式程序的一個示例是具有多個可以在運行時動態(tài)加載的模塊的計帳程序。
三、 簡化部署和安裝
當 DLL 中的函數(shù)需要更新或修復時，部署和安裝 DLL 不要求重新建立程序與該 DLL 的鏈接。此外，如果多個程序使用同一個 DLL，那么多個程序都將從該更新或修復中獲益。當您使用定期更新或修復的第三方 DLL 時，此問題可能會更頻繁地出現(xiàn)。
1、如何了解某應用程序使用哪些DLL文件
右鍵單擊該應用程序并選擇快捷菜單中的“快速查看”命令，在隨后出現(xiàn)的“快速查看”窗口的“引入表”一欄中你將看到其使用DLL文件的情況。
2、如何知道DLL文件被幾個程序使用
運行Regedit，進入HKEY_LOCAL_MACHINESoftwareMicrosrftWindowsCurrentVersionSharedDlls子鍵查看，其右邊窗口中就顯示了所有DLL文件及其相關數(shù)據(jù)，其中數(shù)據(jù)右邊小括號內(nèi)的數(shù)字就說明了被幾個程序使用，（2）表示被兩個程序使用，（0）則表示無程序使用，可以將其刪除。
3、如何解決DLL文件丟失的情況
有時在卸載文件時會提醒你刪除某個DLL文件可能會影響其他應用程序的運行。所以當你卸載軟件時，就有可能誤刪共享的DLL文件。一旦出現(xiàn)了丟失DLL文件的情況，如果你能確定其名稱，可以在Sysbckup（系統(tǒng)備份文件夾）中找到該DLL文件，將其復制到System文件夾中。如果這樣不行，在電腦啟動時又總是出現(xiàn)“***dll文件丟失……”的提示框，你可以在“開始/運行”中運行Msconfig，進入系統(tǒng)配置實用程序對話框以后，單擊選擇“System.ini”標簽，找出提示丟失的DLL文件，使其不被選中，這樣開機時就不會出現(xiàn)錯誤提示了。
rundll的功能是以命令列的方式呼叫Windows的動態(tài)鏈接庫。
Rundll32.exe與Rundll.exe的區(qū)別就在于前者是用于32位的鏈結庫，后者是用于16位的鏈結庫。rundll32.exe是專門用來調(diào)用dll文件的程序。
如果用的是Win98，rundll32.exe一般存在于Windows目錄下；
如果用的WinXP、Win7，rundll32.exe一般存在于Windows\System32目錄下。
若是在其它目錄，就可能是一個木馬程序，它會偽裝成rundll32.exe。
4鏈接方法
當您在應用程序中加載 DLL 時，可以使用兩種鏈接方法來調(diào)用導出的 DLL 函數(shù)。這兩種鏈接方法是加載時動態(tài)鏈接和運行時動態(tài)鏈接。
在運行時動態(tài)鏈接中，應用程序調(diào)用 LoadLibrary 函數(shù)或 LoadLibraryEx 函數(shù)以在運行時加載 DLL。成功加載 DLL 后，可以使用 GetProcAddress 函數(shù)獲得要調(diào)用的導出的 DLL 函數(shù)的地址。在使用運行時動態(tài)鏈接時，無需使用導入庫文件。
Win32 DLL的特點
Win32 DLL與 Win16 DLL有很大的區(qū)別，這主要是由操作系統(tǒng)的設計思想決定的。一方面，在Win16 DLL中程序入口點函數(shù)和出口點函數(shù)（LibMain和WEP）是分別實現(xiàn)的；而在Win32 DLL中卻由同一函數(shù)DLLMain來實現(xiàn)。無論何時，當一個進程或線程載入和卸載DLL時，都要調(diào)用該函數(shù)，它的原型是
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOIDlpvReserved);
其中，第一個參數(shù)表示DLL的實例句柄；第三個參數(shù)系統(tǒng)保留；這里主要介紹一下第二個參數(shù)，它有四個可能的值：DLL_PROCESS_ATTACH（進程載入），DLL_THREAD_ATTACH（線程載入）,DLL_THREAD_DETACH（線程卸載），DLL_PROCESS_DETACH（進程卸載），在DLLMain函數(shù)中可以對傳遞進來的這個參數(shù)的值進行判別，并根據(jù)不同的參數(shù)值對DLL進行必要的初始化或清理工作。舉個例子來說，當有一個進程載入一個DLL時，系統(tǒng)分派給DLL的第二個參數(shù)為DLL_PROCESS_ATTACH，這時，你可以根據(jù)這個參數(shù)初始化特定的數(shù)據(jù)。另一方面，在Win16環(huán)境下，所有應用程序都在同一地址空間；而在Win32環(huán)境下，所有應用程序都有自己的私有空間，每個進程的空間都是相互獨立的，這減少了應用程序間的相互影響，但同時也增加了編程的難度。大家知道，在Win16環(huán)境中，DLL的全局數(shù)據(jù)對每個載入它的進程來說都是相同的；而在Win32環(huán)境中，情況卻發(fā)生了變化，當進程在載入DLL時，系統(tǒng)自動把DLL地址映射到該進程的私有空間，而且也復制該DLL的全局數(shù)據(jù)的一份拷貝到該進程空間，也就是說每個進程所擁有的相同的DLL的全局數(shù)據(jù)其值卻并不一定是相同的。因此，在Win32環(huán)境下要想在多個進程中共享數(shù)據(jù)，就必須進行必要的設置。亦即把這些需要共享的數(shù)據(jù)分離出來，放置在一個獨立的數(shù)據(jù)段里，并把該段的屬性設置為共享。
5故障排除
可以使用多個工具來幫助您解決 DLL 問題。以下是其中的部分工具。
Dependency Walker
Dependency Walker 工具可以遞歸掃描以尋找程序所使用的所有依賴 DLL。當您在 Dependency Walker 中打開程序時，Dependency Walker 會執(zhí)行下列檢查：
·Dependency Walker 檢查是否丟失 DLL。
·Dependency Walker 檢查是否存在無效的程序文件或 DLL。
·Dependency Walker 檢查導入函數(shù)和導出函數(shù)是否匹配。
·Dependency Walker 檢查是否存在循環(huán)依賴性錯誤。
·Dependency Walker 檢查是否存在由于針對另一不同操作系統(tǒng)而無效的模塊。
通過使用 Dependency Walker，您可以記錄程序使用的所有 DLL。這可能有助于避免和更正將來可能發(fā)生的 DLL 問題。當您安裝 Microsoft VisualStudio 6.0 時，Dependency Walker 將位于以下目錄中：
drive\Program Files\Microsoft Visual Studio\Common\Tools
DLL Universal Problem Solver
DLL Universal Problem Solver (DUPS) 工具用于審核、比較、記錄和顯示 DLL 信息。下表說明了組成 DUPS 工具的實用工具：
·Dlister.exe：該實用工具枚舉計算機中的所有 DLL，并且將此信息記錄到一個文本文件或數(shù)據(jù)庫文件中。
·Dcomp.exe：該實用工具比較在兩個文本文件中列出的 DLL，并產(chǎn)生包含差異的第三個文本文件。
·Dtxt2DB.exe：該實用工具將通過使用 Dlister.exe 實用工具和 Dcomp.exe 實用工具創(chuàng)建的文本文件加載到 dllHell數(shù)據(jù)庫中。
·DlgDtxt2DB.exe：該實用工具提供 Dtxt2DB.exe 實用工具的圖形用戶界面(GUI) 版本。
DLL影響
6文件修復
1、用Windows系統(tǒng)盤功能進行文件修復；
2、若在此之前有一鍵備份過，可以重新還原；
3、從網(wǎng)上下載系統(tǒng)文件然后覆蓋到原文件夾里；
硬件接口為電腦等的信息機器的硬件之間通信時的物理連接器形狀、發(fā)送接收信號的方法（協(xié)議）等等的規(guī)格。主要可分為并行鏈接的和比特序列鏈接的。序列鏈接者相比起并行鏈接者，多得多使用同一電線作為信號控制線和電源供應線。個人電腦領域，因并行鏈接向更高傳輸速度的發(fā)展遇到瓶項，而在向各接口的序列鏈接方式遷移（參看總線）。
泛用可熱插拔（可以在機器電源開著時插拔）者
串口USB IEEE 1394以太網(wǎng)（100BASE 為止）ExpressCardeSATA并口以太網(wǎng)（1000BASE-T）
一般不可熱插拔的普及接口，可能已有支持熱插拔的實用產(chǎn)品。
并行SCSI IDEPCI序列PCI-ExpressSerial ATA
通常認為曾經(jīng)泛用的遺產(chǎn)設備（舊世代的接口）。不包括PC卡中可熱插拔的那些。
并行ISA并行端口（IEEE 1284 、 Centronics 規(guī)格兼容）PC卡序列PS/2RS-232非泛用、用途受限者序列MIDI - 電子樂器的控制并行GP-IB - 測量儀器的控制其他電源插座
軟件接口[編輯]
軟件間通信時傳遞消息（message）的規(guī)格。
API進程間通信電腦網(wǎng)絡
接口 (程序設計) - 程序編寫或設計的方法論中程序組件功能的抽象化物。
用戶接口[編輯]
用戶接口 - 人類與機器、設備、計算機程序或其他復雜工具交互的中介物的聚合。常用于電腦系統(tǒng)和電子設備文脈。
人機界面 - 機械系統(tǒng)、交通工具或工業(yè)設備的用戶接口有時會指稱為人機界面（Human-Machine Interface ，縮寫為 HMI）。
DLL:程序編制一般需經(jīng)編輯、編譯、連接、加載和運行幾個步驟。在我們的應用中，有一些公共代碼是需要反復使用，就把這些代碼編譯為“庫”文件；在連接步驟中，連接器將從庫文件取得所需的代碼，復制到生成的可執(zhí)行文件中。這種庫稱為靜態(tài)庫，其特點是可執(zhí)行文件中包含了庫代碼的一份完整拷貝；缺點就是被多次使用就會有多份冗余拷貝。
為了克服這個缺點可以采用動態(tài)連接庫。這個時候連接器僅僅是在可執(zhí)行文件中打上標志，說明需要使用哪些動態(tài)連接庫；當運行程序時，加載器根據(jù)這些標志把所需的動態(tài)連接庫加載到內(nèi)存。
另外在當前的編程環(huán)境中，一般都提供方法讓程序在運行的時候把某個特定的動態(tài)連接庫加載并運行，也可以將其卸載（例如Win32的LoadLibrary()&FreeLibrary()和Posix的dlopen()&dlclose()）。這個功能被廣泛地用于在程序運行時刻更新某些功能模塊或者是程序外觀。
API函數(shù)包含在Windows系統(tǒng)目錄下的動態(tài)連接庫文件中。Windows API是一套用來控制Windows的各個部件的外觀和行為的預先定義的Windows函數(shù)。用戶的每個動作都會引發(fā)一個或幾個函數(shù)的運行以告訴Windows發(fā)生了什么。這在某種程度上很像Windows的天然代碼。而其他的語言只是提供一種能自動而且更容易的訪問API的方法。當你點擊窗體上的一個按鈕時，Windows會發(fā)送一個消息給窗體，VB獲取這個調(diào)用并經(jīng)過分析后生成一個特定事件。
更易理解來說：Windows系統(tǒng)除了協(xié)調(diào)應用程序的執(zhí)行、內(nèi)存的分配、系統(tǒng)資源的管理外，同時他也是一個很大的服務中心。調(diào)用這個服務中心的各種服務(每一種服務就是一個函數(shù))可以幫助應用程序達到開啟視窗、描繪圖形和使用周邊設備等目的，由于這些函數(shù)服務的對象是應用程序，所以稱之為Application ProgrammingInterface，簡稱API 函數(shù)。WIN32 API也就是MicrosoftWindows32位平臺的應用程序編程接口。
凡是在 Windows工作環(huán)境底下執(zhí)行的應用程序，都可以調(diào)用Windows API。
首先，BSP（板級支持包，Board Support Packet）是一個支持特定標準開發(fā)板（SDB，Standed DevelopmentBoard）硬件的WinCE軟件集成包，主要包括Boot Loader程序，OAL程序和板載硬件驅動程序
一個目標板的BSP開發(fā)主要有以下幾個大的流程：
1.建立BootLoader，用來下載映像，啟動系統(tǒng)。
2.編寫OAL程序，用來引導系統(tǒng)核心映像和初始化、管理硬件。
3.為新的硬件編寫硬件驅動。
4.設置平臺配置文件，便于Platform Builder編譯系統(tǒng)。
其中，Boot Loader 就是在操作系統(tǒng)內(nèi)核運行之前運行的一段小程序，大家應該都很熟悉，或許以后還會再詳細說一下，不明白的同學就去百度知道一下吧，而OAL（OEM 適配層，OEMAdaptation Layer），它是BSP驅動的一部分，作用是讓WinCE在OEM的硬件上運行起來，
l 、NOR的讀速度比NAND稍快一些。
2、 NAND的寫入速度比NOR快很多。
3 、NAND的4ms擦除速度遠比NOR的5s快。
4 、大多數(shù)寫入操作需要先進行擦除操作。
5 、NAND的擦除單元更小，相應的擦除電路更少。
此外，NAND的實際應用方式要比NOR復雜的多。NOR可以直接使用，并可在上面直接運行代碼；而NAND需要I/O接口，因此使用時需要驅動程序。不過當今流行的操作系統(tǒng)對NAND結構的Flash都有支持。此外，Linux內(nèi)核也提供了對NAND結構的Flash的支持。
用戶配置文件就是在用戶登錄電腦時，或是用戶在使用軟件時，軟件系統(tǒng)為用戶所要加載所需環(huán)境的設置和文件的集合。它包括所有用戶專用的配置設置，如程序項目、屏幕顏色、網(wǎng)絡連接、打印機連接、鼠標設置及窗口的大小和位置等。
VC中如何徹底刪除一個類?????
在VC環(huán)境中進行編程時，有時需要將某個類刪除掉，但在項目的ClassView中又卻不能通過右鍵點擊這個類直接刪除，而需要到FileView中逐個刪除*.h 和 *.cpp文件，但是工程目錄中仍保留有這個類的文件及相關信息。????
通過搜索找到如下能夠徹底刪除一個類的方法：???
?１，打開工程，在FileView中刪除這個類的相關 *.cpp 和 *.h 。（用左擊鼠標選中再按鍵盤的DELETE鍵就行了）????
2, 關閉工程，再刪除工程目錄中的*.cpp 和 *.h文件，然后刪除保留有這個類相關信息的*.ncb 和 *.clw文件。????
? 3, 重新打開工程，激活ClassWizard,出現(xiàn)提示框，點確定后，在彈出的對話框中單擊Add?? all,??Ok.?????
? 注:? *.dsp(DeveloperStudio Project)：是VC++的工程配置文件,比如說你的工程包含哪個文件,你的編譯選項是什么等等,編譯的時候是按照.dsp的配置來的。
?*.dsw(DeveloperStudio Workspace)：是工作區(qū)文件，用來配置工程文件的。它可以指向一個或多個.dsp文件。
? *.clw：是ClassWizard信息文件,實際上是INI文件的格式,有興趣可以研究一下.有時候ClassWizard出問題,手工修改CLW文件可以解決.如果此文件不存在的話,每次用ClassWizard的時候會提示你是否重建。
?*.rc 稱為資源文件, 其中包含了應用程序中用到的所有的windows資源, 要指出的一點是rc文件可以直接在VC集成環(huán)境中以可視化的方法進行編輯和修改。
?*.ncb：無編譯瀏覽文件(no compile browser)。當自動完成功能出問題時可以刪除此文件，build后會自動生成。
?*.c：源代碼文件，按C語言用法編譯處理。
?*.cpp：源代碼文件，按C++語法編譯處理。
?*.h是頭文件，一般用作聲明和全局定義。
總結
- 上一篇： 章节1 网络安全行业
- 下一篇： TP-LINK WR886N路由器登录过