配置文件如何獲取資源的

❶ java 獲取配置文件路徑

讀取配置文件 , xxx.properties放在webroot/WEB-INF/classes/目錄下

首先將配置文件轉換成InputStream，有兩種方式，原理一樣，都是通過類載入器得到資源：

（1）InputStream inputStream = Thread.currentThread（）.getContextClassLoader（）.getResourceAsStream（"xx.properties"）；
(2) InputStream inputStream =
this.getClass() .getClassLoader().getResourceAsStream( "xx.properties" );
調用對象的getClass()方法是獲得對象當前的類類型，這部分數據存在方法區中，
而後在類類型上調用 getClassLoader()方法是得到當前類型的類載入器，我們知道在Java中所有的類都是通過載入器載入到虛擬機中的，而且類載入器之間存在父 子關系，就是子知道父，父不知道子，這樣不同的子載入的類型之間是無法訪問的（雖然它們都被放在方法區中），所以在這里通過當前類的載入器來載入資源也就 是保證是和類類型同一個載入器載入的。
最後調用了類載入器的getResourceAsStream()方法來載入資源。

(3) 然後載入配置文件，讀取屬性值
Properties prop = new Properties（）；
prop.load（input）；
String value = prop.getProperty("PropertyName");

input.close（）；

❷ Java讀取配置文件的幾種方法以及路徑問題

.類載入器讀取：
只能讀取classes或者類路徑中的任意資源，但是不適合讀取特別大的資源。
①獲取類載入器 ClassLoader cl = 類名.class.getClassLoader();
②調用類載入器對象的方法：public URL getResource(String name);
此方法查找具有給定名稱的資源，資源的搜索路徑是虛擬機的內置類載入器的路徑。
類 URL 代表一個統一資源定位符，它是指向互聯網」資源」的指針。
資源可以是簡單的文件或目錄，也可以是對更為復雜的對象的引用.
URL對象方法：public String getPath()，獲取此 URL 的路徑部分。
示例代碼：
2.類載入器讀取：
只能讀取classes或者類路徑中的任意資源，但是不適合讀取特別大的資源。
①獲取類載入器 ClassLoader cl = 類名.class.getClassLoader();
②調用類載入器對象的方法：public InputStream getResourceAsStream(String name);
返回讀取指定資源的輸入流。資源的搜索路徑是虛擬機的內置類載入器的路徑。

❸ Hadoop讀寫文件時內部工作機制是怎樣的

客戶端通過調用FileSystem對象（對應於HDFS文件系統，調用DistributedFileSystem對象）的open()方法來打開文件（也即圖中的第一步），DistributedFileSystem通過RPC（Remote Procere Call）調用詢問NameNode來得到此文件最開始幾個block的文件位置（第二步）。對每一個block來說，namenode返回擁有此block備份的所有namenode的地址信息（按集群的拓撲網路中與客戶端距離的遠近排序，關於在Hadoop集群中如何進行網路拓撲請看下面介紹）。如果客戶端本身就是一個datanode（如客戶端是一個maprece任務）並且此datanode本身就有所需文件block的話，客戶端便從本地讀取文件。

以上步驟完成後，DistributedFileSystem會返回一個FSDataInputStream（支持文件seek），客戶端可以從FSDataInputStream中讀取數據。FSDataInputStream包裝了一個DFSInputSteam類，用來處理namenode和datanode的I/O操作。

客戶端然後執行read()方法（第三步），DFSInputStream（已經存儲了欲讀取文件的開始幾個block的位置信息）連接到第一個datanode（也即最近的datanode）來獲取數據。通過重復調用read()方法（第四、第五步），文件內的數據就被流式的送到了客戶端。當讀到該block的末尾時，DFSInputStream就會關閉指向該block的流，轉而找到下一個block的位置信息然後重復調用read()方法繼續對該block的流式讀取。這些過程對於用戶來說都是透明的，在用戶看來這就是不間斷的流式讀取整個文件。

