wince配置文件

Ⅰ Win10下開發WinCE的配置

• 設置目標或測試計算機是配置計算機以便進行自動驅動程序部署、測試和調試的過程。一個測試和調試環境具有兩台計算機：主計算機和目標計算機。目標計算機也稱為「測試計算機」。使用主機上的 Visual Studio 開發和構建驅動程序。調試程序在主機上運行並且位於 Visual Studio 用戶界面中。當測試和調試驅動程序時，驅動程序在目標計算機上運行。

  主計算機和目標計算機必須能夠彼此按名稱執行 ping 操作。如果兩台計算機已加入到同一工作組或同一網路域，則此操作可能更容易。如果你的計算機位於工作組中，我們建議你使用路由器（而非集線器或交換機）連接計算機。不支持對虛擬機進行設置。

• 准備目標計算機以進行設置

  在目標計算機上，安裝將用於運行和測試驅動程序的操作系統。

  如果在 x86 或 x64 目標計算機上啟用「安全啟動」，則禁用該功能。

  如果目標計算機使用 ARM 處理器，則安裝 Windows 調試策略。則無需禁用「安全啟動」。

  在目標計算機上，運行與目標計算機平台匹配的 WDK 測試目標安裝程序 MSI。可以在 Remote 下的 Windows 驅動程序工具包 (WDK) 安裝目錄中找到該 MSI。

  例如：C:Program Files (x86)Windows Kits10Remotex64WDK Test Target Setup x64-x64_en-us.msi

  如果目標計算機運行的是 N 或 KN 版本的 Windows，則安裝適用於 N 和 KN 版本的 Windows 的媒體功能包。

  如果目標計算機運行的是 Windows Server，請查找剛才通過 WDK 測試目標設置 MSI 創建的 DriverTest 文件夾。（例如：c:DriverTest）。右鍵單擊「DriverTest」文件夾，然後選擇「屬性」。在「安全」選項卡上，向「經過身份驗證的用戶」組授予「修改」許可權。

• 驗證主機和目標計算機可以彼此執行 ping 操作。打開命令提示符窗口，並輸入 ping 192.186.X.X(ip_adress)。

  如果主計算機和目標計算機已加入到一個工作組，但它們位於不同的子網上，你可能必須調整某些防火牆設置，以便主計算機和目標計算機可以通信。請按照下列步驟進行操作：

  兩種方法（選一即可）：

  方法一：

  在目標計算機上的「控制面板」中，轉到「網路和 Internet」>「網路共享中心」。注意你的活動網路。它可能是「公共網路」、「私有網路」或「域」。

  在目標計算機上的「控制面板」中，轉到「系統和安全」>「Windows 防火牆」>「高級設置」>「入站規則」。

  在入站規則列表中，查找用於活動網路的所有網路發現規則。（例如，查找所有「配置文件」為「專用」的網路發現規則。）雙擊每個規則，然後打開「作用域」選項卡。在「遠程 IP 地址」下，選擇「任何 IP 地址」。

  在入站規則列表中，查找用於活動網路的所有「文件和列印機共享」規則。對於每個規則，雙擊該規則，將打開「作用域」選項卡。在「遠程 IP 地址」下，選擇「任何 IP 地址」。

  方法二：

  「控制面板」->「系統和安全」->「Windows防火牆」->"啟動或關閉Windows防火牆"->"關閉Windows防火牆"

• 設置目標計算機

  現在，你可以隨時在 Visual Studio 中通過主計算機設置目標計算機。

  在主計算機上，在 Visual Studio 的「Driver」菜單中，選擇「Test」>「Configure Deivce」。

  單擊「Add New Device」。

  在「Network host name」中輸入目標計算機的名稱。選擇「Provision Device and choose debugger setting」。

  選擇某種調試連接類型，並輸入所需的參數。

  設置過程將需要幾分鍾時間，並且可能會自動重新啟動目標計算機一到兩次。設置完成後，單擊「完成」。

