Program 的execution image : EXE, DLL, STACK, HEAP, UNUSED..
沒有virtual memory 的machine，因為各section 內不可中斷，所以一些object (DLL, heap) unload, load 後，就會出現memory fragementation。

section 內不可中斷： STACK 內用來存放stack ，當STACK用"滿"時，也就是pointer 頂到了在他前面的DLL section，不可能跳過這些區域，由未使用的UNUSED section 中，再找一塊memory 出來，當作是STACK，繼續工作。因為UNUSED Section 和STACK Section 並不連續，stack pointer沒辦法工作。

範例是用DLL來作比喻：假設DLL section load有兩個DLL : DLL1, DLL2，當DLL2 不需要使用了，program unload DLL2，然後load另一個DLL : DLL3，如果DLL 3 < DLL2，則可以順利的load到原DLL 2 空出來的區域，但是當DLL3 > DLL2時，DLL2 空出來的區域就浪費掉了。

使用virtial memory 的machine，同樣的 execution image : memory 的管理以4k 為單位，可以任意mapping到pysical memory中，所以即使physical memory 上兩塊不連續的區域，都可以藉由virtial memory translation 讓他們在virutal memory space中是連續的(一個接在另一個的後面)，所以memory fragementation 最大不會超過4k。

sysgen ,,, build - 不會作platform.bat 的dependent check

CEBUILD 有一個custom platform prebuild bat : <platform_name>.bat

這個bat檔會在所有build動作之前執行，所以會被用來宣告很多define, undefine function。
platform src 再follow 這個define 作condition compile。

但是

很愚蠢的是...如果修改了這個 bat 檔，執行sysgen (當然不會build)和用command line到 platform Src 下任何一個folder 作 "build" 動作，該 build program 並不會 "察覺" 到 batch file已經變更，必須要要compile source。

所以，必須要"手動"，到改動batch file 相關定義有關的地方下 "build -c" (-c 是force clean)，強制re compile，才行。

也就是說... source depnendency 是手動check 的 ( !!!! 沒有source depnendency check，加上close source, ... 又有人說"Build and Sysgen" + check "Clean befor Build" 會讓private folder的code掛掉 !!! 那，programmer又怎能保證 source module間的一致 ???? )

---

據Robert 所說，platform..bat 內所設定的environment variable 只和platform folder內的source code有關係，所以修改過 platform ...bat後，到platform 下作"build -c" 才是最保險的作法。

再來，build 只有作compile，沒有link，所以做完build -c 後，要sysgen重新link

OEMIoControl

debug 時，log 有:

OEMIoControl: Unsupported Code 0x10100fc - device 0x0101 func 63

所以查一下 OEMIoControl: http://msdn.microsoft.com/library/
default.asp?url=/library/en-us/wcedsn40/html/cmrefOEMIoControl.asp

OEMIoControl是OAL implement的，當 device driver或application 呼叫 KernelIoControl( )這個Kernel Sevice Function 時，kernel就會呼叫OEMIoControl，另外，SystemParametersInfo( )這個function call 也會呼叫OEMIoControl( )，由OAL 負責傳回system information。

既然名稱是IOCTL，參數也跟Linux 的IOCTRL一樣，是用function number配上structure pointer來傳遞參數。

OEMIoControl 是OAL 實做的，不是device driver，device driver。Device Driver實做的Io Control會是 Dll export的介面，不需要由kernel 呼叫。

Wiindows CE 6.0 Open Source (?)

今天在 jserv 與 Open Source 新聞看到這個消息: CE 6.0 將開放原始碼。

開放的Source Code有多少呢？ 依照 jserv 文章的link到 WindowsForDevice.com 的文章看，是 100 % (!)。但是其他的新聞都沒有說明是100%，只有說是比5.0多56%。

WindowsForDevice.com 的說明比較仔細，share source code只要在VS (6.0 的Platform builder 已經成為Visual Studio 2005的一個plug-in)的catalog item，如果該item是"private"，則會出現一個License Agreement dialog要求你確認。
-- 所以，不用像5.0一樣要到MS網站去申請( 還不知道什麼時候會回覆)。

依照說明，open 的方式是BSD-like，也就是說，可以任意修改，不必附source code給customer，也不用 "交回" MS。 但是 jserv說，該license尚未獲得 OSI 認可。

c|net也有新聞說明 6.0 open source ，並且說是"完全" 開放。新聞中有一句話:

WinCE嵌入式系統產品平均開發時間為8個月，若以Linux開發則平均得拉長至14個月；此外WinCE具有各式各樣的模組，在Linux上可能得自行開發或另外授權，事實上Linux不見得免費或比較便宜，嵌入式系統廠商必須以上市時間等整體開發成本為考量。

如果embedded system design 就像一般軟體樣，只要東西拉一拉, build, rom 化 就OK的話，他說得倒是不錯。但是 embedded system 花最多時間的地方是在處理embedded system 的hardware 限制上，產品的prototype是很快，但是debug時間就要很長，當然你也可以就接受產品有那麼點defect，然後就上市，但是那看起來就會是有點"半吊子"的東西。

而在Debug 的時後，有source code跟沒source code的差別 有多大，應該是不用說明了，沒有source code 的東西，就算有一堆文件，也比不上有source code的東西 來的好用。