當真個文件讀取完畢時，客戶端調用FSDataInputSteam中的close（）方法關閉文件輸入流（第六步）。

如果在讀某個block是DFSInputStream檢測到錯誤，DFSInputSteam就會連接下一個datanode以獲取此block的其他備份，同時他會記錄下以前檢測到的壞掉的datanode以免以後再無用的重復讀取該datanode。DFSInputSteam也會檢查從datanode讀取來的數據的校驗和，如果發現有數據損壞，它會把壞掉的block報告給namenode同時重新讀取其他datanode上的其他block備份。

這種設計模式的一個好處是，文件讀取是遍布這個集群的datanode的，namenode只是提供文件block的位置信息，這些信息所需的帶寬是很少的，這樣便有效的避免了單點瓶頸問題從而可以更大的擴充集群的規模。

Hadoop中的網路拓撲

在Hadoop集群中如何衡量兩個節點的遠近呢？要知道，在高速處理數據時，數據處理速率的唯一限制因素就是數據在不同節點間的傳輸速度：這是由帶寬的可怕匱乏引起的。所以我們把帶寬作為衡量兩個節點距離大小的標准。

但是計算兩個節點之間的帶寬是比較復雜的，而且它需要在一個靜態的集群下才能衡量，但Hadoop集群一般是隨著數據處理的規模動態變化的（且兩兩節點直接相連的連接數是節點數的平方）。於是Hadoop使用了一個簡單的方法來衡量距離，它把集群內的網路表示成一個樹結構，兩個節點之間的距離就是他們離共同祖先節點的距離之和。樹一般按數據中心(datacenter)，機架(rack)，計算節點(datanode)的結構組織。計算節點上的本地運算速度最快，跨數據中心的計算速度最慢（現在跨數據中心的Hadoop集群用的還很少，一般都是在一個數據中心內做運算的）。

假如有個計算節點n1處在數據中心c1的機架r1上，它可以表示為/c1/r1/n1，下面是不同情況下兩個節點的距離：

• distance(/d1/r1/n1, /d1/r1/n1) = 0 (processes on the same node)

• distance(/d1/r1/n1, /d1/r1/n2) = 2 (different nodes on the same rack)

• distance(/d1/r1/n1, /d1/r2/n3) = 4 (nodes on different racks in the same data center)

• distance(/d1/r1/n1, /d2/r3/n4) = 6 (nodes in different data centers)

如下圖所示：

Hadoop

寫文件

現在我們來看一下Hadoop中的寫文件機制解析，通過寫文件機制我們可以更好的了解一下Hadoop中的一致性模型。

Hadoop

上圖為我們展示了一個創建一個新文件並向其中寫數據的例子。

首先客戶端通過DistributedFileSystem上的create()方法指明一個欲創建的文件的文件名（第一步），DistributedFileSystem再通過RPC調用向NameNode申請創建一個新文件（第二步，這時該文件還沒有分配相應的block）。namenode檢查是否有同名文件存在以及用戶是否有相應的創建許可權，如果檢查通過，namenode會為該文件創建一個新的記錄，否則的話文件創建失敗，客戶端得到一個IOException異常。DistributedFileSystem返回一個FSDataOutputStream以供客戶端寫入數據，與FSDataInputStream類似，FSDataOutputStream封裝了一個DFSOutputStream用於處理namenode與datanode之間的通信。

當客戶端開始寫數據時（第三步），DFSOutputStream把寫入的數據分成包（packet）, 放入一個中間隊列——數據隊列（data queue）中去。DataStreamer從數據隊列中取數據，同時向namenode申請一個新的block來存放它已經取得的數據。namenode選擇一系列合適的datanode（個數由文件的replica數決定）構成一個管道線（pipeline），這里我們假設replica為3，所以管道線中就有三個datanode。DataSteamer把數據流式的寫入到管道線中的第一個datanode中（第四步），第一個datanode再把接收到的數據轉到第二個datanode中（第四步），以此類推。

