**：
[裝置管理器]
裝置管理**在private\winceos\coreos\device\目錄.
看看裝置管理器的入口點devmain.c.在wince5.0時代, 裝置管理器是作為乙個程序來實現的:devece.exe. 所以裡面就是乙個入口函式winmain()呼叫startdevicemanager()函式.再看wince6.0, devmain.c多出來了devmainentry(), dllentry(), 啊哈~ 看來裝置管理器也慘遭kernel的命運.變成了device.dll了，變成了核心空間程式.
wince6.0當中，oal.exe(nk.exe),kernel.dll,(kitl.exe可選)都被載入到核心空間。
[裝置驅動載入過程]
oal.exe加 載了kernel.dll, kernel.dll載入device.dll, device.dll載入devmgr.dll, 這個就是負責載入, 解除安裝, 管理流驅動的. 流程比較了半天,wince6.0的驅動載入和wince5.0的載入過程沒有發現什麼差別.也是分為靜態載入和動態載入.靜態載入就是啟動時候載入.設 備管理器找到hklm\drivers\builtin下busenum.dll載入, 這是乙個匯流排列舉驅動, 依照order值指示的載入順序,它來完成後續的載入工作, 也是使用activedevice來載入. 至於動態載入,就是在系統起來後, 使用activedevice載入乙個驅動.載入後,也是在登錄檔的active下面顯示裝置資訊.
驅動在登錄檔需要提供的資訊基本是一樣的, 也是prefix, dll, index, order, iclass這些基本的都一致,關鍵區別在flags, userprocgroup這2個鍵.
[flags:驅動載入配置]
登錄檔裡每個驅動可以包含乙個鍵flags, 這個配置決定了驅動的載入.下面是wince5.0的flags的可選配置,(可以多項相與得到復合值)說明如下:
devflags_none
登錄檔沒有指定flags
devflags_unload
指示裝置管理器執行完init後卸掉驅動,並且返回成功.匯流排列舉驅動都這麼幹.
devflags_loadlibrary
通知裝置管理器使用loadlibrary代替loaddriver.2者的區別:loadlibrary載入的可以paged out.
devflags_noload
指示裝置管理器,驅動將不會被載入.
devflags_nakedentries
指 示裝置管理器字首不要用.可以用字首來active,但找函式入口點時候不要用字首. 比如電池驅動指定這個標記後,裝置管理器會用bat這個字首去實現驅動,但在呼叫介面時候不會預設的用bat_init,.bat_***,而是自己去找 入口點. 這樣的目的是可以自由修改驅動介面函式名,可以不要和字首相同了.
devflags_bootphase_1
要求載入驅動時候,必須bootphase大於1. bootphase就是啟動階段的意思. 裝置管理器啟動是分階段的.bootphase1在找登錄檔.;bootphase2 載入驅動;bootphase3開始執行.(題外話,也可以只分2個階段.)
devflags_irq_exclusive
在訪問irq時候再載入.
wince6.0在此的基礎上增加了幾個
devflags_load_as_userproc
這個是重頭戲, 指示裝置管理器,把驅動給載入到user mode. 裝置管理器會建立乙個reflector.這個就是wince6.0主要的改進了.現在我也不懂, 後面再說說這個.
devflags_nounload
阻止驅動被解除安裝.
devflags_trustedcallreronly
指示裝置管理器限制驅動只能被信任的應用程式open. 在wince5.0的文件裡面也說有這個,但**中沒有發現,所以5.0應該是沒有實現.(時空錯亂?還是文件設計先行?還是ms藏私貨了,反正我的版本沒有.)
[驅動模型]
wince6.0 的驅動模型難道沒有變化?對比wince5.0,所有驅動都是被device.exe或者gwes.exe載入. 在wince6.0, 這二者不存在了,變成了dll被nk.exe載入,自然的想法是, 所有驅動被載入到了nk.exe的程序空間? 僅此而已?
不管怎樣,先啟動模擬器觀察證實一下, wince6.0的裝置只有nk.exe, shell.exe, servicesd.exe, explorer.exe, 4個udevice.exe.嗯哼~, 不止device.exe沒有了, 包括filesys.exe, gwes.exe……全體陣亡了,全變成nk.exe載入的dll. udevice.exe出現4個! 直覺這是驅動. 這些現象反映到驅動模型到底有什麼變化?
前面的驅動載入時候提到登錄檔的flags差異和新增userprocgroup.flags增加了乙個devflags_load_as_userproc,這個選項指示裝置管理器將驅動載入成為user mode driver.再看看下面在devcore.c中startdevicemanager()的偽**:
startdevicemanager()
初始化裝置資料結構, 啟動io資源管理,pnp裝置管理,電源管理
devloadinit();// 這兒載入裝置驅動.
inituserpromgr();//ce6新增,這兒初始化 user mode driver handling
while(1)
processautoderegisterdevs();
processdyingdevs();
processdyingopens();嗯哼~ 看來還支援user mode 的驅動.既然叫user mode, 那肯定就不是載入在核心空間,不是在nk.exe空間了. 找到下面這張圖, 簡單明瞭.
裝置管理器會依據devflags_load_as_userproc的指 示建立乙個新的程序載入乙個驅動, 這個程序就是udevice.exe了, 難怪模擬器裡面有4個udevice.exe.在看左上邊那個udevice.exe, 裡面包含一組user-mode driver dll. 嗯哼~ 乙個程序的確是可以載入多個dll的. 但哪些user mode驅動會被載入到乙個udevice.exe? 呵呵, 一下就能猜到userprocgroup這個鍵的作用了:給使用者模式驅動分組啊, 相同組的載入到乙個程序. 嗯, 順便想起手冊裡面user mode driver host是什麼了,使用者模式驅動的寄主啊即udevice.exe.
具體怎麼分組?userprocgroup要等於什麼值? 看看登錄檔:
[hklm\drivers\procgroup_0002]
procname=」servicesd.exe」
procvolprefix=」$services」
proctimeout=20000
[hklm\driver\procgroup_0003]
procname=」udevice.exe」
procvolprefix=」$udevice」
嗯 哈~ 邏輯很簡單, 在這建立乙個組, 比如0003, 如果要加入這個組, 設定userprocgroup等於這個3即可.0003只是表示代號,不是表示3個驅動哦.procname代表載入驅動的host程序名字. 原來udevice.exe和servicesd.exe程序是這麼來的.
趕緊總結一下. 如果沒有flags指定devflags_load_as_userproc, 那麼驅動將被kerneldevice.dll
載入到核心空間,即kernel mode driver;如果指定了,驅動將被載入到乙個使用者程序udevice.exe,成為user mode driver. 乙個udevice.exe可以載入多個user mode driver或者只載入乙個.
winCE6 0攝像頭驅動分析
分析閱讀的是s3c6410 wince6.0的攝像頭驅動，s5pv210雖然也是6.0，但結構大不相同，暫且不提。根據msdn，應用層呼叫攝像頭驅動初始化時序如下 1 呼叫cam init和cam open。2 dshow呼叫findfirstdevice得到裝置名，呼叫createfile開啟。3...
如何安裝WinCE6 0
說實話，這個也寫一篇blog，實在不應該。今天重新安裝了wince6.0的開發環境，感覺還是挺累的。所以還是寫一篇吧，這個寫起來比較簡單，也算是這個月最後一篇blog了。下面開始 1.首先安裝visual studio 2005。7.當然，以後如果出了新的補丁，也要繼續打下去了。現在要公升級.net...
wince6 0 開發流程
windows ce概述從6.0版本開始，windows ce的名字改為windows embedded ce，當然這也是為了結合windows embedded品牌作出的改變。ce經過了十年的風風雨雨之後，終於在ce 6.0這個版本上再次浴火重生了。ce 6.0經歷了ce歷史上第二次 核心重寫，使...