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