DFSOutputStream同時也維護著另一個中間隊列——確認隊列（ack queue），確認隊列中的包只有在得到管道線中所有的datanode的確認以後才會被移出確認隊列（第五步）。

如果某個datanode在寫數據的時候當掉了，下面這些對用戶透明的步驟會被執行：

1）管道線關閉，所有確認隊列上的數據會被挪到數據隊列的首部重新發送，這樣可以確保管道線中當掉的datanode下流的datanode不會因為當掉的datanode而丟失數據包。

2）在還在正常運行的datanode上的當前block上做一個標志，這樣當當掉的datanode重新啟動以後namenode就會知道該datanode上哪個block是剛才當機時殘留下的局部損壞block，從而可以把它刪掉。

3）已經當掉的datanode從管道線中被移除，未寫完的block的其他數據繼續被寫入到其他兩個還在正常運行的datanode中去，namenode知道這個block還處在under-replicated狀態（也即備份數不足的狀態）下，然後他會安排一個新的replica從而達到要求的備份數，後續的block寫入方法同前面正常時候一樣。

有可能管道線中的多個datanode當掉（雖然不太經常發生），但只要dfs.replication.min（默認為1）個replica被創建，我們就認為該創建成功了。剩餘的replica會在以後非同步創建以達到指定的replica數。

當客戶端完成寫數據後，它會調用close()方法（第六步）。這個操作會沖洗（flush）所有剩下的package到pipeline中，等待這些package確認成功，然後通知namenode寫入文件成功（第七步）。這時候namenode就知道該文件由哪些block組成（因為DataStreamer向namenode請求分配新block，namenode當然會知道它分配過哪些blcok給給定文件），它會等待最少的replica數被創建，然後成功返回。

replica是如何分布的

Hadoop在創建新文件時是如何選擇block的位置的呢，綜合來說，要考慮以下因素：帶寬（包括寫帶寬和讀帶寬）和數據安全性。如果我們把三個備份全部放在一個datanode上，雖然可以避免了寫帶寬的消耗，但幾乎沒有提供數據冗餘帶來的安全性，因為如果這個datanode當機，那麼這個文件的所有數據就全部丟失了。另一個極端情況是，如果把三個冗餘備份全部放在不同的機架，甚至數據中心裏面，雖然這樣數據會安全，但寫數據會消耗很多的帶寬。Hadoop 0.17.0給我們提供了一個默認replica分配策略（Hadoop 1.X以後允許replica策略是可插拔的，也就是你可以自己制定自己需要的replica分配策略）。replica的默認分配策略是把第一個備份放在與客戶端相同的datanode上（如果客戶端在集群外運行，就隨機選取一個datanode來存放第一個replica），第二個replica放在與第一個replica不同機架的一個隨機datanode上，第三個replica放在與第二個replica相同機架的隨機datanode上。如果replica數大於三，則隨後的replica在集群中隨機存放，Hadoop會盡量避免過多的replica存放在同一個機架上。選取replica的放置位置後，管道線的網路拓撲結構如下所示：

Hadoop

總體來說，上述默認的replica分配策略給了我們很好的可用性（blocks放置在兩個rack上，較為安全），寫帶寬優化（寫數據只需要跨越一個rack），讀帶寬優化（你可以從兩個機架中選擇較近的一個讀取）。

一致性模型

HDFS某些地方為了性能可能會不符合POSIX（是的，你沒有看錯，POSIX不僅僅只適用於linux/unix， Hadoop 使用了POSIX的設計來實現對文件系統文件流的讀取 ），所以它看起來可能與你所期望的不同，要注意。

創建了一個文件以後，它是可以在命名空間（namespace）中可以看到的：

Path p = new Path("p");

fs.create(p);

assertThat(fs.exists(p), is(true));

但是任何向此文件中寫入的數據並不能保證是可見的，即使你flush了已經寫入的數據，此文件的長度可能仍然為零：

Path p = new Path("p");

OutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.flush();

assertThat(fs.getFileStatus(p).getLen(), is(0L));