這一點有多重要？我有一次面試一家CE base 產品的公司，唯一的題目就是"一個沒有source code的東西如果有問題，要怎麼作 ? "

-- 我還真不知道怎麼作呢，只有一次同事使用pSXS的經驗，利用proxy + snipper 找出原來問題在pSXS沒有open 出來的IP Stack 上。還有一次用sample clip 證明是vendor 沒有release出來的decoder的問題，還有用B廠家的code+A廠家的library 輸出debug message，證明A vendor沒有release的module中parameter有錯誤。

但是證明了問題出在沒有open source的code上，新的感覺是如何呢?
當然是非常，非常的不好。
覺得浪費了自己的生命在非常無聊的事情上，
尤其是知道世界上有open 的source code有一大堆都研究不完了，
卻還要浪費生命為這些寫的爛又不release的code作debug.....

但是source open 出來終算是好事一件，光是這一點就想趕快切到6.0去。否則，依照慣例，MS的產品至少要到QFE出了兩月份後才能用。

---

這一篇，很明顯的，是一篇抱怨文 :P

Usefule EXE in "SDK\BIN\I386"

CE的 "\SDK\BIN\I386" 里有很多有用的program，像errlook.exe就是error code的翻譯程式，當執行win32 program出現error code時，輸入error code，就會顯示eror code的名稱（中文的喔)。
像 執行 remote debug 時出現 Error Code : 126，查的結果是："找不到指定的模組"。

Suspend/Resume

Suspend 狀態是將 CPU 中，所有週邊和cpu core的clock ，power 都停掉，只留下

• DRAM refresh
• RTC
• INT

三個部份還有動作，這樣的目的是要減少電源消耗，同時盡量維持執行狀態。
讓裝置回到正常狀態的方式有

• 外部中斷
• RTC TimerUp (也是中斷)

從PowerOff中恢復後，要盡量讓系統回到當初power Off的狀態。

Suspend/Recover的動作有一點像Task Switch，就是Stack Frame的操作：在斷電前將StackFrame保存在固定的地方，Recover時到那個地方拿回Stack Frame回存，動作跟TaskSwitch一模一樣。

CE 的Suspend/Resume 動作 需要driver的配合，所以所有Driver都要implement (and export) PowerUp/PowerDown function。另外GUI 的部份也要response to WM_XX 這個power state change message。

在PUBLIC\COMMON\OAK\DRIVERS\PM\MDD\pmresume.cpp 的comment中有說明：

Application (Drvier) 中不可以直接呼叫 PowerOffSystem( )來suspend system，要藉由 SetSystemPowerState ( ) 這個 Win32 funtion 來轉換 power status 到 suspend/resume 狀態才行。 因為 SetSystemPowerState( ) 在呼叫PowerOffSystem( ) 之前，還會呼叫PM 的function 一一呼叫所有Device 的 PowerOn/PowerDown function，還會post necessary message to GWES server，最後才呼叫PowerOffSystem( )將所有cpu core關閉。

SetSystemPowerState()是一個手套，會去呼叫PlatformSetSystemPowerState()，

CEC 和Platform Builder

PUBLIC\COMMON\OAK\CATALOG\ 目錄下都是PlatformBuilder 使用的設定資料。

• CEC : 所有的 *.cec 檔案，所有import 進platform builder的cec都會有一份備份在這裡。這些cec file 可以作為create cec 物件的參考。
• NewPlatformWizard : PlatformBuilder - New Platform 時幾個building template 的內容，在這些file中可以看出各template額外設定的Build Option, SYSGEN Variable。這些都是在platform builder中看不到的(尤其是SYSGEN_XXX變數)。

*.CEC是platform builder的元件定義檔(其實也很不完全，只有定義出一些該元件需要的資料)，在Platform Builder中提供CEC Edit 工具來修改，Create CEC檔。

Goupe 的階層在CEC中使用類似目錄字串的方式表示(以"\"區分)。

CEC Editor的使用很不直觀，有些是要新增，修改property後，該item才會重新"落"在適當的階層下。還有先找個"地方"新增item完後，再edit property，或是按右鍵，讓隸屬於某一個item (造成item dependency)。

"Parent Node Require This Groupe" 就是dependency (?)

使用CEC Editor時，可以開啟一個複雜的CEC，然後New一個測試 File，用"右鍵"試試使用方法。

這個功能比較有用的地方在於 能知道 Catalog 中item 與該source code所在位置。(Catalog與SYSGEN_VAR 的關係在PB中就會自動顯示)。

---

由於 各Item間有dependency存在，所以在 Edit Platform時，有時後只有選一個item，卻有很多其他item被自動加入，這是PlatformBuilder依照該Item的dependency自動加進去的，在Platform Builder的 OSDesignView中有小小的icon，可以用來區分這是你選擇加入的還是因為depends on other item而被加入的：

上面兩個圖示，一個下面有小小的紅色檢箭頭就是你選擇加入的，沒有小小箭頭的就是因為dependency 加入的。

Workspace的description file : *.pbxml 只有紀錄 你選擇加入的item，dependent item沒有紀錄，但是在每次open Workspace時，platform builder會再自動依照該item 的CEC描述加入需要的item。
(所以修改過CEC file，要重新open一次workspace)