• WDK 10 與 Microsoft Visual Studio 完全集成。你可以使用 Visual Studio 開發環境生成驅動程序，也可以使用 Microsoft Build Engine (MSBuild) 直接從命令行生成驅動程序。

  從 Windows 驅動程序工具包 (WDK) 8 開始，MSBuild 就已經取代了在早期版本的 WDK 中使用的 Windows 構建實用工具 (Build.exe)。現在，WDK 可使用與你用於構建 Visual Studio 項目相同的編譯器和構建工具。使用早期版本的 WDK 構建的驅動程序項目必須進行轉換才能在 Visual Studio 環境中工作。你可以從命令行運行轉換實用工具，也可以通過從現有的源創建新的 Visual Studio 項目來轉換現有驅動程序。

  構建驅動程序主要有以下兩種方式（選一即可）

• 方法一：使用 Visual Studio 構建驅動程序

  構建驅動程序的方法與在 Visual Studio 中構建任何項目或解決方案的方法相同。當使用 Windows 驅動程序模板創建新的驅動程序項目時，該模板定義默認（活動）的項目配置以及默認（活動）的解決方案生成配置。

  注意你可以將使用 WDK 8 或 Windows 驅動程序工具包 (WDK) 8.1 所創建的項目和解決方案轉換為適用於 Windows 驅動程序工具包 (WDK) 10 和 Visual Studio 2015。打開項目或解決方案前，請先運行 ProjectUpgradeTool。ProjectUpgradeTool 將轉換項目和解決方案，以便可以使用 WDK 10 構建它們。

• 1、確保安裝在你的計算機上的 SDK 和 WDK 的版本相同。

  2、在 Visual Studio 中打開驅動程序項目或解決方案。

  3、在「解決方案資源管理器」中右鍵單擊解決方案，並選擇「配置管理器」。

  4、從「配置管理器」中，選擇與你感興趣的構建類型相對應的活動解決方案配置（例如，「調試」或「發布」）以及活動解決方案平台（例如，「Win32」）。

  5、選擇要構建驅動程序的目標操作系統。導航到「驅動程序」>「常規」中的項目屬性，然後設置 TargetVersion 屬性。

  6、為驅動程序或驅動程序包配置項目屬性。 可以為部署、驅動程序簽署或其他任務設置屬性。

  7、從「構建」菜單中，單擊「構建解決方案」 (Ctrl+Shift+B)。

• 方法二：

  使用命令行構建驅動程序 (MSBuild)

  你可以使用「Visual Studio 命令提示符」窗口和 Microsoft Build Engine (MSBuild) 來從命令行構建驅動程序。

  使用「Visual Studio 命令提示符」窗口構建驅動程序

  打開「適用於 VS2015 的開發人員命令提示符」窗口。

  在此窗口中，你可以藉助 MSBuild.exe，通過指定項目 (.VcxProj) 或解決方案 (.Sln) 文件來構建任何 Visual Studio 項目。

  導航到項目目錄並為你的目標輸入 MSbuild 命令。

  例如，若要使用默認的平台和配置生成名為 MyDriver.vcxproj 的全新的 Visual Studio 驅動程序項目，請導航到項目目錄並輸入以下 MSBuild 命令：

  msbuild /t:clean /t:build .MyDriver.vcxproj

  語法 - 若要指定特定的配置和平台，請使用以下命令語法：

  msbuild /t:clean /t:build ProjectFile /p:Configuration=<Debug|Release> /p:Platform=architecture /p:TargetPlatformVersion=a.b.c.d /p:TargetVersion=OS

  例如，以下命令將為「調試」配置、「Win32」平台和 Windows 10 生成一個通用 Windows 驅動程序。

  msbuild /t:clean /t:build .MyDriver.vcxproj /p:Configuration="Debug" /p:Platform=Win32 /p:TargetVersion=」Windows10」 /p:TargetPlatformVersion=」10.0.10010.0」

  「TargetPlatformVersion」設置為可選項，並且允許你指定用於生成的工具包版本。默認值為使用最新的工具包。

• 使用 Visual Studio 中的選項增加構建輸出詳細信息的步驟

  1、單擊 Tools > Options。

  2、單擊「項目和解決方案」文件夾並單擊「生成並運行」。

  3、更改「MSBuild 項目構建輸出詳細信息」和「MSBuild 項目構建日誌文件詳細信息」。 默認情況下，這些都設置為「最少」。