這是因為，在Hadoop中，只有滿一個block數據量的數據被寫入文件後，此文件中的內容才是可見的（即這些數據會被寫入到硬碟中去），所以當前正在寫的block中的內容總是不可見的。

Hadoop提供了一種強制使buffer中的內容沖洗到datanode的方法，那就是FSDataOutputStream的sync()方法。調用了sync()方法後，Hadoop保證所有已經被寫入的數據都被沖洗到了管道線中的datanode中，並且對所有讀者都可見了：

Path p = new Path("p");

FSDataOutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.flush();

out.sync();

assertThat(fs.getFileStatus(p).getLen(), is(((long) "content".length())));

這個方法就像POSIX中的fsync系統調用（它沖洗給定文件描述符中的所有緩沖數據到磁碟中）。例如，使用java API寫一個本地文件，我們可以保證在調用flush()和同步化後可以看到已寫入的內容：

FileOutputStream out = new FileOutputStream(localFile);

out.write("content".getBytes("UTF-8"));

out.flush(); // flush to operating system

out.getFD().sync(); // sync to disk （getFD()返回與該流所對應的文件描述符）

assertThat(localFile.length(), is(((long) "content".length())));

在HDFS中關閉一個流隱式的調用了sync()方法：

Path p = new Path("p");

OutputStream out = fs.create(p);

out.write("content".getBytes("UTF-8"));

out.close();

assertThat(fs.getFileStatus(p).getLen(), is(((long) "content".length())));

由於Hadoop中的一致性模型限制，如果我們不調用sync()方法的話，我們很可能會丟失多大一個block的數據。這是難以接受的，所以我們應該使用sync()方法來確保數據已經寫入磁碟。但頻繁調用sync()方法也是不好的，因為會造成很多額外開銷。我們可以再寫入一定量數據後調用sync()方法一次，至於這個具體的數據量大小就要根據你的應用程序而定了，在不影響你的應用程序的性能的情況下，這個數據量應越大越好。

❹ 用java 如何讀取配置文件（如：資源文件）中配

java讀取配置文件的幾種方法如下：
方式一：採用ServletContext讀取，讀取配置文件的realpath，然後通過文件流讀取出來。因為是用ServletContext讀取文件路徑，所以配置文件可以放入在web-info的classes目錄中，也可以在應用層級及web-info的目錄中。文件存放位置具體在eclipse工程中的表現是：可以放在src下面，也可放在web-info及webroot下面等。因為是讀取出路徑後，用文件流進行讀取的，所以可以讀取任意的配置文件包括xml和properties。缺點：不能在servlet外面應用讀取配置信息。
方式二：採用ResourceBundle類讀取配置信息，
優點是：可以以完全限定類名的方式載入資源後，直接的讀取出來，且可以在非Web應用中讀取資源文件。缺點：只能載入類classes下面的資源文件且只能讀取.properties文件。
方式三：採用ClassLoader方式進行讀取配置信息
優點是：可以在非Web應用中讀取配置資源信息，可以讀取任意的資源文件信息
缺點：只能載入類classes下面的資源文件。
方法4 getResouceAsStream
XmlParserHandler.class.getResourceAsStream 與classloader不同

使用的是當前類的相對路徑

❺ myeclipse做webservice開發,如何讀取配置文件中web.xml中設置的參數

想請問你的web.xml是否是你自已定義的xml文件

1.是的話，那很簡單。DOM或是SAX解析隨便找一種方法就好

2.不是，說明是你web的配置目錄，你可以在使用節點加一個
<init-param>
<param-name>firstparam</param-name>
<param-value>firstparamvalue</param-value>
</init-param>

然後在方法裡面獲得
<%
String Str1;
Str1=config.getInitParameter("firstparam");
Out.println(Str1);

%>
不知道能否幫到你^^
--------------------------------------
方法很多。csdn幫你看了下

在tomcat 的C:\Program Files\Apache Software Foundation\Tomcat 5.0\conf\Catalina\localhost 目錄下建立一個xml文件,文件名是你的應用的名字

