⑴ wince6.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函數中；否則需要進行硬體中斷屏蔽、內存、系統時鍾頻率、電源管理等硬體的基本初始化過程。（具體過程見代碼的分析）
⑵ 我在dos下使用devenv.exe編譯MFC解決方案sln程序時，生成的日誌文件提示生成cmd.exe時出錯，
可以更詳細一點嗎？
那個不叫Dos，叫控制台窗口。
⑶ 如何把數據寫入日誌里（python）
#coding=utf-8
def
initlog():
import
logging
#
生成一個日誌對象
logger
=
logging.getLogger()
#
生成一個Handler。logging支持許多Handler，
#
象FileHandler,
SocketHandler,
SMTPHandler等，我由於要寫
#
文件就使用了FileHandler。
#
logfile是一個全局變數，它就是一個文件名，如：'crawl.log'
logfile
=
'test.log'
hdlr
=
logging.FileHandler(logfile)
#
成一個格式器，用於規范日誌的輸出格式。如果沒有這行代碼，那麼預設的
#
格式就是："%(message)s"。也就是寫日誌時，信息是什麼日誌中就是什麼，
#
沒有日期，沒有信息級別等信息。logging支持許多種替換值，詳細請看
#
Formatter的文檔說明。這里有三項：時間，信息級別，日誌信息
formatter
=
logging.Formatter('%(asctime)s
%(levelname)s
%(message)s')
#
將格式器設置到處理器上
hdlr.setFormatter(formatter)
#
將處理器加到日誌對象上
logger.addHandler(hdlr)
#
設置日誌信息輸出的級別。logging提供多種級別的日誌信息，如：NOTSET,
#
DEBUG,
INFO,
WARNING,
ERROR,
CRITICAL等。每個級別都對應一個數值。
#
如果不執行此句，預設為30(WARNING)。可以執行：logging.getLevelName
#
(logger.getEffectiveLevel())來查看預設的日誌級別。日誌對象對於不同
#
的級別信息提供不同的函數進行輸出，如：info(),
error(),
debug()等。當
#
寫入日誌時，小於指定級別的信息將被忽略。因此為了輸出想要的日誌級別一定
#
要設置好此參數。這里我設為NOTSET（值為0），也就是想輸出所有信息
logger.setLevel(logging.NOTSET)
return
logger
logging=initlog()
logging.info(u'注冊')
⑷ Windows下怎麼獲取並保存g++的編譯日誌
g++ 編譯參數 > 日誌文件.log
⑸ openwrt編譯之後，編譯過程生成的log文件在哪個目錄下
編譯後生成一個EXE啊,還有一些像OBJ格式的文件,那些都是中間文件,真正用的到的就是那個EXE文件
⑹ 請問用visual studio編譯solution工程文件的時候，會產生編譯時的日誌嗎放在哪裡
當然有了
visual studio6.0 在工程目錄里會產生一個.plg文件
visual studio2005和2005會在Debug或Release目錄里產生一個.htm文件
⑺ 我寫了個VB6.0的程序，我想用VB調用G++編譯程序並輸出日誌文件，可是一直不行怎麼辦
看著有點暈，建議你把完整的字元串賦值給一個變數，然後MsgBox看一下有沒問題，
或者復制出來，在dos窗口裡手工運行看下先，
⑻ linux編譯的時候怎麼保存日誌啊，就比如g++ test.cpp，怎麼編譯完了查看日誌
敲
g++ test.cpp > log
然後就會在編譯的目錄下多出一個log文件，你用文本編輯器打開就可以看了
⑼ 如何實現log4cxx日誌輸出方式
Log4cxx是開放源代碼項目Apache Logging Service的子項目之一，用於為C++程序提供日誌功能，以便開發者對目標程序進行調試
和審計。本文對log4cxx的使用及配置進行介紹，並給出一個可以快速開始的實例。最後，針對日誌服務給出一些實踐方面的建議。
1. 介紹
Log4cxx是開放源代碼項目Apache Logging Service的子項目之一，是Java社區著名的log4j的c++移植版，用於為C++程序提供日誌
功能，以便開發者對目標程序進行調試和審計。
有關log4cxx的更多信息可以從Apache Loggin Service的網站http://logging.apache.org獲得。當前的穩定版本為0.9.7，本文內
容及示例代碼都是基於此版本。此外，示例代碼的編譯環境為Windows環境中的Microsoft Visual C++ .Net 2003。
本文的示例代碼可以在此下載，其中也包含了預編譯好的log4cxx的庫文件。
2. 集成log4cxx到IDE
要使用log4cxx，首先需要將其集成到你的項目開發環境中。以下針對Windows環境中的Microsoft Visual C++ .Net 2003進行說明
，其他環境的配置信息請參考官方文檔。
要讓log4cxx為你工作，通常情況下需要如下幾個步驟：
l 獲取軟體包：得到log4xx的源代碼；
l 編譯：構建庫文件；
l 項目環境設置：加入log4cxx支持。
2.1 獲取軟體包
請從官方網站獲得合適的版本。也可以從下面這個鏈接中直接獲取（直接的鏈接地址可能不會永遠有效）：
http://mirror.vmmatrix.net/apache/logging/log4cxx/log4cxx-0.9.7.tar.gz
下載完成後解壓縮到合適的目錄中，因為我們在下一步中需要使用軟體包，包括編譯和復制必要的文件。
2.2 編譯
原始發行包中不含編譯後的代碼，這個工作需要我們自己來做。打開你的IDE，並載入以下目錄中的工程：
l Msvc\static：該工程產生log4cxx的靜態鏈接庫（lib4cxx.lib和lib4cxxs.lib）；
l Msvc\dll：該工程產生log4cxx的動態鏈接庫（lib4cxx.dll）。
通常情況下，工程都可以順利編譯通過。查看輸出目錄，把這些生成的庫文件找出來，以便在下一步驟中使用。
2.3 項目環境設置
請先在IDE中打開一個需要加入日誌功能的工程，或者出於實驗目的，新建一個工程，以便對其進行設置。
首先需要設置log4cxx的include文件。這些文件位於log4cxx軟體包的include\log4cxx目錄內。請查看你的VC++ IDE中「工具->選
項->項目->VC++目錄->包含文件」所列出的內容，以便確定你以何種方式加入這些include文件：
l 將include\log4cxx直接拷貝到已定義的包含文件目錄中。如果將log4cxx看作是一項系統服務的話，這樣做是胡合乎情理
的，因為你可以採用標准庫的方式使用它，例如：#include <log4cxx/logger.h>
l 增加一個包含路徑，以指向位於IDE外部的某一文件目錄。可以簡單的指向在2.1中解壓縮後形成的log4cxx軟體包目錄。
下一步需要對2.2節產生的log4cxx庫進行設置。這取決於你使用該庫的方式：靜態鏈接或者動態鏈接。
l 靜態鏈接情況下需要做如下工作：為預編譯器定義LOG4CXX_STATIC宏，設置位置為「項目->屬性->配置屬性->C/C++->預
處理器->預處理器定義」；為鏈接器指定依賴的庫lib4cxxs.lib和Ws2_32.lib，設置位置為「項目->屬性->配置屬性->鏈接器->輸
入->附加依賴項」。
l 動態鏈接情況下只需要為鏈接器指定依賴的庫lib4cxxs.lib即可，設置方式同上。
3. 示例代碼
本節展示了一個最簡單的log4cxx示例，以便你可以快速的了解它。
該示例在功能上創建了一個日誌服務，該日誌可通過配置文件進行必要控制，並可以同時向文件和控制台輸出信息。
在實現上，我們採用了一個簡單的控制台程序，並使用動態鏈接庫的方式使用log4cxx。
要實現這個目標，請按如下步驟進行：
1）創建一個名為logdemo的空白win32控制台工程，並按照2.3節所述內容對其進行設置。注意，這里我們使用動態連介面的方式。
2）在logdemo.cpp中加入實現日誌功能的代碼。完成後的代碼清單如下：
#include "stdafx.h"
#include <log4cxx/logger.h>
#include <log4cxx/propertyconfigurator.h>
using namespace log4cxx;
int _tmain(int argc, _TCHAR* argv[])
{
//載入log4cxx的配置文件，這里使用了屬性文件
PropertyConfigurator::configure("log4cxx.properties");
//獲得一個Logger，這里使用了RootLogger
LoggerPtr rootLogger = Logger::getRootLogger();
//發出INFO級別的輸出請求
LOG4CXX_INFO(rootLogger, _T("它的確工作了"));
//rootLogger->info(_T("它的確工作了")); //與上面那句話功能相當
return 0;
}
以Debug方式編譯工程，調試程序直到成功為止。
3）新建一個文本文件，命名為log4cxx.properties，並鍵入如下內容：
# 設置root logger為DEBUG級別，使用了ca和fa兩個Appender
log4j.rootLogger=DEBUG, ca, fa
4）復制log4cxx.dll到輸出目錄。在動態鏈接方式下，應用程序需要能夠找到這個庫文件。
5）運行生成的logdemo.exe文件，查看一下運行結果，看看我們工作有沒有取得成效。如果一切順利，無論是在控制台還是在輸出
文件中，都應該能看到類似下面那樣的輸出內容：
2006-06-02 16:09:50,609 [2528] INFO root - 它的確工作了
4. 體系結構
4.1 核心類
Log4cxx有三個關鍵組件，它們是loggers, appenders和layouts。
Logger是log4cxx的核心類，只要執行日誌操作；looger有層次結構，最頂層為RootLogger；logger是有級別的。每個logger可以附
加多個Appender。Appender代表了日誌輸出的目標，如輸出到文件、控制台等等。對於每一種appender，都可以通過layout進行格
式設置。
這三類組件用示意圖表示如下（不代表類關系）：
（TODO：在此對三種組件分別進行說明）
4.2 配置類
此外在使用中還會用到的類有BasicConfigurator、PropertyConfigurator和DOMConfigurator等，用於對log4cxx進行配置。其中：
BasicConfigurator提供了一種簡單配置，包括使用ConsoleAppder作為root appender和PatternLayout作為預設布局。
PropertyConfigurator使用properties文件作為配置方式。
DOMConfigurator則使用properties文件作為配置方式。
（TODO：在此對配置內容進行說明）
5. 實踐指導
在項目中是否使用日誌，以及如何使用日誌，對開發者來說都是一個需要做出的技術選擇，這通常會牽扯到系統的性能，使用日誌
的目的等問題。我們使用日誌的方式，有些是這個行業積累了多年的經驗，有些則純粹關乎個人的喜好。
1）何時使用日誌
通常情況下，日誌的作用在於調試和審計，如果你的項目對此有特殊需求，即可考慮使用日誌。
對於調試，通常用於IDE調試器無法達到的地方。一些常見的場景包括：
分布式組件的調試。在伺服器端的組件，需要通過客戶端的調用來驗證其工作是否正確，此時利用日誌的輸出作為輔助工具對錯誤
進行診斷。
鏈接庫調試。在無法跟蹤進外部庫中的情況下，這種方法非常有效。
生產環境下的調試。生產環境通常是指產品在客戶處處於正式運行的狀態，在出現問題時，開發者常常不在現場，藉助日誌的輸出
進行錯誤判斷就是一個非常有效的手段。
對於審計應用，則需要視特定的情況而定，程序級的記錄能力，無疑可以作為業務級審計手段的有效補充。
無論是在哪種場景下，log4cxx都是可以勝任工作的，這取決於它的靈活的配置能力及多種類型的輸出方式。
2）性能問題
關閉日誌，通過配置文件設置日誌的關閉和打開
使用宏代替logger的輸出命令
選擇性輸出日誌。建立logger的層次結構，根據級別選擇性輸出
輸出目標。盡可能減少輸出目標
選擇合適的輸出格式。使用SimpleLayout將達到與std::cout相當的速度。
3）其它
使用類的全限定名對logger命名
6. 結論
Log4cxx具有的一些顯著特性使得C++者可以將其放入自己的工具箱中，這些特性包括靈活的配置能力，多種輸出手段，豐富的格式
控制，出色的性能。如果在你的開發中需要藉助於日誌進行調試和審計，你也許需要log4cxx。最後，重要的一點是，如你所見，
log4cxx的使用是如此的簡單。