Ⅱ WinCE 6.0系統啟動流程詳解

Windows CE6.0啟動過程分析
在Windows CE 6.0中，內核（Kenerl）和OEM代碼被分成oal.exe、kernel.dll和kitl.dll三個部分，其中啟動代碼（startup）和 OAL層的實現部分不再與內核鏈接生成NK.exe，取而代之的是啟動代碼（startup）和硬體相關且獨立於內核的OAL層的實現部分編譯成 oal.exe，而與內核相關且獨立於硬體的OAL層代碼包含在kernel.dll中；內核無關傳輸層（KITL）的支持代碼從OAL層分離出來編譯成 kitl.dll。
從表面上看，好像只是代碼重新組合了一下，從幫助 文檔中BSP的移植過程看好像也是這么一回事，實際上，整個Windows CE 6.0內核布局發生了很大的改變。Windows CE 6.0的啟動過程也是如此，如果你想按照Windows CE 5.0的啟動順序去分析Windows CE 6.0的啟動順序，可能會走到一個死胡同。主要是因為Windows CE 6.0在啟動過程中調用了kernel.dll和kitl.dll兩個動態鏈接庫的原因，而且Windows CE6.0不再編譯生成KernKitlProf.exe內核文件。
從Windows CE 6.0的幫助文檔可以看出，WinCE6.0的啟動只與oal.exe和kernel.dll有關，至於kitl.dll，只有將操作系統編譯成具有 KITL功能時才用到。分析Windows CE 6.0的啟動過程實際上找到編譯oal.exe和kernel.dll的源碼位置。
首先看一下將WinCE6.0編譯成諸如 WinCE5.0所說的基本內核情況，即kern.exe。對於oal.exe源碼位置比較容易找到，因為oal.exe是啟動代碼與硬體相關的OAL層 實現文件編譯而成，所以只需在BSP的OAL目錄中便能找到。而對於kernel.dll，在BSP目錄結構中，基本上無法找到kernel.dll的編 譯文件，所以必須從其他方面著手。
下面為WinCE 6.0的編譯日誌輸出文件：makeimg.out在文件復制過程的一部分：
Copying E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\oal.exe to E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\nk.exe for debugger Copying E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kern.dll to E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kernel.dll for debugger
從日誌輸出文件可以看出，在文件復制過程 中，WinCE6.0編譯器將oal.exe更名為nk.exe，而將kern.dll文件更名為kernel.dll，也就是說，kern.dll文件 的實現部分就是kernel.dll的實現體。根據前面的分析，oal.exe是與硬體相關獨立於內核的OAL層的實現部分，而kernel.dll為內 核相關獨立於硬體的OAL層的實現部分。同樣可以從最後整合後的二進制配置文件ce.bib文件中看出端倪。
; @CESYSGEN IF CE_MODULES_NK
nk.exe E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\oal.exe NK SHZ
kitl.dll E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kitl.dll NK SHZ
kernel.dll E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kern.dll NK SHZ
; @CESYSGEN ENDIF
而kern.dll動態庫在整個Windows CE6.0中沒有顯式編譯過程，即沒有一個sources文件有kern.dll的編譯過程，所以只能從操作系統的編譯文件Makefile中尋找其編譯 過程。下面看一下$(_PUBLICROOT)\common\CESYSGEN\makefile中的部分內容：
nk::$(NK_COMPONENTS) $(NK_REPLACE_COMPONENTS)
@ $(SG_INPUT_LIB)\oemstub.pdb $(SG_OUTPUT_OAKLIB)
@ $(SG_INPUT_LIB)\oemstub.lib $(SG_OUTPUT_OAKLIB)
set TARGETTYPE=DYNLINK
set TARGETNAME=kern
set RELEASETYPE=OAK
set DLLENTRY=NKStartup
set DEFFILE=NO_DEF_FILE
set TARGETLIBS=
set SOURCELIBS=%%NKLIBS%% $(SG_INPUT_LIB)\nkmain.lib $(SG_INPUT_LIB)\fulllibc.lib
$(MAKECMD) /NOLOGO NOLIBC=1 kern.dll
從上述代碼中可以發現，原來kern.dll動態庫是從oemstub.lib編譯而來，而且與nkmain.lib有關。
在理順了上述文件的相互之間的關系之後，再來分析Windows CE 6.0的啟動過程可能就比較容易啦。
在理清了上述文件的關系之後，便可以分析任意一款基於ARM微處理器的Windows CE 6.0的啟動過程，現在以深圳億道電子技術有限公司開發的基於PXA270 ARM開發平台為例，分析Windows CE 6.0操作系統啟動過程。
1、Startup函數：
從Windows CE 6.0的幫助文檔可以看出，WinCE6.0的啟動只與oal.exe和kernel.dll有關，至於kitl.dll，只有將操作系統編譯成具有 KITL功能時才用到。分析Windows CE 6.0的啟動過程實際上找到編譯oal.exe和kernel.dll的源碼位置。
oal.exe的通過Startup函數完成硬體 的初始化。Startup.s代碼與該硬體平台的Bootloader啟動代碼共用，其中PreInit函數主要完成將ARM處理器工作模式切換到管理員 模式、同時關閉MMU，並檢測系統啟動原因,如果是熱啟動、即在該函數調用之前已經啟動了Bootloader程序，相當基本硬體初始化已經完成，則直接 跳轉到OALStartUp函數中；否則需要進行硬體中斷屏蔽、內存、系統時鍾頻率、電源管理等硬體的基本初始化過程。（具體過程見代碼的分析）
$(_PLATFORMROOT)\xsbase270\src\common\Startup\Startup.s
LEAF_ENTRY StartUp
bl PreInit
tst r10, #RCSR_HARD_RESET
beq OALStartUp
tst r10, #RCSR_GPIO_RESET
bne Continue_StartUp
bl xlli_mem_init ;初始化內存控制器
ldr r0, =xlli_PMRCREGS_PHYSICAL_BASE;
ldr r0, [r0, #xlli_PSPR_offset];
mov r1, r10;
bl XllpPmValidateResumeFromSleep;
cmp r0, #0;
bne Failed_Sleep_Resume;
Sleep_Reset
ldr r0, =xlli_PMRCREGS_PHYSICAL_BASE;
ldr r0, [r0, #xlli_PSPR_offset];
mov r1, r10;
b XllpPmGoToContextRestoration;
Failed_Sleep_Resume
ldr r1, =xlli_RCSR_SMR
bic r10, r10, r1
Continue_StartUp
bl xlli_intr_init; ;初始化中斷控制器
bl EnableClks; ;使能內核時鍾(內存/OS定時器/FFART時鍾之需)
bl OALXScaleSetFrequencies ;設置系統頻率
bl xlli_mem_Topt
bl xlli_mem_restart ;復位內存，使其處於工作模式
bl xlli_ost_init ;初始化操作系統定時器
bl xlli_pwrmgr_init ;初始化電源管理
bl xlli_IMpwr_init ;初始化內部存儲器
b
ENTRY_END
2、OALStartUp函數：
在系統硬體初始化完畢之後，Startup調用 OALStartUp函數，OALStartUp函數主要完成將OEMAddressTable表傳遞給內核；然後調用KernelStart函數跳轉到 內核OEMAddressTable表的主要作用表的每一個入口都定義了一個內存中的物理位置、內存的大小以及映射這物理地址的靜態虛擬地址；
◆靜態虛擬內存地址被定義在緩沖存儲器的范圍之內；
◆內核可以創建非緩沖的內存地址指向到相同的物理地址；
◆對於同一物理地址，既有一個緩沖的虛擬內存地址，也有一個非緩沖的虛擬內存地址；
◆OEMAddressTable最後必須以0結尾；
◆對於MIPS和SHx類型的CPU，物理地址與虛擬地址的映射由CPU完成，無需創建OEMAddressTable
$(_PLATFORMROOT)\xsbase270\src\Inc\ Oemaddrtab_cfg.inc)：
$(_PLATFORMROOT)\xsbase270\src\oal\OalLib\Startup.s

3、KernelStart函數主要作用：
◆完成OEMAddressTable表中的物理地址到虛擬地址和虛擬地址到物理地址之間的映射；
◆對存儲器頁表和內核參數區存儲空間（RAM或DRAM）進行清零處理。
◆讀出CPU的ID號，內核需要根據該ID決定ARM的MMU處理，因為ARMV6和ARMV6之前的ARM處理器的MMU處理過程有所區別；
◆設置並開啟MMU和Cache，因為在Startup函數關閉MMU和Cache；
◆設置ARM處理器工作模式的SP指針，ARM處理器共用7種不同的工作模式 （USER、FIQ、IRQ、Supervisor、Abort、Undefined、System），除用戶模式(USER)和系統模式 （System）之外，其他5種工作模式都有具有特定的SP指針寄存器（ARM處理器稱其為影子寄存器）；
◆讀取內核啟動所需要的KDataStruct結構體；
◆調用ARMInit函數重新定位Windows CE內核參數pTOC和初始化OEMInitGlobals全局變數；
◆利用mov pc, r12指令跳轉到kernel.dll的入口位置，即NKStartup函數中。
$(_PRIVATEROOT)WINCEOS\COREOS\NK\LDR\ARM\armstart.s

4、ARMInit函數：
在ARMInit之前，系統仍無法使用全局變數， 因為系統的全局還在ROM區域，對於操作系統而言，出於安全考慮，只有XIP程序才有讀取ROM區域數據的權利，對於大部分Windows CE 操作系統，只有將數據拷貝到RAM區域後才能進行讀寫，ARMInit函數中通過調用KernelRelocate函數對pTOC全局變數重新定位，定位 之後，對內核啟動所需要的KDataStruct結構體進行初始化，其中OEMInitGlobals便是交換oal.exe和kernel.dll之間 的全局指針，ARMInit函數返回kernel.dll的入口位置。並在KernelStart函數最後利用mov pc, r12指令跳轉到kernel.dll的入口位置，即NKStartup函數中。
$(_PRIVATEROOT)WINCEOS\COREOS\NK\LDR\ARM\arminit.c

5、NKStartup函數：
硬體平台初始化完成後，oal.exe的啟動任務基本完成，餘下的啟動工作由內核相關且獨立於內核的OAL層實現體kernel.dll接管。kernel.dll主要作用：
◆從結構體參數KDataStruct * pKData提取內核啟動時所必須的全局變數，同時初始化內核全局變數；
◆定位對Windows CE 6.0特有的OEMGLOBAL結構體的初始化函數OEMInitGlobals地址，該結構體構建了內核和OAL層之間進行通信的橋梁。在 OEMGLOBAL結構體定義了OAL層所必須的函數，該結構體在oemglobal.c文件中被初始化，並被編譯在OEMMain.lib和 OEMMain_StaticKITL.lib兩個庫中，如果OAL鏈接這兩個庫，則必須要有該結構體中函數實現體；
◆通過調用ARMSetup設置物理地址和非緩沖的虛擬內存地址的映射、ARM中斷向量以及內核模式所需要的堆棧。
◆調用OEMInitDebugSerial函數初始化調試串口；
◆調用OEMInit進行平台初始化；
需要注意的時，NKStartup函數調用OEMInitDebugSerial和 OEMInit函數的過程與Windows CE 6.0之前的版本完全不同，這是因為在Windows CE 6.0以前的版本中，由於內核（kernel）、OAL和KITL編譯在一個可執行的文件中，它們之間的共享變數只需簡單利用extern關鍵字申明便可 相互之間進行訪問，而在Windows CE 6.0中，由於內核（kernel）、OAL和KITL被編譯成不同的可執行文件，變數之間的相互訪問無法使用extern關鍵字實現共享，即內核無法使 用extern DWORD varX方法訪問OAL層的變數varX，當然OAL層的實現體同樣無法通過同樣的方式訪問內核變數。為實現內核和OAL訪問共享信息，Windows CE 6.0定義了OEMGLOBAL和GLOBAL兩個結構體。
在 Windows CE 6.0的內核啟動時，OS找到OAL的入口位置，然後調用入口函數與全局塊進行指針交換，這樣內核才能使用OAL層中的信息，同樣OAL層才能訪問內核（kernel）導出的函數。
所以上述兩個函數的調用實際上通過OEMGLOBAL結構體實現的。實際調用位置為$(_PRIVATEROOT)\winceos\coreos \nk\oemstub\oemstub.c中的OEMInitDebugSerial和OEMInit，這兩個函數中通過OEMGLOBAL結構體指針 訪問OAL層中的OEMInitDebugSerial和OEMInit。
首先看一下將WinCE6.0編譯成諸如WinCE5.0所說的基本內核情況，即kern.exe。對於oal.exe源碼位置比較容易找到，因為 oal.exe是啟動代碼與硬體相關的OAL層實現文件編譯而成，所以只需在BSP的OAL目錄中便能找到。而對於kernel.dll，在BSP目錄結 構中，基本上無法找到kernel.dll的編譯文件，所以必須從其他方面著手。
調用KernelFindMemory()函數分割RAM區域，在Windows CE操作系統中，RAM空間主要分為存儲內存和程序內存，存儲內存主要為文件的存儲空間，包括內核文件和復制到系統中所有目標文件，程序內存為運行程序時所需要的存儲空間。

◆KernelStart ()啟動內核。
$(_PRIVATEROOT)\WINCEOS\COREOS\NK\KERNEL\ARM\mdarm.c
void NKStartup (struct KDataStruct * pKData)
{
。。。。
}
6、KernelSstart函數：
這里的KernelStart函數與前面的KernelStart函數的屬於兩個完全不 同的函數，NKStartup函數中調用的KernelStart函數為$(_PRIVATEROOT)\WINCEOS\COREOS\NK \KERNEL\ARM\armtrap.s文件中的KernelStart函數，主要完成調用內核初始化函數KernelInit，並跳轉到操作系統的 第一個啟動的任務。
LEAF_ENTRY KernelStart
ldr r4, =KData ; (r4) = ptr to KDataStruct
ldr r0, =APIRet
str r0, [r4, #pAPIReturn] ; set API return address
mov r1, #SVC_MODE
msr cpsr_c, r1 ; switch to Supervisor Mode w/IRQs enabled
CALL KernelInit ; initialize scheler, etc.
mov r0, #0 ; no current thread
mov r1, #ID_RESCHEDULE
b FirstSchele
ENTRY_END
7、KernelInit函數：
Windows CE 6.0的內核初始化函數同其他版本的內核初始化函數基本相近，主要完成在啟動第一個線程前對內核進行初始化，主要包括API函數集初始化、堆的初始化、初始化內存池、進程初始化、線程初始化和文件映射初始化等操作。
void KernelInit (void)
。。。{
}
8、FirstSchele：
FirstSchele函數為Windows CE操作系統啟動過程中最後無條件跳轉的一個函數，windows CE進行第一個調度，實際為一個空閑線程，因為windows CE系統還沒有完成啟動，只有當windows CE完全啟動並進入穩定狀態，然後啟動文件系統filesys.dll,設備管理device.dll,窗體圖像子系統gews.dll和shell程序 explore.exe。

Ⅲ 如何將文本文檔改為ini格式

直接把擴展名txt改成ini，ini文件也可以用文本文檔直接打開。
其實INI文件就是簡單的text文件，只不過這種txt文件要遵循一定的INI文件格式。現在的WINCE系統上也常常用INI文件作為配置文件。「.INI 」就是英文 「initialization」的頭三個字母的縮寫；當然INI file的後綴名也不一定是".ini"也可以是".cfg"，".conf 」或者是".txt"。
ini經典格式：

INI文件的格式很簡單，最基本的三個要素是：parameters，sections和comments。

什麼是parameters？

INI所包含的最基本的「元素」就是parameter；每一個parameter都有一個name和一個value，name和value是由等號「=」隔開。name在等號的左邊。

如：

name = value

什麼是sections ？

所有的parameters都是以sections為單位結合在一起的。所有的section名稱都是獨佔一行，並且sections名字都被方括弧包圍著（[ and ])。在section聲明後的所有parameters都是屬於該section。對於一個section沒有明顯的結束標志符，一個section的開始就是上一個section的結束，或者是end of the file。Sections一般情況下不能被nested，當然特殊情況下也可以實現sections的嵌套。

section如下所示：

[section]

什麼是comments ？

在INI文件中注釋語句是以分號「；」開始的。所有的所有的注釋語句不管多長都是獨佔一行直到結束的。在分號和行結束符之間的所有內容都是被忽略的。

注釋實例如下：

；comments text

當然，上面講的都是最經典的INI文件格式，隨著使用的需求INI文件的格式也出現了很多變種；

INI實例：

; last modified 1 April 2001 by John Doe
[owner]
name=John Doe
organization=Acme Procts

[database]
server=192.0.1.42 ; use IP address in case network name resolution is not working
port=142
file = "acme payroll.dat"

Ⅳ BSP(Board Support Packet)是什麼

BSP就是買開發板,開發板的生產商提供的一個資料和資源包

通常包括:

一 硬體相關:
1 開發板原理圖
2 開發板元件列表
3 介面定義
4 地址分布

二 軟體相關:
1 某些操作系統的bootloader及源代碼
2 某些操作系統裁剪好的映像文件(如linux系列可能有源碼,如WinCE可能有CEC文件)

三 服務相關
1 售後的技術支持(根據價格,差異很大)

但以上並非一定都有,根據生產商和晶元的不同,會有一定增減,建議按照自己的要求多比較

PS:這個問題其實不值那麼多懸賞,呵呵,你也不富裕

呵呵,消消火氣,這年頭都是不懂的面試懂的,習慣了就好,下回主動唬他們,問他們知道DD不(device driver)
^-^

Ⅳ 怎樣才能進入導航wince系統

步驟如下：
第一步：要先下載地圖軟體；

第二步：用電腦查找SD卡上原地圖文件中含埠與波特率的文件（一般為ini，txt後綴的文件），看一下是多少（例如：埠(COM)：1，波特率(BAUDRATE)：4800）。這個文件在不同的機器里是不一樣的文件名稱。你要仔細找，然後記下。

第三步：把下載好的地圖軟體通過電腦復制到SD卡上，替換原地圖。

第四步：打開新地圖文件中找到含埠與波特率的文件（一般為ini，txt後綴的文件），改成剛才記下的數據（例如：埠(COM)：1，波特率(BAUDRATE)：4800）。

第五步：在GPS中設置一下地圖的默認路徑,不同品牌型號的GPS默認路徑設置都是大同小異的。一種（如中恆MV770）在操作系統中依次進入「系統設置」---「文件管理」---「SDMMC」---，最後找到「*.EXE」的運行文件，將這個文件設置為GPS的默認路徑就可以了。另一種就是要找到系統的配置文件（一般為cfg，txt後綴的文件），把其中的路徑名改為你新地圖的路徑名保存（我用的是恆太gps，改MobileNavigator目錄下ConFig.txt文件，即把ConFig.txt里的路徑改為新的路徑即可）。

剩下的就是把SD卡插入機器，就完成了。

Ⅵ U盤的格式化系統FAT32和exFAT有什麼區別

U盤FAT32和exFAT的區別如下：

一、U盤文件系統類型的區別

1、FAT32 文件系統 FAT32使用4個位元組(也就是32位)的空間來表示每個扇區(Sector)配置文件的情形，故稱之為FAT32，其分區容量下限是 512MB，不同操作系統的上限不同，例如Win2000最大支持32GB FAT32分區，而WinXP最大可達2TB FAT32分區。

2、exFAT 文件系統 是Microsoft在Windows Embeded 5.0以上(包括Windows CE 5.0、6.0、 Windows Mobile5、6、6.1)中引入的一種適合於快閃記憶體的文件系統，為了解決FAT32等不支持4G及其更大的文件而推出。

二、可用4GB文件的區別

1、大多數優盤在租缺格式化時選用FAT32為默認文件系統，它最大優點就是在一個不超過8GB的分區中，FAT32分區格式的每個簇容量都固定為4KB，與前代相比可以大大地減少磁碟的浪費，提高磁碟利用率。

2、雖然對於最大分區容量的支持上面，FAT32 2TB最大分區的州型圓容量時至今日仍不過時，但FAT32無法傳輸並存放超過4GB容量的光碟ISO鏡像、高清視頻、各種圖形作品文件等等，這是其致命的弊端。

(6)wince配置文件擴展閱讀

exFAT的作用

exFAT的U盤不是很在意U盤的存取效能，那麼現在市面上4G、8G的MLC U盤可以說一點都不貴，這種容量對FAT32支持的單一分割最大容量（32GB）並不成問題，不過超過4GB的文件就有點麻煩。

雖然說很少有單一文件超過4GB的機會，但不代表完全沒有：如BD影片的Remux文件、BD/HD影片的原始文件、無損音樂愛好者的未壓縮音頻文件、DVD光碟的ISO文件、從DV上擷取下來的AVI文件等等，想要完整備份就得選擇NTFS或exFAT做為儲存格式。

exFAT原本設計的目的是在FAT32與NTFS之間取得一個折中，有FAT32的輕便、不需要耗損太多的效能及記憶體來處理文件運作，又有類似NTFS的CAL存取控制機制，以及類似HPFS系統可快速整理可用叢集空間的Free Space Bitmap，來將檔案破碎的情況盡量減少。

要真正比較出使用FAT32、NTFS及exFAT時冊塌的檔案破碎情況很難做到客觀的評比，剩下所能測試的就是存取效能了，尤其是exFAT最大的簇大小達到了驚人的32MB，連NTFS都只有64KB。

exFAT是適用於隨身碟或隨身型攜帶裝置（如PDA）的新格式，最早出現在2006年的WinCE 6.0，為了增進與桌面操作系統的相容性還有便於隨身裝置的同步需求，到了Vista SP1正式被納入桌面操作系統所支持的檔案系統，但跟一般玩家息息相關的，還是在於U盤上的應用。

參考資料來源：網路-exFAT

Ⅶ 新科魯茲原裝導航怎麼改成凱立德

將原廠導航更改為凱立德導航
已實現的效果：在副駕儲物箱插上U盤或SD卡，點擊導航圖標進入凱立德導航；拔出U盤或SD卡，點擊導航圖標進入原廠高德導航。不影響車機其它功能的使用
步驟
1、進入wince界面（原理不說了）
准備一張容量8G以上的SD卡或U盤，將Shincoupdate.exe文件拷貝至SD卡或U盤根目錄，重新上電，自動進入wince界面
2、拷貝地圖文件
在網上下載最新版的凱立德導航地圖，
點擊進入NaviOne文件夾，再進入NaviResFile文件夾，雙擊KLD_CfgDiy工具修改NaviConfig.dll文件，將音量更改為40-50之間，點擊右鍵保存，切記！不然會有驚喜（也可下載我改好的文件，直接覆蓋）音量在進入導航後可調整。
3、更改遠峰引導程序配置文件
在wince界面點擊My Device進入，點擊ResidentFlash2進入，發現YFAPP文件夾，點擊進入，發現index.ini配置文件，這個文件需要拷貝到電腦上更改。
若用的是SD卡將Path2更改為Path2=USB_SDNaviOneNaviOne.exe
若用的U盤將Path2更改為Path2=USB DiskNaviOneNaviOne.exe
因為Path9為原廠導航路徑，此處改Path1到Path8任何一個均可。
先把 ResidentFlash2YFAPP文件夾裡面index.ini文件刪除，將在電腦上改好的文件或者下載的改好的文件拷貝到這個文件夾裡面。
4、刪掉SD卡或U盤中的Shincoupdate.exe文件，重啟車機，點擊導航圖標，正常進入凱立德導航界面
點擊右上角音量小圖標，可以通過右下角的切換進入原車機主界面，正常進行播放音樂或收音機的操作。拔出U盤或SD卡，點擊車機主界面導航圖標，可進入原廠高德導航，不影響雙屏互動和實時路況的使用！