類似於這樣:

<?xml version='1.0' encoding='utf-8'?>
<Context docBase="C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\sc114" path="/sc114" workDir="work\Catalina\localhost\sc114">
<Resource name="jdbc/UBSS_DS" type="javax.sql.DataSource"/>
<ResourceParams name="jdbc/UBSS_DS">
<parameter>
<name>maxWait </name>
<value>5000 </value>
</parameter>
<parameter>
<name>maxActive </name>
<value>4 </value>
</parameter>
<parameter>
<name>password </name>
<value>xunqin </value>
</parameter>
<parameter>
<name>url </name>
<value>jdbc:oracle:thin:@192.168.14.178:1521:orcl </value>
</parameter>
<parameter>
<name>driverClassName </name>
<value>oracle.jdbc.OracleDriver </value>
</parameter>
<parameter>
<name>maxIdle </name>
<value>2 </value>
</parameter>
<parameter>
<name>username </name>
<value>xunqin </value>
</parameter>
</ResourceParams>

</Context>

//web.xml 裡面映射資源

<resource-ref>
<description>DB Connection </description>
<res-ref-name>jdbc/UBSS_DS </res-ref-name>
<res-type>javax.sql.DataSource </res-type>
<res-auth>Container </res-auth>
</resource-ref>

程序裡面這樣訪問:

try{
DataSource ds = null;
InitialContext ctx=new InitialContext();
ds=(DataSource)ctx.lookup("java:comp/env/jdbc/UBSS_DS");
Connection conn = ds.getConnection();
//這里拿到了connection對象後,你想幹啥就幹啥吧
}catch(Exception e){
System.out.println("**********");
e.printStackTrace();

return null;
}

//tomcat不同的版本 配置可能稍有不同,有的配置在server.xml裡面,自己去研究下,網上多的一大把

❻ pb的配置文件如何應用

每次系統登陸，把當前登陸的用戶、密碼保存到配置文件，不管自動的還是手動的，都保存。
open的時候：
if now() < time'09:00:00' then
//取配置文件里的用戶、密碼
//登陸
//用戶、密碼保存配置文件。（當然，自動登陸保存配置文件可以不做，只手動做）
end if從用途方面分析，PB包含兩種配置文件。分別是源碼配置文件和鏡像配置文件。
一、源碼配置文件
源碼配置文件用於編譯源碼時使用。這里的源碼是指Windows
CE公開的源碼，如驅動程序、系統應用程序等。PB在編譯平台時將這些公開的源碼即時編譯並將編譯鏈接後的文件復制到平台工程子目錄里。記得前面講過PB在開始編譯時調用cebuild.bat批處理文件，cebuild.bat執行的一個步驟是針對_DEPTREES變數指定的所有目錄執行build.exe和sysgen.bat。build.exe在編譯源碼文件時會尋找當前目錄下存放的源碼配置文件，根據配置文件的信息來編譯和鏈接，產生EXE、DLL、LIB文件。CE的源碼文件所在的目錄中都包含了相應的配置文件，這些配置文件只對當前目錄或者子目錄的源碼有效，具體分為三種：

DIRS文件：文件內容和解釋如下：
DIRS：指定哪個子目錄的源碼要被編譯
DIRS_CE：只有為CE編寫的源碼才被編譯
OPTIONAL_DIRS：指定可選的目錄（很少使用這個選項），可以只編譯指定目錄而不是全部編譯。

SOURCES文件：通過宏定義來指定編譯和鏈接涉及到的文件，文件內容和解釋如下：
TARGETNAME：指定編譯鏈接產生的主文件名
TARGETTYPE：指定編譯鏈接產生的文件的類型（決定了擴展名）。文件共分三種：.lib（LIBRARY）和.dll（DYNLINK）和.exe（PROGRAM）。
TARGETLIBS：定義.lib鏈接文件，鏈接時需要這個文件。
SOURCES：源碼文件。包含擴展名為*.c或*.h
或*.cpp的文件。
EXEENTRY：.exe文件的執行代碼入口點。
sources.cmn文件是通用的SOURCES文件。在這個文件中可以指定作用於所有源碼文件的配置選項。

