配置文件如何获取资源的

❶ 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对