MAKEFILE文件：包含默認的編譯和鏈接選項
整個編譯和鏈接過程：build.exe收集編譯和鏈接需要的數據（源碼文件、鏈接文件、編譯和鏈接選項）產生一系列的內部環境變數，然後調用nmake.exe，nmake.exe根據內部環境變數執行編譯、鏈接，最後產生最終文件（*.lib
*.exe *.dll）。
二、鏡像配置文件：
鏡像配置文件用於在製作CE鏡像文件時使用。CE的鏡像文件擴展名為.bin。製作鏡像工具romimage.exe除了能夠產生.bin文件外，還能夠產生.abx和.sre文件。整個鏡像的製作過程由makeimg.exe控制，它調用cenlscmp.exe、fmerge.exe、res2.exe、txt2ucde.exe、regcomp.exe、romimage.exe等。這些工具大部分在前面已經介紹過了。鏡像配置文件類型有.bib、.reg、.db、.dat、.str。如果主文件名為Common，表示是通用的配置文件。如果主文件名為Platform，表示是某一個BSP的配置文件。如果主文件名是Project，表示是定製的一個平台的配置文件。在PB中修改配置文件前如果沒有把握最好先做好備份。
.bib（Binary image builder）

定義包含在內核鏡像中的文件和模塊的名稱、載入位置。主要的bib文件有Common.bib,Config.bib, Project.bib,
Platform.bib等。.bib文件內部分為幾個部分：
【MEMORY】用於定義有效的物理內存塊，在此將整個RAM分為幾個部分。
格式： 名稱 首地址 大小 內存類型
名稱： 內存區域的唯一名稱（RESERVE是預定義名稱，可以用多次，表示此區域保留）
首地址： 內存區域的首地址（十六進製表示）
大小： 內存區域的大小（十六進製表示）
內存類型：分為三種。
RAM： 運行所有進程的內存區域（整個區域必須是連續的，且不能含空洞）
RAMIMAGE：專用於保存鏡像的內存區域。（每個.bin中只能指定一個RAMIMAGE）
RESERVED：保留內存區域（這樣的區域一般用於驅動程序使用，如顯卡緩沖區、DMA緩沖區）
舉例：
;名稱 首地址 大小 內存類型
IF IMGRAM64
NK 80220000 009E0000 RAMIMAGE
RAM 80C00000 03000000 RAM
UMABUF 83C00000 00400000 RESERVED
ENDIF

註：整個內核的地址都是從0x8000 0000開始的。如果是x86系列的CPU，那麼物理內存地址與虛擬地址映射關系在oeminit.asm中指定。
【CONFIG】類似環境變數，PB預設置了一些配置變數。常用的配置及說明如下：
AUTOSIZE：
格式：AUTOSIZE = OFF | ON

默認值為OFF。在config.bib中的MEMORY部分定義了有效的內存區域，其中兩部分RAM、RAMIMAGE分別用於進程使用區域和保存鏡像區域。如果為ON，romimage.exe在創建nk.bin時將RAM和RAMIMAGE兩部分合並成一個部分，然後從最低地址開始保留RAMIMAGE大小的內存，其餘都作為RAM使用。
BOOTJUMP：
格式：BOOTJUMP = address | NONE

默認值為NONE。每次重新啟動CE內核，默認執行的代碼從RAMIMAGE的首地址開始。如果在BOOTJUMP指定一個地址（必須在RAMIMAGE范圍內），那麼將從指定的地址開始執行。
COMPRESSION：
格式：COMPRESSION = OFF | ON

默認值為ON。romimage.exe在創建內核時默認壓縮所有可寫部分。對於文件，默認全部壓縮。對於模塊（.exe、.dll），默認壓縮可寫部分。模塊的可寫部分包括數據段，也就是在模塊運行時一定載入到內存中的部分。如果模塊在.bib中定義時具有C屬性（表明壓縮模塊所有部分），那麼當前這個選項就忽略了。
FSRAMPERCENT：
格式：FSRAMPERCENT = number

默認值為0x80808080。指定為文件系統分配的內存的百分比。number分為四個位元組，由十六進製表示。
byte0的值（單位為4KB）表示在第一個2MB中，其中每1MB包含的4KB的整數倍。
byte1的值（單位為4KB）表示在第二個2MB中，其中每1MB包含的4KB的整數倍。
byte2的值（單位為4KB）表示在第三個2MB中，其中每1MB包含的4KB的整數倍。
byte3的值（單位為4KB）表示在剩下的內存中，每1MB包含的4KB的整數倍。

計算一下默認值0x80808080表示的百分比：0x80*4K/1M = 0.5，因為每個位元組都等於0.5，所以整個佔用的百分比是50%。
KERNELFIXUPS：
格式：KERNELFIXUPS = OFF | ON

默認值為ON。如果為ON，romimage.exe創建內核前重定位內核到RAM的開始位置。
OUTPUT：
格式：OUTPUT = path

指定romimaeg.exe將創建完成的內核文件nk.bin放置到的路徑。一般放置到%_FLATRELEASEDIR%下。
ROMFLAGS
格式：ROMFLAGS = Flags

設置內核選項的位掩碼，多個位掩碼可以組合使用。

0x0001 禁止按需分頁：EXE和DLL默認是按需分頁的。

0x0002
禁止全內核模式：進程運行在兩種模式下，用戶模式和內核模式。全內核模式下所有線程運行在內核模式。全內核模式能夠提高執行效率，但會增加系統的不穩定性。如果允許執行用戶程序，那麼不適合採用全內核模式。

0x00000010
只信任來自ROM的模塊（DLL、EXE）。默認ROM中的模塊和所有文件系統的模塊都是內核信任的。OEM能夠在OAL層實現對所有運行模塊的檢查，這個標志將忽略對來自ROM保存的模塊的檢查。

0x00000020 停止刷新TLB。這個標志僅用於運行在x86CPU上的內核。TLB（Translation Look-aside
Buffer），有人翻譯成變換索引緩沖區，它的作用是在虛擬地址和物理地址之間轉換。對於具有實時性的內核，這個標志應該設置。

0x00000040 按照/base鏈接選項中的地址載入DLL。這樣內核將不採用重定位載入DLL。不建議採用。
ROMSIZE
格式：ROMSIZE = size

指定內核鏡像的大小
ROMSTART
格式：ROMSTART = address

指定內核鏡像的首地址
ROMWIDTH
格式：ROMWIDTH = width

指定數據寬度，一般為32位
ROMOFFSET
格式：ROMOFFSET = address

指定偏移地址。
SRE
格式：SRE = OFF | ON

指定romimage.exe是否產生.src文件，一般燒錄ROM的程序能夠識別此文件。

註：config中絕大多數【CONFIG】選項不需要修改。凡是配置文件都可以使用IF/ENDIF
條件語句。
【MODULES】定義鏡像要包含的模塊並指定模塊（DLL、EXE）如何被載入到內存表中。
格式：模塊名稱 路徑 內存塊 類型

模塊名稱一般為模塊的真實名稱；路徑為當前文件所處的位置（路徑中指定的文件名和前面模塊名稱最好一致）；內存塊是指這個模塊將被存放到哪個內存塊中，內存塊的定義見前面MEMORY部分；類型指定這個模塊將被存放的屬性，具體類型如下：

S：系統文件

H：隱藏文件

R：只壓縮模塊的資源部分（默認模塊是不壓縮的）

C：壓縮模塊所有部分

D：禁止調試

N：標志模塊是非信任的

P：忽略CPU類型

K：指定romimage.exe修正模塊（僅用於調試或者內核跟蹤）

X：指定romimage.exe對