1． 关于动态加载机制??
学习Java比C++更容易理解OOP的思想，毕竟C++还混合了不少面向过程的成分。很多人都能背出来Java语言的特点，所谓的动态加载机制等等。当然概念往往是先记住而后消化的，可有多少人真正去体会过动态加载的机制，试图去寻找过其中的细节呢? 提供大家一个方法：
在命令行窗口运行Java程序的时候，加上这个很有用的参数：

java -verbose *.class

这样会清晰的打印出被加载的类文件，大部分是jdk自身运行需要的，最后几行会明显的看到自己用到的那几个类文件被加载进来的顺序。即使你声明了一个类对象，不实例化也不会加载，说明只有真正用到那个类的实例即对象的时候，才会执行加载。这样是不是大家稍微能明白一点动态加载了呢？^_^

2． 关于寻找class文件原理??
建议大家在入门的时候在命令行窗口编译和运行，不要借助JCreator或者Eclipse等IDE去帮助做那些事情。尝试自己这样做：
javac -classpath yourpath *.java
java -classpath yourpath *.class
也许很多人都能看懂，设置classpath的目的就是告诉编译器去哪里寻找你的class文件. 不过至少笔者今日才弄懂JVM去查询类的原理，编译器加载类要依靠classloader，而classloader有3个级别，从高到低分别是BootClassLoader(名字可能不准确) , ExtClassLoader, AppClassLoader.

这3个加载器分别对应着编译器去寻找类文件的优先级别和不同的路径：BootClassLoader对应jre/classes路径，是编译器最优先寻找class的地方
ExtClassLoader对应jre/lib/ext路径，是编译器次优先寻找class的地方
AppClassLoader对应当前路径，所以也是编译器默认找class的地方

其实大家可以自己写个程序简单的测试，对任何class，例如A,
调用new A().getClass().getClassLoader().toString() 打印出来就可以看到，把class文件放在不同的路径下再次执行，就会看到区别。特别注意的是如果打印出来是null就表示到了最高级 BootClassLoader, 因为它是C++编写的，不存在Java对应的类加载器的名字。

寻找的顺序是一种向上迂回的思想，即如果本级别找不到，就只能去本级别之上的找，不会向下寻找。不过似乎从Jdk1.4到Jdk1.6这一特点又有改变，没有找到详细资料。所以就不举例子了。告诉大家设计这种体系的是Sun公司曾经的技术核心宫力先生，一个纯种华人哦！^_^

这样希望大家不至于迷惑为什么总报错找不到类文件，不管是自己写的还是导入的第三方的jar文件（J2ee中经常需要导入的）。

3． 关于jdk和jre??
大家肯定在安装JDK的时候会有选择是否安装单独的jre，一般都会一起安装，我也建议大家这样做。因为这样更能帮助大家弄清楚它们的区别：

Jre 是java runtime environment, 是java程序的运行环境。既然是运行，当然要包含jvm，也就是大家熟悉的虚拟机啦，还有所有java类库的class文件，都在lib目录下打包成了jar。大家可以自己验证。至于在windows上的虚拟机是哪个文件呢？学过MFC的都知道什么是dll文件吧，那么大家看看jre/bin/client里面是不是有一个jvm.dll呢？那就是虚拟机。

Jdk 是java development kit，是java的开发工具包，里面包含了各种类库和工具。当然也包括了另外一个Jre. 那么为什么要包括另外一个Jre呢？而且jdk/jre/bin同时有client和server两个文件夹下都包含一个jvm.dll。说明是有两个虚拟机的。这一点不知道大家是否注意到了呢？

相信大家都知道jdk的bin下有各种java程序需要用到的命令，与jre的bin目录最明显的区别就是jdk下才有javac，这一点很好理解，因为 jre只是一个运行环境而已。与开发无关，正因为如此，具备开发功能的jdk自己的jre下才会同时有client性质的jvm和server性质的 jvm， 而仅仅作为运行环境的jre下只需要client性质的jvm.dll就够了。

记得在环境变量path中设置jdk/bin路径麽？这应该是大家学习Java的第一步吧，老师会告诉大家不设置的话javac和java是用不了的。确实jdk/bin目录下包含了所有的命令。可是有没有人想过我们用的java命令并不是 jdk/bin目录下的而是jre/bin目录下的呢？不信可以做一个实验，大家可以把jdk/bin目录下的java.exe剪切到别的地方再运行 java程序，发现了什么？一切OK！

那么有人会问了？我明明没有设置jre/bin目录到环境变量中啊？

试想一下如果java为了提供给大多数人使用，他们是不需要jdk做开发的，只需要jre能让java程序跑起来就可以了，那么每个客户还需要手动去设置环境变量多麻烦啊？所以安装jre的时候安装程序自动帮你把jre的java.exe添加到了系统变量中，验证的方法很简单，大家看到了系统环境变量的 path最前面有“%SystemRoot%\system32;%SystemRoot%;”这样的配置，那么再去Windows/system32下面去看看吧，发现了什么？有一个java.exe。

如果强行能够把jdk/bin挪到system32变量前面，当然也可以迫使使用jdk/jre里面的java，不过除非有必要，我不建议大家这么做。使用单独的jre跑java程序也算是客户环境下的一种测试。

这下大家应该更清楚jdk和jre内部的一些联系和区别了吧？

PS: 其实还有满多感想可以总结的，一次写多了怕大家扔砖头砸死我，怪我太罗唆。大家应该更加踏实更加务实的去做一些研究并互相分享心得，大方向和太前沿的技术讨论是必要的但最好不要太多，毕竟自己基础都还没打好，什么都讲最新版本其实是进步的一大障碍！

Java 学习杂谈（二）
鉴于上回写的一点感想大家不嫌弃，都鼓励小弟继续写下去，好不容易等到国庆黄金周，实习总算有一个休息的阶段，于是这就开始写第二篇了。希望这次写的仍然对志同道合的朋友们有所帮助。上回讲了Java动态加载机制、classLoader原理和关于jdk和jre三个问题。这次延续着讲一些具体的类库??

1． 关于集合框架类
相信学过Java的各位对这个名词并不陌生，对 java.util.*这个package肯定也不陌生。不知道大家查询API的时候怎么去审视或者分析其中的一个package，每个包最重要的两个部分就是interfaces和classes，接口代表了它能做什么，实现类则代表了它如何去做。关注实现类之前，我们应该先理解清楚它的来源接口，不管在j2se还是j2ee中，都应该是这样。那么我们先看这三个接口：List、Set、Map。
也许有些人不太熟悉这三个名字，但相信大部分人都熟悉ArrayList，LinkedList，TreeSet，HashSet，HashMap， Hashtable等实现类的名字。它们的区别也是满容易理解的，List放可以重复的对象集合，Set放不可重复的对象组合，而Map则放 <Key,Value > 这样的名值对， Key不可重复，Value可以。这里有几个容易混淆的问题：

到底Vector和ArrayList，Hashtable和HashMap有什么区别？
很多面试官喜欢问这个问题，其实更专业一点应该这样问：新集合框架和旧集合框架有哪些区别？新集合框架大家可以在这些包中找since jdk1.2的，之前的如vector和Hashtable都是旧的集合框架包括的类。那么区别是？
a. 新集合框架的命名更加科学合理。例如List下的ArrayList和LinkedList
b. 新集合框架下全部都是非线程安全的。建议去jdk里面包含的源代码里面自己去亲自看看vector和ArrayList的区别吧。当然如果是jdk5.0之后的会比较难看一点，因为又加入了泛型的语法，类似c++的template语法。

那么大家是否想过为什么要从旧集合框架默认全部加锁防止多线程访问更新到新集合框架全部取消锁，默认方式支持多线程？(当然需要的时候可以使用collections的静态方法加锁达到线程安全)
笔者的观点是任何技术的发展都未必是遵循它们的初衷的，很多重大改变是受到客观环境的影响的。大家知道Java的初衷是为什么而开发的麽？是为嵌入式程序开发的。记得上一篇讲到classLoader机制麽？那正是为了节约嵌入式开发环境下内存而设计的。而走到今天，Java成了人们心中为互联网诞生的语言。互联网意味着什么？多线程是必然的趋势。客观环境在变，Java技术也随着飞速发展，导致越来越脱离它的初衷。据说Sun公司其实主打的是J2se，结果又是由于客观环境影响，J2se几乎遗忘，留在大家谈论焦点的一直是j2ee。

技术的细节这里就不多说了，只有用了才能真正理解。解释这些正是为了帮助大家理解正在学的和将要学的任何技术。之后讲j2ee的时候还会再讨论。
多扯句题外话：几十年前的IT巨人是IBM，Mainframe市场无人可比。微软如何打败IBM？正是由于硬件飞速发展，对个人PC的需求这个客观环境，让微软通过OS称为了第二个巨人。下一个打败微软的呢？Google。如何做到的？如果微软并不和IBM争大型机，Google借着互联网飞速发展这个客观环境作为决定性因素，避开跟微软争OS，而是走搜索引擎这条路，称为第3个巨人。那么第4个巨人是谁呢？很多专家预言将在亚洲或者中国出现， Whatever，客观环境变化趋势才是决定大方向的关键。当然笔者也希望会出现在中国，^_^~~

2． 关于Java设计模式
身边的很多在看GOF的23种设计模式，似乎学习它无论在学校还是在职场，都成了一种流行风气。我不想列举解释这23种Design Pattern， 我写这些的初衷一直都是谈自己的经历和看法，希望能帮助大家理解。
首先我觉得设计模式只是对一类问题的一种通用解决办法，只要是面向对象的编程预言都可以用得上这23种。理解它们最好的方法就是亲自去写每一种，哪怕是一个简单的应用就足够了。如果代码实现也记不住的话，记忆它们对应的UML图会是一个比较好的办法，当然前提是必须了解UML。
同时最好能利用Java自身的类库帮助记忆，例如比较常用的观察者模式，在java.util.*有现成的Observer接口和Observable这个实现类，看看源代码相信就足够理解观察者模式了。再比如装饰器模式，大家只要写几个关于java.io.*的程序就可以完全理解什么是装饰器模式了。有很多人觉得刚入门的时候不该接触设计模式，比如图灵设计丛书系列很出名的那本《Java设计模式》，作者: Steven John Metsker，大部分例子老实说令现在的我也很迷惑。但我仍然不同意入门跟学习设计模式有任何冲突，只是我们需要知道每种模式的概念的和典型的应用，这样我们在第一次编写 FileOutputStream、BufferedReader、PrintWriter的时候就能感觉到原来设计模式离我们如此之近，而且并不是多么神秘的东西。

另外，在学习某些模式的同时，反而更能帮助我们理解java类库的某些特点。例如当你编写原型(Prototype)模式的时候，你必须了解的是 java.lang.Cloneable这个接口和所有类的基类Object的clone()这个方法。即深copy和浅copy的区别：
Object.clone()默认实现的是浅copy，也就是复制一份对象拷贝，但如果对象包含其他对象的引用，不会复制引用，所以原对象和拷贝共用那个引用的对象。
深copy当然就是包括对象的引用都一起复制啦。这样原对象和拷贝对象，都分别拥有一份引用对象。如果要实现深copy就必须首先实现 java.lang.Cloneable接口，然后重写clone()方法。因为在Object中的clone()方法是protected签名的，而 Cloneable接口的作用就是把protected放大到public，这样clone()才能被重写。

那么又有个问题了？如果引用的对象又引用了其他对象呢？这样一直判断并复制下去，是不是显得很麻烦？曾经有位前辈告诉我的方法是重写clone方法的时候直接把原对象序列化到磁盘上再反序列化回来，这样不用判断就可以得到一个深copy的结果。如果大家不了解序列化的作法建议看一看 ObjectOutputStream和ObjectInputStream

归根结底，模式只是思想上的东西，把它当成前人总结的经验其实一点都不为过。鼓励大家动手自己去写，例如代理模式，可以简单的写一个Child类， Adult类。Child要买任何东西由Adult来代理实现。简单来说就是Adult里的buy()内部实际调用的是Child的buy()，可是暴露在main函数的却是Adult.buy()。这样一个简单的程序就足够理解代理模式的基本含义了。

Java 杂谈（三）
这已经笔者写的第三篇Java杂记了，庆幸前两篇一直得到论坛朋友们的支持鼓励，还望大家继续指正不足之处。笔者也一直渴望通过这样方式清醒的自审，来寻找自己技术上的不足之处，希望和共同爱好Java的同仁们一起提高。
前两次分别讲述了关于jvm、jdk、jre、collection、classLoader和一些Design Pattern的自我理解。这次仍然不准备开始过渡到j2ee中，因为觉得还有一些琐碎的j2se的问题没有总结完毕。

1． 关于Object类理解
大家都知道Object是所有Java类的基类， 意味着所有的Java类都会继承了Object的11个方法。建议大家去看看Object的 11个成员函数的源代码，就会知道默认的实现方式。比如equals方法，默认实现就是用"=="来比较，即直接比较内存地址，返回true 或者 false。而toString()方法，返回的串组成方式是??
"getClass().getName() + "@" + Integer.toHexString(hashCode())"
其实不用我过多的解释，大家都能看懂这个串的组成。接下来再看看hashCode()：
public native int hashCode()；

由于是native方法，跟OS的处理方式相关，源代码里仅仅有一个声明罢了。我们有兴趣的话完全可以去深究它的hashCode到底是由OS怎么样产生的呢？但笔者建议最重要的还是先记住使用它的几条原则吧！首先如果equals()方法相同的对象具有相通的hashCode，但equals ()对象不相通的时候并不保证hashCode()方法返回不同的整数。而且下一次运行同一个程序，同一个对象未必还是当初的那个hashCode() 哦。
其余的方法呢？nofigy()、notifyAll()、clone()、wait()都是native方法的，说明依赖于操作系统的实现。最后一个有趣的方法是finalize()，类似C++的析构函数，签名是protected，证明只有继承扩展了才能使用，方法体是空的，默示什么也不做。它的作用据笔者的了解仅仅是通知JVM此对象不再使用，随时可以被销毁，而实际的销毁权还是在于虚拟机手上。那么它真的什么也不做麽？未必，实际上如果是线程对象它会导致在一定范围内该线程的优先级别提高，导致更快的被销毁来节约内存提高性能。其实从常理来说，我们也可以大概这样猜测出jvm做法的目的。

2． 关于重载hashCode()与Collection框架的关系
笔者曾经听一位搞Java培训多年的前辈说在他看来hashCode方法没有任何意义，仅仅是为了配合证明具有同样的hashCode会导致equals 方法相等而存在的。连有的前辈都犯这样的错误，其实说明它还是满容易被忽略的。那么hashCode()方法到底做什么用？

学过数据结构的课程大家都会知道有一种结构叫hash table，目的是通过给每个对象分配一个唯一的索引来提高查询的效率。那么Java也不会肆意扭曲改变这个概念，所以hashCode唯一的作用就是为支持数据结构中的哈希表结构而存在的，换句话说，也就是只有用到集合框架的 Hashtable、HashMap、HashSet的时候，才需要重载hashCode()方法，
这样才能使得我们能人为的去控制在哈希结构中索引是否相等。笔者举一个例子：
曾经为了写一个求解类程序，需要随机列出1,2,3,4组成的不同排列组合，所以笔者写了一个数组类用int[]来存组合结果，然后把随机产生的组合加入一个HashSet中，就是想利用HashSet不包括重复元素的特点。可是HashSet怎么判断是不是重复的元素呢？当然是通过 hashCode()返回的结果是否相等来判断啦，可做一下这个实验：
int[] A = {1,2,3,4};
int[] B = {1,2,3,4};
System.out.println(A.hashCode());
System.out.println(B.hashCode());

这明明是同一种组合，却是不同的hashCode，加入Set的时候会被当成不同的对象。这个时候我们就需要自己来重写hashCode()方法了，如何写呢？其实也是基于原始的hashCode()，毕竟那是操作系统的实现， 找到相通对象唯一的标识，实现方式很多，笔者的实现方式是：
首先重写了toString()方法:
return A[0]“+” A[1]“+” A[2]“+” A[3]; //显示上比较直观
然后利用toString()来计算hashCode()：
return this.toString().hashCode()；
这样上述A和B返回的就都是”1234”，在测试toString().hashCode()，由于String在内存中的副本是一样的，”1234”.hashCode()返回的一定是相同的结果。

说到这，相信大家能理解得比我更好，今后千万不要再误解hashCode()方法的作用。

3． 关于Class类的成员函数与Java反射机制
很早刚接触Java就听很多老师说过Java的动态运行时机制、反射机制等。确实它们都是Java的显著特点，运行时加载笔者在第一篇介绍过了，现在想讲讲反射机制。在Java中，主要是通过java.lang包中的Class类和Method类来实现内存反射机制的。
熟悉C++的人一定知道下面这样在C++中是做不到的：运行时以字符串参数传递一个类名，就可以得到这个类的所有信息，包括它所有的方法，和方法的详细信息。还可以实例化一个对象，并通过查到的方法名来调用该对象的任何方法。这是因为Java的类在内存中除了C++中也有的静态动态数据区之外，还包括一份对类自身的描述，也正是通过这描述中的信息，才能帮助我们才运行时读取里面的内容，得到需要加载目标类的所有信息，从而实现反射机制。大家有没有想过当我们需要得到一个JavaBean的实例的时候，怎么知道它有哪些属性呢？再明显简单不过的例子就是自己写一个JavaBean的解析器：

a. 通过Class.forName(“Bean的类名”)得到Class对象，例如叫ABeanClass
b. 通过ABeanClass的getMethods()方法，得到Method[]对象
c. 按照规范所有get方法名后的单词就代表着该Bean的一个属性
d. 当已经知道一个方法名，可以调用newInstance()得到一个实例，然后通过invoke()方法将方法的名字和方法需要用的参数传递进去，就可以动态调用此方法。

当然还有更复杂的应用，这里就不赘述，大家可以参考Class类和Method类的方法。

4． 坦言Synchronize的本质
Synchronize大家都知道是同步、加锁的意思，其实它的本质远没有大家想得那么复杂。声明Synchronize的方法被调用的时候，锁其实是加载对象上，当然如果是静态类则是加在类上的锁，调用结束锁被解除。它的实现原理很简单，仅仅是不让第二把锁再次被加在同一个对象或类上，仅此而已。一个简单的例子足以说明问题：
class A{
synchronized void f(){}
void g(){}
}

当A的一个对象a被第一个线程调用其f()方法的时候，第二个线程不能调用a的synchronized方法例如f()，因为那是在试图在对象上加第二把锁。但调用g()却是可以的，因为并没有在同一对象上加两把锁的行为产生。
这样大家能理解了麽？明白它的原理能更好的帮助大家设计同步机制，不要滥用加锁。

PS：下篇笔者计划开始对J2ee接触到的各个方面来进行总结，谈谈自己的经验和想法。希望大家还能一如既往的支持笔者写下去，指正不足之处。

Java杂谈（四）

不知不觉已经写到第四篇了，论坛里面不断的有朋友鼓励我写下去。坚持自己的作风，把一切迷惑不容易理清楚的知识讲出来，讲到大家都能听懂，那么自己就真的懂了。最近在公司实习的时候Trainer跟我讲了很多经典事迹，对还未毕业的我来说是笔不小的财富，我自己的信念是：人在逆境中成长的速度要远远快过顺境中，这样来看一切都能欣然接受了。
好了，闲话不说了，第三篇讲的是反射机制集合框架之类的，这次打算讲讲自己对反序列化和多线程的理解。希望能对大家学习Java起到帮助??

1．关于序列化和反序列化
应该大家都大概知道Java中序列化和反序列化的意思，序列化就是把一个Java对象转换成二进制进行磁盘上传输或者网络流的传输，反序列化的意思就是把这个接受到的二进制流重新组装成原来的对象逆过程。它们在Java中分别是通过ObjectInputStream和 ObjectInputStream这两个类来实现的（以下分别用ois和oos来简称）。

oos的writeObject()方法用来执行序列化的过程，ois的readObject()用来执行反序列化的过程，在传输二进制流之前，需要讲这两个高层流对象连接到同一个Channel上，这个Channel可以是磁盘文件，也可以是socket底层流。所以无论用哪种方式，底层流对象都是以构造函数参数的形式传递进oos和ois这两个高层流，连接完毕了才可以进行二进制数据传输的。例子：
可以是文件流通道
file = new File(“C:/data.dat”);
oos = new ObjectOutputStream(new FileOutputStream(file));
ois = new ObjectInputStream(new FileInputStream(file));

或者网络流通道
oos = new ObjectOutputStream(socket.getOutputStream());
ois = new ObjectInputStream(socket.getInputStream());

不知道大家是否注意到oos总是在ois之前定义，这里不希望大家误解这个顺序是固定的么？回答是否定的，那么有顺序要求么？回答是肯定的。原则是什么呢？
原则是互相对接的输入/输出流之间必须是output流先初始化然后再input流初始化，否则就会抛异常。大家肯定会问为什么？只要稍微看一看这两个类的源代码文件就大概知道了，output流的任务很简单，只要把对象转换成二进制往通道中写就可以了，但input流需要做很多准备工作来接受并最终重组这个Object，所以ObjectInputStream的构造函数中就需要用到output初始化发送过来的header信息，这个方法叫做 readStreamHeader()，它将会去读两个Short值用于决定用多大的缓存来存放通道发送过来的二进制流，这个缓存的size因jre的版本不同是不一样的。所以output如果不先初始化，input的构造函数首先就无法正确运行。

对于上面两个例子，第一个顺序是严格的，第二个因为oos和ois连接的已经不是对方了，而是socket另外一端的流，需要严格按照另外一方对接的output流先于对接的input流打开才能顺利运行。

这个writeObject和readObject本身就是线程安全的，传输过程中是不允许被并发访问的。所以对象能一个一个接连不断的传过来，有很多人在运行的时候会碰到EOFException, 然后百思不得其解，去各种论坛问解决方案。其实笔者这里想说，这个异常不是必须声明的，也就是说它虽然是异常，但其实是正常运行结束的标志。EOF表示读到了文件尾，发送结束自然连接也就断开了。如果这影响到了你程序的正确性的话，请各位静下心来看看自己程序的业务逻辑，而不要把注意力狭隘的聚集在发送和接受的方法上。因为笔者也被这样的bug困扰了1整天，被很多论坛的帖子误解了很多次最后得出的教训。如果在while循环中去readObject，本质上是没有问题的，有对象数据来就会读，没有就自动阻塞。那么抛出EOFException一定是因为连接断了还在继续read，什么原因导致连接断了呢？一定是业务逻辑哪里存在错误，比如NullPoint、 ClassCaseException、ArrayOutofBound，即使程序较大也没关系，最多只要单步调适一次就能很快发现bug并且解决它。

难怪一位程序大师说过：解决问题90％靠经验，5％靠技术，剩下5％靠运气！真是金玉良言，笔者大概查阅过不下30篇讨论在while循环中使用 readObject抛出EOFExceptionde 的帖子，大家都盲目的去关注解释这个名词、反序列化的行为或反对这样写而没有一个人认为EOF是正确的行为，它其实很老实的在做它的事情。为什么大家都忽略了真正出错误的地方呢？两个字，经验！

2．关于Java的多线程编程
关于Java的线程，初学或者接触不深的大概也能知道一些基本概念，同时又会很迷惑线程到底是怎么回事？如果有人认为自己已经懂了不妨来回答下面的问题：
a. A对象实现Runnable接口，A.start()运行后所谓的线程对象是谁？是A么？
b. 线程的wait()、notify()方法到底是做什么时候用的，什么时候用？
c. 为什么线程的suspend方法会被标注过时，不推荐再使用，线程还能挂起么？
d. 为了同步我们会对线程方法声明Synchronized来加锁在对象上，那么如果父类的f()方法加了Synchronized，子类重写f()方法必须也加Synchronized么？如果子类的f()方法重写时声明Synchronized并调用super.f()，那么子类对象上到底有几把锁呢？会因为竞争产生死锁么？

呵呵，各位能回答上来几道呢？如果这些都能答上来，说明对线程的概念还是满清晰的，虽说还远远不能算精通。笔者这里一一做回答，碍于篇幅的原因，笔者尽量说得简介一点，如果大家有疑惑的欢迎一起讨论。

首先第一点，线程跟对象完全是两回事，虽然我们也常说线程对象。但当你用run()和start()来启动一个线程之后，线程其实跟这个继承了 Thread或实现了Runnable的对象已经没有关系了，对象只能算内存中可用资源而对象的方法只能算内存正文区可以执行的代码段而已。既然是资源和代码段，另外一个线程当然也可以去访问，main函数执行就至少会启动两个线程，一个我们称之为主线程，还一个是垃圾收集器的线程，主线程结束就意味着程序结束，可垃圾收集器线程很可能正在工作。

第二点，wait()和sleep()类似，都是让线程处于阻塞状态暂停一段时间，不同之处在于wait会释放当前线程占有的所有的锁，而 sleep不会。我们知道获得锁的唯一方法是进入了Synchronized保护代码段，所以大家会发现只有Synchronized方法中才会出现 wait，直接写会给警告没有获得当前对象的锁。所以notify跟wait配合使用，notify会重新把锁还给阻塞的线程重而使其继续执行，当有多个对象wait了，notify不能确定唤醒哪一个，必经锁只有一把，所以一般用notifyAll()来让它们自己根据优先级等竞争那唯一的一把锁，竞争到的线程执行，其他线程只要继续wait。

从前Java允许在一个线程之外把线程挂起，即调用suspend方法，这样的操作是极不安全的。根据面向对象的思想每个对象必须对自己的行为负责，而对自己的权力进行封装。如果任何外步对象都能使线程被挂起而阻塞的话，程序往往会出现混乱导致崩溃，所以这样的方法自然是被毙掉了啦。

最后一个问题比较有意思，首先回答的是子类重写f()方法可以加Synchronized也可以不加，如果加了而且还内部调用了super.f ()的话理论上是应该对同一对象加两把锁的，因为每次调用Synchronized方法都要加一把，调用子类的f首先就加了一把，进入方法内部调用父类的 f又要加一把，加两把不是互斥的么？那么调父类f加锁不就必须永远等待已经加的锁释放而造成死锁么？实际上是不会的，这个机制叫重进入，当父类的f方法试图在本对象上再加一把锁的时候，因为当前线程拥有这个对象的锁，也可以理解为开启它的钥匙，所以同一个线程在同一对象上还没释放之前加第二次锁是不会出问题的，这个锁其实根本就没有加，它有了钥匙，不管加几把还是可以进入锁保护的代码段，畅通无阻，所以叫重进入，我们可以简单认为第二把锁没有加上去。

总而言之，Synchronized的本质是不让其他线程在同一对象上再加一把锁。

Java杂谈（五）

本来预计J2se只讲了第四篇就收尾了，可是版主厚爱把帖子置顶长期让大家浏览让小弟倍感责任重大，务必追求最到更好，所以关于J2se一些没有提到的部分，决定再写几篇把常用的部分经验全部写出来供大家讨论切磋。这一篇准备讲一讲Xml解析包和Java Swing，然后下一篇再讲java.security包关于Java沙箱安全机制和RMI机制，再进入J2ee的部分，暂时就做这样的计划了。如果由于实习繁忙更新稍微慢了一些，希望各位见谅！

1． Java关于XML的解析
相信大家对XML都不陌生，含义是可扩展标记语言。本身它也就是一个数据的载体以树状表现形式出现。后来慢慢的数据变成了信息，区别是信息可以包括可变的状态从而针对程序硬编码的做法变革为针对统一接口硬编码而可变状态作为信息进入了XML中存储。这样改变状态实现扩展的唯一工作是在XML中添加一段文本信息就可以了，代码不需要改动也不需要重新编译。这个灵活性是XML诞生时候谁也没想到的。

当然，如果接口要能提取XML中配置的信息就需要程序能解析规范的XML文件，Java中当然要提高包对这个行为进行有利支持。笔者打算讲到的两个包是 org.w3c.dom和javax.xml.parsers和。（大家可以浏览一下这些包中间的接口和类定义）

Javax.xml.parsers包很简单，没有接口，两个工厂配两个解析器。显然解析XML是有两种方式的：DOM解析和SAX解析。本质上并没有谁好谁不好，只是实现的思想不一样罢了。给一个XML文件的例子：
<?xml version=”1.0” encoding=”UTF-8” >
<root >
<child name=”Kitty” >
A Cat
</child >
</root >

所谓DOM解析的思路是把整个树状图存入内存中，需要那个节点只需要在树上搜索就可以读到节点的属性，内容等，这样的好处是所有节点皆在内存可以反复搜索重复使用，缺点是需要消耗相应的内存空间。

自然SAX解析的思路就是为了克服DOM的缺点，以事件触发为基本思路，顺序的搜索下来，碰到了Element之前触发什么事件，碰到之后做什么动作。由于需要自己来写触发事件的处理方案，所以需要借助另外一个自定义的Handler，处于org.xml.sax.helpers包中。它的优点当然是不用整个包都读入内存，缺点也是只能顺序搜索，走完一遍就得重来。

大家很容易就能猜到，接触到的J2ee框架用的是哪一种，显然是DOM。因为类似Struts，Hibernate框架配置文件毕竟是很小的一部分配置信息，而且需要频繁搜索来读取，当然会采用DOM方式（其实SAX内部也是用DOM采用的结构来存储节点信息的）。现在无论用什么框架，还真难发现使用 SAX来解析XML的技术了，如果哪位仁兄知道，请让笔者也学习学习。

既然解析方式有了，那么就需要有解析的存储位置。不知道大家是否发现org.w3c.dom这个包是没有实现类全部都是接口的。这里笔者想说一下Java 如何对XML解析是Jdk应该考虑的事，是它的责任。而w3c组织是维护定义XML标准的组织，所以一个XML结构是怎么样的由w3c说了算，它不关心 Java如何去实现，于是乎规定了所有XML存储的结构应该遵循的规则，这就是org.w3c.dom里全部的接口目的所在。在笔者看来，简单理解接口的概念就是实现者必须遵守的原则。

整个XML对应的结构叫Document、子元素对应的叫做Element、还有节点相关的Node、NodeList、Text、Entity、 CharacterData、CDATASection等接口，它们都可以在XML的语法中间找到相对应的含义。由于这里不是讲解XML基本语法，就不多介绍了。如果大家感兴趣，笔者也可以专门写一篇关于XML的语法规则帖与大家分享一下。

2． Java Swing
Swing是一个让人又爱又恨的东西，可爱之处在于上手很容易，较AWT比起来Swing提供的界面功能更加强大，可恨之处在于编复杂的界面工作量实在是巨大。笔者写过超过3000行的Swing界面，感觉用户体验还不是那么优秀。最近又写过超过6000行的，由于功能模块多了，整体效果还只是一般般。体会最深的就一个字：累! 所以大家现在都陆续不怎么用Swing在真正开发的项目上了，太多界面技术可以取代它了。笔者去写也是迫于无奈组里面大家都没写过，我不入地域谁入？

尽管Swing慢慢的在被人忽略，特别是随着B/S慢慢的在淹没C/S，笔者倒是很愿意站出来为Swing正身。每一项技术的掌握绝不是为了流行时尚跟风。真正喜欢Java的朋友们还是应该好好体会一下Swing，相信在校的很多学生也很多在学习它。很可能从Jdk 1.1、1.2走过来的很多大学老师可能是最不熟悉它的。
Swing提供了一组轻组件统称为JComponent，它们与AWT组件的最大区别是JComponent全部都是Container，而 Container的特点是里面可以装载别的组件。在Swing组件中无论是JButton、JLabel、JPanel、JList等都可以再装入任何其他组件。好处是程序员可以对Swing组件实现“再开发”，针对特定需求构建自己的按钮、标签、画板、列表之类的特定组件。

有轻自然就有重，那么轻组件和重组件区别是？重组件表现出来的形态因操作系统不同而异，轻组件是Swing自己提供GUI，在跨平台的时候最大程度的保持一致。
那么在编程的时候要注意一些什么呢？笔者谈谈自己的几点经验：

a. 明确一个概念，只有Frame组件才可以单独显示的，也许有人会说JOptionPane里面的静态方法就实现了单独窗口出现，但追寻源代码会发现其实现实出来的Dialog也需要依托一个Frame窗体，如果没有指定就会默认产生一个然后装载这个Dialog显示出来。

b. JFrame是由这么几部分组成：
最底下一层JRootPane，上面是glassPane (一个JPanel)和layeredPane (一个JLayeredPane)，而layeredPane又由contentPane(一个JPanel)和menuBar构成。我们的组件都是加在 contentPane上，而背景图片只能加在layeredPane上面。至于glassPane是一个透明的覆盖了contentPane的一层，在特定效果中将被利用到来记录鼠标坐标或掩饰组件。

c. 为了增强用户体验，我们会在一些按钮上添加快捷键，但Swing里面通常只能识别键盘的Alt键，要加入其他的快捷键，必须自己实现一个ActionListener。

d. 通过setLayout(null)可以使得所有组件以setBounds()的四个参数来精确定位各自的大小、位置，但不推荐使用，因为好的编程风格不应该在Swing代码中硬编码具体数字，所有的数字应该以常数的形式统一存在一个静态无实例资源类文件中。这个静态无实例类统一负责Swing界面的风格，包括字体和颜色都应该包括进去。

e. 好的界面设计有一条Golden Rule: 用户不用任何手册通过少数尝试就能学会使用软件。所以尽量把按钮以菜单的形式（不管是右键菜单还是窗体自带顶部菜单）呈现给顾客，除非是频繁点击的按钮才有必要直接呈现在界面中。

其实Swing的功能是相当强大的，只是现在应用不广泛，专门去研究大概是要花不少时间的。笔者在各网站论坛浏览关于Swing的技巧文章还是比较可信的，自己所学非常有限，各人体会对Swing各个组件的掌握就是一个实践积累的过程。笔者只用到过以上这些，所以只能谈谈部分想法，还望大家见谅！

Java杂谈（六）

这篇是笔者打算写的J2se部分的最后一篇了，这篇结束之后，再写J2ee部分，不知道是否还合适写在这个版块？大家可以给点意见，谢谢大家对小弟这么鼓励一路写完前六篇Java杂谈的J2se部分。最后这篇打算谈一谈Java中的RMI机制和JVM沙箱安全框架。

1． Java中的RMI机制
RMI的全称是远程方法调用，相信不少朋友都听说过，基本的思路可以用一个经典比方来解释：A计算机想要计算一个两个数的加法，但A自己做不了，于是叫另外一台计算机B帮忙，B有计算加法的功能，A调用它就像调用这个功能是自己的一样方便。这个就叫做远程方法调用了。

远程方法调用是EJB实现的支柱，建立分布式应用的核心思想。这个很好理解，再拿上面的计算加法例子，A只知道去call计算机B的方法，自己并没有B的那些功能，所以A计算机端就无法看到B执行这段功能的过程和代码，因为看都看不到，所以既没有机会窃取也没有机会去改动方法代码。EJB正式基于这样的思想来完成它的任务的。当简单的加法变成复杂的数据库操作和电子商务交易应用的时候，这样的安全性和分布式应用的便利性就表现出来优势了。

好了，回到细节上，要如何实现远程方法调用呢？我希望大家学习任何技术的时候可以试着依赖自己的下意识判断，只要你的想法是合理健壮的，那么很可能实际上它就是这么做的，毕竟真理都蕴藏在平凡的生活细节中。这样只要带着一些薄弱的Java基础来思考RMI，其实也可以想出个大概来。

a) 需要有一个服务器角色，它拥有真正的功能代码方法。例如B，它提供加法服务
b) 如果想远程使用B的功能，需要知道B的IP地址
c) 如果想远程使用B的功能，还需要知道B中那个特定服务的名字

我们很自然可以想到这些，虽然不完善，但已经很接近正确的做法了。实际上RMI要得以实现还得意于Java一个很重要的特性，就是Java反射机制。我们需要知道服务的名字，但又必须隐藏实现的代码，如何去做呢？答案就是：接口！
举个例子：
public interface Person(){
public void sayHello();
}

Public class PersonImplA implements Person{
public PersonImplA(){}

public void sayHello(){ System.out.println(“Hello!”);}
}

Public class PersonImplB implements Person{
public PersonImplB(){}

public void sayHello(){ System.out.println(“Nice to meet you!”);}
}

客户端：Person p = Naming.lookup(“PersonService”);
p.sayHello();

就这几段代码就包含了几乎所有的实现技术，大家相信么？客户端请求一个say hello服务，服务器运行时接到这个请求，利用Java反射机制的Class.newInstance()返回一个对象，但客户端不知道服务器返回的是 ImplA还是ImplB，它接受用的参数签名是Person，它知道实现了Person接口的对象一定有sayHello()方法，这就意味着客户端并不知道服务器真正如何去实现的，但它通过了解Person接口明确了它要用的服务方法名字叫做sayHello()。

如此类推，服务器只需要暴露自己的接口出来供客户端，所有客户端就可以自己选择需要的服务。这就像餐馆只要拿出自己的菜单出来让客户选择，就可以在后台厨房一道道的按需做出来，它怎么做的通常是不让客户知道的！（祖传菜谱吧，^_^）

最后一点是我调用lookup，查找一个叫PersonService名字的对象，服务器只要看到这个名字，在自己的目录（相当于电话簿）中找到对应的对象名字提供服务就可以了，这个目录就叫做JNDI (Java命名与目录接口），相信大家也听过的。

有兴趣的朋友不妨自己做个RMI的应用，很多前辈的博客中有简单的例子。提示一下利用Jdk的bin目录中rmi.exe和 rmiregistry.exe两个命令就可以自己建起一个服务器，提供远程服务。因为例子很容易找，我就不自己举例子了！

2． JVM沙箱&框架
RMI罗唆得太多了，实在是尽力想把它说清楚，希望对大家有帮助。最后的最后，给大家简单讲一下JVM框架，我们叫做Java沙箱。Java沙箱的基本组件如下：
a) 类装载器结构
b) class文件检验器
c) 内置于Java虚拟机的安全特性
d) 安全管理器及Java API

其中类装载器在3个方面对Java沙箱起作用：
a. 它防止恶意代码去干涉善意的代码
b. 它守护了被信任的类库边界
c. 它将代码归入保护域，确定了代码可以进行哪些操作

虚拟机为不同的类加载器载入的类提供不同的命名空间，命名空间由一系列唯一的名称组成，每一个被装载的类将有一个名字，这个命名空间是由Java虚拟机为每一个类装载器维护的，它们互相之间甚至不可见。

我们常说的包（package）是在Java虚拟机第2版的规范第一次出现，正确定义是由同一个类装载器装载的、属于同一个包、多个类型的集合。类装载器采用的机制是双亲委派模式。具体的加载器框架我在Java杂谈（一）中已经解释过了，当时说最外层的加载器是AppClassLoader，其实算上网络层的话AppClassLoader也可以作为parent，还有更外层的加载器URLClassLoader。为了防止恶意攻击由URL加载进来的类文件我们当然需要分不同的访问命名空间，并且制定最安全的加载次序，简单来说就是两点：

a. 从最内层JVM自带类加载器开始加载，外层恶意同名类得不到先加载而无法使用
b. 由于严格通过包来区分了访问域，外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。

附：关于Java的平台无关性，有一个例子可以很明显的说明这个特性：
一般来说，C或C++中的int占位宽度是根据目标平台的字长来决定的，这就意味着针对不同的平台编译同一个C++程序在运行时会有不同的行为。然而对于 Java中的int都是32位的二进制补码标识的有符号整数，而float都是遵守IEEE 754浮点标准的32位浮点数。

PS: 这个小弟最近也没时间继续研究下去了，只是想抛砖引玉的提供给大家一个初步认识JVM的印象。有机会了解一下JVM的内部结构对今后做Java开发是很有好处的。

Java杂谈（七）－－接口& 组件、容器

终于又静下来继续写这个主题的续篇，前六篇主要讲了一些J2se方面的经验和感受，眼下Java应用范围已经被J2ee占据了相当大的一块领域，有些人甚至声称Java被J2ee所取代了。不知道大家如何来理解所谓的J2ee (Java2 Enterprise Edition)，也就是Java企业级应用？

笔者的观点是，技术的发展是顺应世界变化的趋势的，从C/S过渡到B/S模式，从客户端的角度考虑企业级应用或者说电子商务领域不在关心客户端维护问题，这个任务已经交给了任何一台PC都会有的浏览器去维护；从服务器端的角度考虑，以往C/S中的TCP/IP协议实现载体ServerSocket被Web Server Container所取代，例如大家都很熟悉的Tomcat、JBoss、WebLogic等等。总之一切的转变都是为了使得Java技术能更好的为人类生产生活所服务。

有人会问，直接去学J2ee跳过J2se行否？笔者是肯定不赞成的，实际上确实有人走这条路，但笔者自身体会是正是由于J2se的基础很牢固，才会导致在J2ee学习的道路上顺风顺水，知识点上不会有什么迷惑的地方。举个简单的例子吧：

笔者曾经跟大学同学讨论下面这两种写法的区别：
ArrayList list = new ArrayList(); //笔者不说反对，但至少不赞成
List list = new ArrayList(); //笔者支持
曾经笔者跟同学争论了几个小时，他非说第一种写法更科学，第二种完全没有必要。我无法完全说服他，但笔者认为良好的习惯和意识是任何时候都应该针对接口编程，以达到解耦合和可扩展性的目的。下面就以接口开始进入J2ee的世界吧：

1. J2ee与接口

每一个版本的J2ee都对应着一个确定版本的JDK，J2ee1.4对应Jdk1.4，现在比较新的是JDK5.0，自然也会有J2EE 5.0。其实笔者一直在用的是J2EE1.4，不过没什么关系，大家可以下任何一个版本的J2ee api来稍微浏览一下。笔者想先声明一个概念，J2ee也是源自Java，所以底层的操作依然调用到很多J2se的库，所以才建议大家先牢牢掌握J2se 的主流技术。

J2ee api有一个特点，大家比较熟悉的几个包java.jms、javax.servlet.http、javax.ejb等都以interface居多，实现类较少。其实大家真正在用的时候百分之六十以上都在反复的查着javax.servlet.http这个包下面几个实现类的api函数，其他的包很少问津。笔者建议在学习一种技术之前，对整体的框架有一个了解是很有必要的，J2ee旨在通过interface的声明来规范实现的行为，任何第三方的厂商想要提供自己品牌的实现前提也是遵循这些接口定义的规则。如果在从前J2se学习的道路上对接口的理解很好的话，这里的体会将是非常深刻的，举个简单的例子：

public interface Mp3{
public void play();
public void record();
public void stop();
}

如果我定义这个简单的接口，发布出去，规定任何第三方的公司想推出自己的名字为Mp3的产品都必须实现这个接口，也就是至少提供接口中方法的具体实现。这个意义已经远远不止是面向对象的多态了，只有厂商遵循J2ee的接口定义，世界上的J2ee程序员才能针对统一的接口进行程序设计，最终不用改变代码只是因为使用了不同厂商的实现类而有不同的特性罢了，本质上说，无论哪一种厂商实现都完成了职责范围内的工作。这个就是笔者想一直强调的，针对接口编程的思想。

接口到底有什么好处呢？我们这样设想，现在有AppleMp3、SonyMp3、SamsungMp3都实现了这个Mp3的接口，于是都有了play、 record、stop这三个功能。我们将Mp3产品座位一个组件的时候就不需要知道它的具体实现，只要看到接口定义知道这个对象有3个功能就可以使用了。那么类似下面这样的业务就完全可以在任何时间从3个品牌扩展到任意个品牌，开个玩笑的说，项目经理高高在上的写完10个接口里的方法声明，然后就丢给手下的程序员去写里面的细节，由于接口已经统一（即每个方法传入和传出的格式已经统一），经理只需关注全局的业务就可以天天端杯咖啡走来走去了，^_^：
public Mp3 create();
public void copy(Mp3 mp3);
public Mp3 getMp3();

最后用一个简单的例子说明接口：一个5号电池的手电筒，可以装入任何牌子的5号电池，只要它符合5号电池的规范，装入之后任何看不到是什么牌子，只能感受到手电筒在完成它的功能。那么生产手电筒的厂商和生产5号电池的厂商就可以完全解除依赖关系，可以各自自由开发自己的产品，因为它们都遵守5号电池应有的形状、正负极位置等约定。这下大家能对接口多一点体会了么？

2. 组件和容器
针对接口是笔者特意强调的J2ee学习之路必备的思想，另外一个就是比较常规的组件和容器的概念了。很多教材和专业网站都说J2EE的核心是一组规范与指南，强调J2ee的核心概念就是组件+容器，这确实是无可厚非的。随着越来越多的J2ee框架出现，相应的每种框架都一般有与之对应的容器。

容器，是用来管理组件行为的一个集合工具，组件的行为包括与外部环境的交互、组件的生命周期、组件之间的合作依赖关系等等。J2ee包含的容器种类大约有 Web容器、Application Client容器、EJB容器、Applet客户端容器等。但在笔者看来，现在容器的概念变得有点模糊了，大家耳熟能详是那些功能强大的开源框架，比如 Hibernate、Struts2、Spring、JSF等，其中Hibernate就基于JDBC的基础封装了对事务和会话的管理，大大方便了对数据库操作的繁琐代码，从这个意义上来说它已经接近容器的概念了，EJB的实体Bean也逐渐被以Hibernate为代表的持久化框架所取代。

组件，本意是指可以重用的代码单元，一般代表着一个或者一组可以独立出来的功能模块，在J2ee中组件的种类有很多种，比较常见的是EJB组件、DAO组件、客户端组件或者应用程序组件等，它们有个共同特点是分别会打包成.war，.jar，.jar，.ear，每个组件由特定格式的xml描述符文件进行描述，而且服务器端的组件都需要被部署到应用服务器上面才能够被使用。

稍微理解完组件和容器，还有一个重要的概念就是分层模型，最著名的当然是MVC三层模型。在一个大的工程或项目中，为了让前台和后台各个模块的编程人员能够同时进行工作提高开发效率，最重要的就是实现层与层之间的耦合关系，许多分层模型的宗旨和开源框架所追求的也就是这样的效果。在笔者看来，一个完整的 Web项目大概有以下几个层次：

a) 表示层（Jsp、Html、Javascript、Ajax、Flash等等技术对其支持）
b) 控制层（Struts、JSF、WebWork等等框架在基于Servlet的基础上支持，负责把具体的请求数据（有时卸载重新装载）导向适合处理它的模型层对象）
c) 模型层（笔者认为目前最好的框架是Spring，实质就是处理表示层经由控制层转发过来的数据，包含着大量的业务逻辑）
d) 数据层（Hibernate、JDBC、EJB等，由模型层处理完了持久化到数据库中）

当然，这仅仅是笔者个人的观点，仅仅是供大家学习做一个参考，如果要实现这些层之间的完全分离，那么一个大的工程，可以仅仅通过增加人手就来完成任务。虽然《人月神话》中已经很明确的阐述了增加人手并不能是效率增加，很大程度上是因为彼此做的工作有顺序上的依赖关系或者说难度和工作量上的巨大差距。当然理想状态在真实世界中是不可能达到的，但我们永远应该朝着这个方向去不断努力。最开始所提倡的针对接口来编程，哪怕是小小的细节，写一条List list= = new ArrayList()语句也能体现着处处皆使用接口的思想在里面。Anyway，这只是个开篇，笔者会就自己用过的J2ee技术和框架再细化谈一些经验.

Java杂谈（八）－－Servlet/Jsp

终于正式进入J2ee的细节部分了，首当其冲的当然是Servlet和Jsp了，上篇曾经提到过J2ee只是一个规范和指南，定义了一组必须要遵循的接口，核心概念是组件和容器。曾经有的人问笔者Servlet的Class文件是哪里来的？他认为是J2ee官方提供的，我举了一个简单的反例：稍微检查了一下Tomcat5.0里面的Servlet.jar文件和JBoss里面的Servlet.jar文件大小，很明显是不一样的，至少已经说明了它们不是源自同根的吧。其实Servlet是由容器根据J2ee的接口定义自己来实现的，实现的方式当然可以不同，只要都遵守J2ee规范和指南。

上述只是一个常见的误区罢了，告诉我们要编译运行Servlet，是要依赖于实现它的容器的，不然连jar文件都没有，编译都无法进行。那么Jsp呢？ Java Server Page的简称，是为了开发动态网页而诞生的技术，其本质也是Jsp，在编写完毕之后会在容器启动时经过编译成对应的Servlet。只是我们利用Jsp 的很多新特性，可以更加专注于前后台的分离，早期Jsp做前台是满流行的，毕竟里面支持Html代码，这让前台美工人员可以更有效率的去完成自己的工作。然后Jsp将请求转发到后台的Servlet，由Servlet处理业务逻辑，再转发回另外一个Jsp在前台显示出来。这似乎已经成为一种常用的模式，最初笔者学习J2ee的时候，大量时间也在编写这样的代码。

尽管现在做前台的技术越来越多，例如Flash、Ajax等，已经有很多人不再认为Jsp重要了。笔者觉得Jsp带来的不仅仅是前后端分离的设计理念，它的另外一项技术成就了我们今天用的很多框架，那就是Tag标签技术。所以与其说是在学习Jsp，不如更清醒的告诉自己在不断的理解Tag标签的意义和本质。

1． Servlet以及Jsp的生命周期
Servlet是Jsp的实质，尽管容器对它们的处理有所区别。Servlet有init()方法初始化，service()方法进行Web服务， destroy()方法进行销毁，从生到灭都由容器来掌握，所以这些方法除非你想自己来实现Servlet，否则是很少会接触到的。正是由于很少接触，才容易被广大初学者所忽略，希望大家至少记住Servlet生命周期方法都是回调方法。回调这个概念简单来说就是把自己注入另外一个类中，由它来调用你的方法，所谓的另外一个类就是Web容器，它只认识接口和接口的方法，注入进来的是怎样的对象不管，它只会根据所需调用这个对象在接口定义存在的那些方法。由容器来调用的Servlet对象的初始化、服务和销毁方法，所以叫做回调。这个概念对学习其他J2ee技术相当关键！

那么Jsp呢？本事上是Servlet，还是有些区别的，它的生命周期是这样的：
a) 一个客户端的Request到达服务器 ->
b) 判断是否第一次调用 -> 是的话编译Jsp成Servlet
c) 否的话再判断此Jsp是否有改变 -> 是的话也重新编译Jsp成Servlet
d) 已经编译最近版本的Servlet装载所需的其他Class
e) 发布Servlet，即调用它的Service()方法

所以Jsp号称的是第一次Load缓慢，以后都会很快的运行。从它的生命的周期确实不难看出来这个特点，客户端的操作很少会改变Jsp的源码，所以它不需要编译第二次就一直可以为客户端提供服务。这里稍微解释一下Http的无状态性，因为发现很多人误解，Http的无状态性是指每次一张页面显示出来了，与服务器的连接其实就已经断开了，当再次有提交动作的时候，才会再次与服务器进行连接请求提供服务。当然还有现在比较流行的是Ajax与服务器异步通过 xml交互的技术，在做前台的领域潜力巨大，笔者不是Ajax的高手，这里无法为大家解释。

2． Tag标签的本质
笔者之前说了，Jsp本身初衷是使得Web应用前后台的开发可以脱离耦合分开有效的进行，可惜这个理念的贡献反倒不如它带来的Tag技术对J2ee的贡献要大。也许已经有很多人开始使用Tag技术了却并不了解它。所以才建议大家在学习J2ee开始的时候一定要认真学习Jsp，其实最重要的就是明白标签的本质。

Html标签我们都很熟悉了，有 <html> 、 <head> 、 <body> 、 <title> ，Jsp带来的Tag标签遵循同样的格式，或者说更严格的Xml格式规范，例如 <jsp:include> 、 <jsp:useBean> 、 <c:if> 、 <c:forEach> 等等。它们没有什么神秘的地方，就其源头也还是Java Class而已，Tag标签的实质也就是一段Java代码，或者说一个Class文件。当配置文件设置好去哪里寻找这些Class的路径后，容器负责将页面中存在的标签对应到相应的Class上，执行那段特定的Java代码，如此而已。
说得明白一点的话还是举几个简单的例子说明一下吧：

<jsp:include> 去哪里找执行什么class呢?首先这是个jsp类库的标签，当然要去jsp类库寻找相应的class了，同样它也是由Web容器来提供，例如 Tomcat就应该去安装目录的lib文件夹下面的jsp-api.jar里面找，有兴趣的可以去找一找啊！

<c:forEach> 又去哪里找呢？这个是由Jsp2.0版本推荐的和核心标记库的内容，例如 <c:if> 就对应在页面中做if判断的功能的一断Java代码。它的class文件在jstl.jar这个类库里面，往往还需要和一个standard.jar类库一起导入，放在具体Web项目的WEB-INF的lib目录下面就可以使用了。

顺便罗唆一句，Web Project的目录结构是相对固定的，因为容器会按照固定的路径去寻找它需要的配置文件和资源，这个任何一本J2ee入门书上都有，这里就不介绍了。了解Tag的本质还要了解它的工作原理，所以大家去J2ee的API里找到并研究这个包：javax.servlet.jsp.tagext。它有一些接口，和一些实现类，专门用语开发Tag，只有自己亲自写出几个不同功能的标签，才算是真正理解了标签的原理。别忘记了自己开发的标签要自己去完成配置文件，容器只是集成了去哪里寻找jsp标签对应class的路径，自己写的标签库当然要告诉容器去哪里找啦。

说了这么多，我们为什么要用标签呢？完全在Jsp里面来个 <% %> 就可以在里面任意写Java代码了，但是长期实践发现页面代码统一都是与html同风格的标记语言更加有助于美工人员进行开发前台，它不需要懂Java，只要Java程序员给个列表告诉美工什么标签可以完成什么逻辑功能，他就可以专注于美工，也算是进一步隔离了前后台的工作吧！

3． 成就Web框架
框架是什么？曾经看过这样的定义：与模式类似，框架也是解决特定问题的可重用方法，框架是一个描述性的构建块和服务集合，开发人员可以用来达成某个目标。一般来说，框架提供了解决某类问题的基础设施，是用来创建解决方案的工具，而不是问题的解决方案。

正是由于Tag的出现，成就了以后出现的那么多Web框架，它们都开发了自己成熟实用的一套标签，然后由特定的Xml文件来配置加载信息，力图使得Web 应用的开发变得更加高效。下面这些标签相应对很多人来说相当熟悉了：
<html:password>
<logic:equal>
<bean:write>
<f:view>
<h:form>
<h:message>

它们分别来自Struts和JSF框架，最强大的功能在于控制转发，就是MVC三层模型中间完成控制器的工作。Struts-1实际上并未做到真正的三层隔离，这一点在Struts-2上得到了很大的改进。而Jsf向来以比较完善合理的标签库受到人们推崇。

今天就大概讲这么多吧，再次需要强调的是Servlet/Jsp是学习J2ee必经之路，也是最基础的知识，希望大家给与足够的重视！

Java杂谈（九）－－Struts

J2ee的开源框架很多，笔者只能介绍自己熟悉的几个，其他的目前在中国IT行业应用得不是很多。希望大家对新出的框架不要盲目的推崇，首先一定要熟悉它比旧的到底好在哪里，新的理念和特性是什么？然后再决定是否要使用它。

这期的主题是Struts，直译过来是支架。Struts的第一个版本是在2001年5月发布的，它提供了一个Web应用的解决方案，如何让Jsp和 servlet共存去提供清晰的分离视图和业务应用逻辑的架构。在Struts之前，通常的做法是在Jsp中加入业务逻辑，或者在Servlet中生成视图转发到前台去。Struts带着MVC的新理念当时退出几乎成为业界公认的Web应用标准，于是当代IT市场上也出现了众多熟悉Struts的程序员。即使有新的框架再出来不用，而继续用Struts的理由也加上了一条低风险，因为中途如果开发人员变动，很容易的招进新的会Struts的IT民工啊， ^_^!

笔者之前说的都是Struts-1，因为新出了Struts-2，使得每次谈到Struts都必须注明它是Struts-1还是2。笔者先谈比较熟悉的 Struts-1，下次再介绍一下与Struts－2的区别：

1． Struts框架整体结构
Struts-1的核心功能是前端控制器，程序员需要关注的是后端控制器。前端控制器是是一个Servlet，在Web.xml中间配置所有 Request都必须经过前端控制器，它的名字是ActionServlet，由框架来实现和管理。所有的视图和业务逻辑隔离都是应为这个 ActionServlet，它就像一个交通警察，所有过往的车辆必须经过它的法眼，然后被送往特定的通道。所有，对它的理解就是分发器，我们也可以叫做Dispatcher，其实了解Servlet编程的人自己也可以写一个分发器，加上拦截request的Filter，其实自己实现一个struts框架并不是很困难。主要目的就是让编写视图的和后台逻辑的可以脱离紧耦合，各自同步的完成自己的工作。

那么有了ActionServlet在中间负责转发，前端的视图比如说是Jsp，只需要把所有的数据Submit，这些数据就会到达适合处理它的后端控制器Action，然后在里面进行处理，处理完毕之后转发到前台的同一个或者不同的视图Jsp中间，返回前台利用的也是Servlet里面的forward 和redirect两种方式。所以到目前为止，一切都只是借用了Servlet的API搭建起了一个方便的框架而已。这也是Struts最显著的特性?? 控制器。

那么另外一个特性，可以说也是Struts-1带来的一个比较成功的理念，就是以xml配置代替硬编码配置信息。以往决定Jsp往哪个servlet提交，是要写进Jsp代码中的，也就是说一旦这个提交路径要改，我们必须改写代码再重新编译。而Struts提出来的思路是，编码的只是一个逻辑名字，它对应哪个class文件写进了xml配置文件中，这个配置文件记录着所有的映射关系，一旦需要改变路径，改变xml文件比改变代码要容易得多。这个理念可以说相当成功，以致于后来的框架都延续着这个思路，xml所起的作用也越来越大。

大致上来说Struts当初给我们带来的新鲜感就这么多了，其他的所有特性都是基于方便的控制转发和可扩展的xml配置的基础之上来完成它们的功能的。
下面将分别介绍Action和FormBean， 这两个是Struts中最核心的两个组件。

2． 后端控制器Action
Action就是我们说的后端控制器，它必须继承自一个Action父类，Struts设计了很多种Action，例如DispatchAction、 DynaValidationAction。它们都有一个处理业务逻辑的方法execute()，传入的request, response, formBean和actionMapping四个对象，返回actionForward对象。到达Action之前先会经过一个 RequestProcessor来初始化配置文件的映射关系，这里需要大家注意几点：

1) 为了确保线程安全，在一个应用的生命周期中，Struts框架只会为每个Action类创建一个Action实例，所有的客户请求共享同一个Action 实例，并且所有线程可以同时执行它的execute()方法。所以当你继承父类Action，并添加了private成员变量的时候，请记住这个变量可以被多个线程访问，它的同步必须由程序员负责。(所有我们不推荐这样做)。在使用Action的时候，保证线程安全的重要原则是在Action类中仅仅使用局部变量，谨慎的使用实例变量。局部变量是对每个线程来说私有的，execute方法结束就被销毁，而实例变量相当于被所有线程共享。

2) 当ActionServlet实例接收到Http请求后，在doGet()或者doPost()方法中都会调用process()方法来处理请求。 RequestProcessor类包含一个HashMap，作为存放所有Action实例的缓存，每个Action实例在缓存中存放的属性key为 Action类名。在RequestProcessor类的processActionCreate()方法中，首先检查在HashMap中是否存在 Action实例。创建Action实例的代码位于同步代码块中，以保证只有一个线程创建Action实例。一旦线程创建了Action实例并把它存放到 HashMap中，以后所有的线程会直接使用这个缓存中的实例。

3) <action> 元素的 <roles> 属性指定访问这个Action用户必须具备的安全角色，多个角色之间逗号隔开。RequestProcessor类在预处理请求时会调用自身的 processRoles()方法，检查配置文件中是否为Action配置了安全角色，如果有，就调用HttpServletRequest的 isUserInRole()方法来判断用户是否具备了必要的安全性角色，如果不具备，就直接向客户端返回错误。(返回的视图通过 <input> 属性来指定)

3． 数据传输对象FormBean
Struts并没有把模型层的业务对象直接传递到视图层，而是采用DTO（Data Transfer Object）来传输数据，这样可以减少传输数据的冗余，提高传输效率；还有助于实现各层之间的独立，使每个层分工明确。Struts的DTO就是 ActionForm，即formBean。由于模型层应该和Web应用层保持独立。由于ActionForm类中使用了Servlet API，因此不提倡把ActionForm传递给模型层， 而应该在控制层把ActionForm Bean的数据重新组装到自定义的DTO中，再把它传递给模型层。它只有两个scope，分别是session和request。（默认是session）一个ActionForm标准的生命周期是：
1) 控制器收到请求 ->
2) 从request或session中取出ActionForm实例，如不存在就创建一个 ->
3) 调用ActionForm的reset()方法 ->
4) 把实例放入session或者request中 ->
5) 将用户输入表达数据组装到ActionForm中 ->
6) 如眼张方法配置了就调用validate()方法 ->
7) 如验证错误就转发给 <input> 属性指定的地方，否则调用execute()方法

validate()方法调用必须满足两个条件：
1) ActionForm 配置了Action映射而且name属性匹配
2) <aciton> 元素的validate属性为true

如果ActionForm在request范围内，那么对于每个新的请求都会创建新的ActionForm实例，属性被初始化为默认值，那么reset ()方法就显得没有必要；但如果ActionForm在session范围内，同一个ActionForm实例会被多个请求共享，reset()方法在这种情况下极为有用。

4． 验证框架和国际化
Struts有许多自己的特性，但是基本上大家还是不太常用，说白了它们也是基于JDK中间的很多Java基础包来完成工作。例如国际化、验证框架、插件自扩展功能、与其他框架的集成、因为各大框架基本都有提供这样的特性，Struts也并不是做得最好的一个，这里也不想多说。Struts的验证框架，是通过一个validator.xml的配置文件读入验证规则，然后在validation-rules.xml里面找到验证实现通过自动为Jsp插入 Javascript来实现，可以说做得相当简陋。弹出来的JavaScript框不但难看还很多冗余信息，笔者宁愿用formBean验证或者 Action的saveErrors()，验证逻辑虽然要自己写，但页面隐藏/浮现的警告提示更加人性化和美观一些。

至于Struts的国际化，其实无论哪个框架的国际化，java.util.Locale类是最重要的Java I18N类。在Java语言中，几乎所有的对国际化和本地化的支持都依赖于这个类。如果Java类库中的某个类在运行的时候需要根据Locale对象来调整其功能，那么就称这个类是本地敏感的(Locale-Sensitive)，例如java.text.DateFormat类就是，依赖于特定Locale。

创建Locale对象的时候，需要明确的指定其语言和国家的代码，语言代码遵从的是ISO-639规范，国家代码遵从ISO-3166规范，可以从
http://www.unicode.org/unicode/onlinedat/languages.html
http://www.unicode.org/unicode/onlinedat/countries.htm

Struts的国际化是基于properties的message/key对应来实现的，笔者曾写过一个程序，所有Jsp页面上没有任何Text文本串，全部都用的是 <bean:message> 去Properties文件里面读，这个时候其实只要指定不同的语言区域读不同的Properties文件就实现了国际化。需要注意的是不同语言的字符写进Properties文件的时候需要转化成Unicode码，JDK已经带有转换的功能。JDK的bin目录中有native2ascii这个命令，可以完成对*.txt和*.properties的Unicode码转换。

OK，今天就说到这里，本文中的很多内容也不是笔者的手笔，是笔者一路学习过来自己抄下来的笔记，希望对大家有帮助！Java杂谈一路走来，感谢大家持续的关注，大概再有个2到3篇续篇就改完结了！笔者尽快整理完成后续的写作吧……^_^

Java杂谈（九）－－Struts2

最近业余时间笔者一直Java Virtual Machine的研究，由于实习分配到项目组里面，不想从前那么闲了，好不容易才抽出时间来继续这个话题的帖子。我打算把J2ee的部分结束之后，再谈谈 JVM和JavaScript，只要笔者有最新的学习笔记总结出来，一定会拿来及时和大家分享的。衷心希望与热爱Java的关大同仁共同进步……

这次准备继续上次的话题先讲讲Struts-2，手下简短回顾一段历史：随着时间的推移，Web应用框架经常变化的需求，产生了几个下一代 Struts的解决方案。其中的Struts Ti 继续坚持 MVC模式的基础上改进，继续Struts的成功经验。 WebWork项目是在2002年3月发布的，它对Struts式框架进行了革命性改进，引进了不少新的思想，概念和功能，但和原Struts代码并不兼容。WebWork是一个成熟的框架，经过了好几次重大的改进与发布。在2005年12月，WebWork与Struts Ti决定合拼， 再此同时， Struts Ti 改名为 Struts Action Framework 2.0,成为Struts真正的下一代。

看看Struts-2的处理流程：
1) Browser产生一个请求并提交框架来处理：根据配置决定使用哪些拦截器、action类和结果等。
2) 请求经过一系列拦截器：根据请求的级别不同拦截器做不同的处理。这和Struts-1的RequestProcessor类很相似。
3) 调用Action: 产生一个新的action实例，调用业务逻辑方法。
4) 调用产生结果：匹配result class并调用产生实例。
5) 请求再次经过一系列拦截器返回：过程也可配置减少拦截器数量
6) 请求返回用户：从control返回servlet，生成Html。

这里很明显的一点是不存在FormBean的作用域封装，直接可以从Action中取得数据。 这里有一个Strut-2配置的web.xml文件：
<filter>
<filter-name> controller </filter-name>
<filter-class> org.apache.struts.action2.dispatcher.FilterDispatcher </filter-class>
</filter>
<filter-mapping>
<filter-name> cotroller </filter-name>
<url-pattern> /* </url-pattern>
</filter-mapping>

注意到以往的servlet变成了filter，ActionServlet变成了FilterDispatcher，*.do变成了/*。filter 配置定义了名称(供关联)和filter的类。filter mapping让URI匹配成功的的请求调用该filter。默认情况下，扩展名为 ".action "。这个是在default.properties文件里的 "struts.action.extension "属性定义的。

default.properties是属性定义文件，通过在项目classpath路径中包含一个名为“struts.properties”的文件来设置不同的属性值。而Struts-2的默认配置文件名为struts.xml。由于1和2的action扩展名分别为.do和.action，所以很方便能共存。我们再来看一个Struts-2的action代码：
public class MyAction {
public String execute() throws Exception {
//do the work
return "success ";
}
}

很明显的区别是不用再继承任何类和接口，返回的只是一个String，无参数。实际上在Struts-2中任何返回String的无参数方法都可以通过配置来调用action。所有的参数从哪里来获得呢？答案就是Inversion of Control技术（控制反转）。笔者尽量以最通俗的方式来解释，我们先试图让这个Action获得reuqest对象，这样可以提取页面提交的任何参数。那么我们把request设为一个成员变量，然后需要一个对它的set方法。由于大部分的action都需要这么做，我们把这个set方法作为接口来实现。
public interface ServletRequestAware {
public void setServletRequest(HttpServletRequest request);
}

public class MyAction implements ServletRequestAware {
private HttpServletRequest request;

public void setServletRequest(HttpServletRequest request) {
this.request = request;
}

public String execute() throws Exception {
// do the work directly using the request
return Action.SUCCESS;
}
}

那么谁来调用这个set方法呢？也就是说谁来控制这个action的行为，以往我们都是自己在适当的地方写上一句 action.setServletRequest(…)，也就是控制权在程序员这边。然而控制反转的思想是在哪里调用交给正在运行的容器来决定，只要利用Java反射机制来获得Method对象然后调用它的invoke方法传入参数就能做到，这样控制权就从程序员这边转移到了容器那边。程序员可以减轻很多繁琐的工作更多的关注业务逻辑。Request可以这样注入到action中，其他任何对象也都可以。为了保证action的成员变量线程安全， Struts-2的action不是单例的，每一个新的请求都会产生一个新的action实例。

那么有人会问，到底谁来做这个对象的注入工作呢？答案就是拦截器。拦截器又是什么东西？笔者再来尽量通俗的解释拦截器的概念。大家要理解拦截器的话，首先一定要理解GOF23种设计模式中的Proxy模式。

A对象要调用f()，它希望代理给B来做，那么B就要获得A对象的引用，然后在B的f()中通过A对象引用调用A对象的f()方法，最终达到A的f()被调用的目的。有没有人会觉得这样很麻烦，为什么明明只要A.f()就可以完成的一定要封装到B的f()方法中去？有哪些好处呢？

1) 这里我们只有一个A，当我们有很多个A的时候，只需要监视B一个对象的f()方法就可以从全局上控制所有被调用的f()方法。
2) 另外，既然代理人B能获得A对象的引用，那么B可以决定在真正调A对象的f()方法之前可以做哪些前置工作，调完返回前可有做哪些后置工作。

讲到这里，大家看出来一点拦截器的概念了么？它拦截下一调f()方法的请求，然后统一的做处理（处理每个的方式还可以不同，解析A对象就可以辨别），处理完毕再放行。这样像不像对流动的河水横切了一刀，对所有想通过的水分子进行搜身，然后再放行？这也就是AOP（Aspect of Programming面向切面编程）的思想。

Anyway，Struts-2只是利用了AOP和IoC技术来减轻action和框架的耦合关系，力图到最大程度重用action的目的。在这样的技术促动下，Struts-2的action成了一个简单被框架使用的POJO（Plain Old Java Object）罢了。实事上AOP和IoC的思想已经遍布新出来的每一个框架上，他们并不是多么新的技术，利用的也都是JDK早已可以最到的事情，它们代表的是更加面向接口编程，提高重用，增加扩展性的一种思想。Struts-2只是部分的使用这两种思想来设计完成的，另外一个最近很火的框架 Spring，更大程度上代表了这两种设计思想，笔者将于下一篇来进一步探讨Spring的结构。

PS: 关于Struts-2笔者也没真正怎么用过，这里是看了网上一些前辈的帖子之后写下自己的学习体验，不足之处请见谅！

Java杂谈（十）－－Spring

笔者最近比较忙，一边在实习一边在寻找明年毕业更好的工作，不过论坛里的朋友非常支持小弟继续写，今天是周末，泡上一杯咖啡，继续与大家分享J2ee部分的学习经验。今天的主题是目前很流行也很好的一个开源框架－Spring。

引用《Spring2.0技术手册》上的一段话：
Spring的核心是个轻量级容器，它是实现IoC容器和非侵入性的框架，并提供AOP概念的实现方式；提供对持久层、事务的支持；提供MVC Web框架的实现，并对于一些常用的企业服务API提供一致的模型封装，是一个全方位的应用程序框架，除此之外，对于现存的各种框架，Spring也提供了与它们相整合的方案。
接下来笔者先谈谈自己的一些理解吧，Spring框架的发起者之前一本很著名的书名字大概是《J2ee Development without EJB》，他提倡用轻量级的组件代替重量级的EJB。笔者还没有看完那本著作，只阅读了部分章节。其中有一点分析觉得是很有道理的：

EJB里在服务器端有Web Container和EJB Container，从前的观点是各层之间应该在物理上隔离，Web Container处理视图功能、在EJB Container中处理业务逻辑功能、然后也是EBJ Container控制数据库持久化。这样的层次是很清晰，但是一个很严重的问题是Web Container和EJB Container毕竟是两个不同的容器，它们之间要通信就得用的是RMI机制和JNDI服务，同样都在服务端，却物理上隔离，而且每次业务请求都要远程调用，有没有必要呢？看来并非隔离都是好的。

再看看轻量级和重量级的区别，笔者看过很多种说法，觉得最有道理的是轻量级代表是POJO + IoC，重量级的代表是Container + Factory。（EJB2.0是典型的重量级组件的技术）我们尽量使用轻量级的Pojo很好理解，意义就在于兼容性和可适应性，移植不需要改变原来的代码。而Ioc与Factory比起来，Ioc的优点是更大的灵活性，通过配置可以控制很多注入的细节，而Factory模式，行为是相对比较封闭固定的，生产一个对象就必须接受它全部的特点，不管是否需要。其实轻量级和重量级都是相对的概念，使用资源更少、运行负载更小的自然就算轻量。

话题扯远了，因为Spring框架带来了太多可以探讨的地方。比如它的非侵入性：指的是它提供的框架实现可以让程序员编程却感觉不到框架的存在，这样所写的代码并没有和框架绑定在一起，可以随时抽离出来，这也是Spring设计的目标。Spring是唯一可以做到真正的针对接口编程，处处都是接口，不依赖绑定任何实现类。同时，Spring还设计了自己的事务管理、对象管理和Model2 的MVC框架，还封装了其他J2ee的服务在里面，在实现上基本都在使用依赖注入和AOP的思想。由此我们大概可以看到Spring是一个什么概念上的框架，代表了很多优秀思想，值得深入学习。笔者强调，学习并不是框架，而是框架代表的思想，就像我们当初学Struts一样……

1．Spring MVC
关于IoC和AOP笔者在上篇已经稍微解释过了，这里先通过Spring的MVC框架来给大家探讨一下Spring的特点吧。（毕竟大部分人已经很熟悉Struts了，对比一下吧）
众所周知MVC的核心是控制器。类似Struts中的ActionServlet，Spring里面前端控制器叫做DispatcherServlet。里面充当Action的组件叫做Controller，返回的视图层对象叫做ModelAndView，提交和返回都可能要经过过滤的组件叫做 Interceptor。

让我们看看一个从请求到返回的流程吧：
(1) 前台Jsp或Html通过点击submit，将数据装入了request域
(2) 请求被Interceptor拦截下来，执行preHandler()方法出前置判断
(3) 请求到达DispathcerServlet
(4) DispathcerServlet通过Handler Mapping来决定每个reuqest应该转发给哪个后端控制器Controller

Java杂谈（十一）ORM

这是最后一篇Java杂谈了，以ORM框架的谈论收尾，也算是把J2ee的最后一方面给涵盖到了，之所以这么晚才总结出ORM这方面，一是笔者这两周比较忙，另一方面也想善始善终，仔细的先自己好好研究一下ORM框架技术，不想草率的敷衍了事。

其实J2ee的规范指南里面就已经包括了一些对象持久化技术，例如JDO（Java Data Object）就是Java对象持久化的新规范，一个用于存取某种数据仓库中的对象的标准化API，提供了透明的对象存储，对开发人员来说，存储数据对象完全不需要额外的代码（如JDBC API的使用）。这些繁琐的工作已经转移到JDO产品提供商身上，使开发人员解脱出来，从而集中时间和精力在业务逻辑上。另外，JDO很灵活，因为它可以在任何数据底层上运行。JDBC只是面向关系数据库（RDBMS）JDO更通用，提供到任何数据底层的存储功能，比如关系数据库、文件、XML以及对象数据库（ODBMS）等等，使得应用可移植性更强。我们如果要理解对象持久化技术，首先要问自己一个问题：为什么传统的JDBC来持久化不再能满足大家的需求了呢？

笔者认为最好是能用JDBC真正编写过程序了才能真正体会ORM的好处，同样的道理，真正拿Servlet/Jsp做过项目了才能体会到Struts、 Spring等框架的方便之处。很幸运的是笔者这两者都曾经经历过，用混乱的内嵌Java代码的Jsp加Servlet转发写过完整的Web项目，也用 JDBC搭建过一个完整C/S项目的后台。所以现在接触到新框架才更能体会它们思想和实现的优越之处，回顾从前的代码，真是丑陋不堪啊。^_^

回到正题，我们来研究一下为什么要从JDBC发展到ORM。简单来说，传统的JDBC要花大量的重复代码在初始化数据库连接上，每次增删改查都要获得 Connection对象，初始化Statement，执行得到ResultSet再封装成自己的List或者Object，这样造成了在每个数据访问方法中都含有大量冗余重复的代码，考虑到安全性的话，还要加上大量的事务控制和log记录。虽然我们学习了设计模式之后，可以自己定义Factory来帮助减少一部分重复的代码，但是仍然无法避免冗余的问题。其次，随着OO思想深入人心，连典型的过程化语言Perl等都冠冕堂皇的加上了OO的外壳，何况是 Java中繁杂的数据库访问持久化技术呢？强调面向对象编程的结果就是找到一个桥梁，使得关系型数据库存储的数据能准确的映射到Java的对象上，然后针对Java对象来设计对象和方法，如果我们把数据库的Table当作Class，Record当作Instance的话，就可以完全用面向对象的思想来编写数据层的代码。于是乎，Object Relationship Mapping的概念开始普遍受到重视，尽管很早很早就已经有人提出来了。
缺点我们已经大概清楚了，那么如何改进呢？对症下药，首先我们要解决的是如何从Data Schema准备完美的映射到Object Schema，另外要提供对数据库连接对象生命周期的管理，对事务不同粒度的控制和考虑到扩展性后提供对XML、Properties等可配置化的文件的支持。到目前为止，有很多框架和技术在尝试着这样做。例如似乎是封装管理得过了头的EJB、很早就出现目前已经不在开发和升级了的Apache OJB、首先支持Manual SQL的iBATIS，还有公认非常优秀的Hibernate等等。在分别介绍它们之前，我还想反复强调这些框架都在试图做什么：

毕竟Java Object和数据库的每一条Record还是有很大的区别，就是类型上来说，DB是没有Boolean类型的。而Java也不得不用封装类（Integer、Double等）为了能映射上数据库中为null的情况，毕竟Primitive类型是没有null值的。还有一个比较明显的问题是，数据库有主键和外键，而Java中仍然只能通过基本类型来对应字段值而已，无法规定Unique等特征，更别提外键约束、事务控制和级联操作了。另外，通过Java Object预设某Field值去取数据库记录，是否在这样的记录也是不能保证的。真的要设计到完全映射的话，Java的Static被所有对象共享的变量怎么办？在数据库中如何表现出来……
我们能看到大量的问题像一座座大山横在那些框架设计者们面前，他们并不是没有解决办法，而是从不同的角度去考虑，会得到很多不同的解决方案，问题是应该采取哪一种呢？甚至只有等到真正设计出来了投入生产使用了，才能印证出当初的设想是否真的能为项目开发带来更多的益处。笔者引用一份文档中提到一个健壮的持久化框架应该具有的特点：
A robust persistence layer should support----
1. Several types of persistence mechanism
2. Full encapsulation of the persistence mechanism.
3. Multi-object actions
4. Transactions Control
5. Extensibility
6. Object identifiers
7. Cursors: logical connection to the persistence mechanism
8. Proxies: commonly used when the results of a query are to be displayed in a list
9. Records: avoid the overhead of converting database records to objects and then back to records
10. Multi architecture
11. Various database version and/or vendors
12. Multiple connections
13. Native and non-native drivers
14. Structured query language queries(SQL)

Java杂谈（十一） ORM
现在来简短的介绍一下笔者用过的一些持久化框架和技术，之所以前面强调那么多共通的知识，是希望大家不要盲从流行框架，一定要把握它的本质和卓越的思想好在哪里。
1． Apache OJB
OJB代表Apache Object Relational Bridge，是Apache开发的一个数据库持久型框架。它是基于J2ee规范指南下的持久型框架技术而设计开发的，例如实现了ODMG 3.0规范的API，实现了JDO规范的API， 核心实现是Persistence Broker API。OJB使用XML文件来实现映射并动态的在Metadata layer听过一个Meta-Object-Protocol(MOP)来改变底层数据的行为。更高级的特点包括对象缓存机制、锁管理机制、 Virtual 代理、事务隔离性级别等等。举个OJB Mapping的简单例子ojb-repository.xml：

<class-descriptor class=”com.ant.Employee” table=”EMPLOYEE”>
<field-descriptor name=”id” column=”ID”
jdbc-type=”INTEGER” primarykey=”true” autoincrement=”true”/>

<field-descriptor name=”name” column=”NAME” jdbc-type=”VARCHAR”/>
</class-descrptor>

<class-descriptor class=”com.ant.Executive” table=”EXECUTIVE”>
<field-descriptor name=”id” column=”ID”
jdbc-type=”INTEGER” primarykey=”true” autoincrement=”true”/>

<field-descriptor name=”department” column=”DEPARTMENT” jdbc-type=”VARCHAR”/>

<reference-descriptor name=”super” class-ref=”com.ant.Employee”>
<foreignkey field-ref=”id”/>
</reference-descriptor>
</class-descrptor>

2． iBATIS
iBATIS最大的特点就是允许用户自己定义SQL来组配Bean的属性。因为它的SQL语句是直接写入XML文件中去的，所以可以最大程度上利用到 SQL语法本身能控制的全部特性，同时也能允许你使用特定数据库服务器的额外特性，并不局限于类似SQL92这样的标准，它最大的缺点是不支持枚举类型的持久化，即把枚举类型的几个对象属性拼成与数据库一个字段例如VARCHAR对应的行为。这里也举一个Mapping文件的例子sqlMap.xml：
<sqlMap>
<typeAlias type=”com.ant.Test” alias=”test”/>

<resultMap class=”test” id=”result”>
<result property=”testId” column=”TestId”/>
<result property=”name” column=”Name”/>
<result property=”date” column=”Date”/>
</resultMap>

<select id=”getTestById” resultMap=”result” parameterClass=”int”>
select * from Test where TestId=#value#
</select>

<update id=”updateTest” parameterClass=”test”>
Update Tests set Name=#name#, Date=”date” where TestId=#testId#
</update>
</sqlMap>

3． Hibernate
Hibernate无疑是应用最广泛最受欢迎的持久型框架，它生成的SQL语句是非常优秀。虽然一度因为不能支持手工SQL而性能受到局限，但随着新一代 Hibernate 3.x推出，很多缺点都被改进，Hibernate也因此变得更加通用而时尚。同样先看一个Mapping文件的例子customer.hbm.xml来有一个大概印象：

<hibernate-mapping>
<class name=”com.ant.Customer” table=”Customers”>
<id name=”customerId” column=”CustomerId” type=”int” unsaved-value=”0”>
<generator class=”sequence”>
<param name=”sequence”> Customers_CustomerId_Seq </param>
</generator>
</id>

<property name=”firstName” column=”FirstName”/>
<property name=”lastName” column=”LastName”/>

<set name=”addresses” outer-join=”true”>
<key column=”Customer”/>
<one-to-many class=”com.ant.Address”/>
</set>
</class>
</hibernate-mapping>

Hibernate有很多显著的特性，最突出的就是它有自己的查询语言叫做HQL，在HQL中select from的不是Table而是类名，一方面更加面向对象，另外一方面通过在hibernate.cfg.xml中配置Dialect为HQL可以使得整个后台与数据库脱离耦合，因为不管用那种数据库我都是基于HQL来查询，Hibernate框架负责帮我最终转换成特定数据库里的SQL语句。另外 Hibernate在Object-Caching这方面也做得相当出色，它同时管理两个级别的缓存，当数据被第一次取出后，真正使用的时候对象被放在一级缓存管理，这个时候任何改动都会影响到数据库；而空闲时候会把对象放在二级缓存管理，虽然这个时候与数据库字段能对应上但未绑定在一起，改动不会影响到数据库的记录，主要目的是为了在重复读取的时候更快的拿到数据而不用再次请求连接对象。其实关于这种缓存的设计建议大家研究一下Oracle的存储机制（原理是相通的），Oracle牺牲了空间换来时间依赖于很健壮的缓存算法来保证最优的企业级数据库访问速率。

以上是一些Mapping的例子，真正在Java代码中使用多半是继承各个框架中默认的Dao实现类，然后可以通过Id来查找对象，或者通过 Example来查找，更流行的是更具Criteria查找对象。Criteria是完全封装了SQL条件查询语法的一个工具类，任何一个查询条件都可以在Criteria中找到方法与之对应，这样可以在Java代码级别实现SQL的完全控制。另外，现在许多ORM框架的最新版本随着JDk 5.0加入Annotation特性都开始支持用XDoclet来自动根据Annotation来生成XML配置文件了。

笔者不可能详细的讲解每一个框架，也许更多的人在用Hibernate，笔者是从OJB开始接触ORM技术的，它很原始却更容易让人理解从JDBC到 ORM的过渡。更多的细节是可以从官方文档和书籍中学到的，但我们应该更加看中它们设计思想的来源和闪光点，不是盲从它们的使用方法。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/hchen2008/archive/2009/04/03/4001147.aspx

1.可以每次发送同样大小的包,过大的包不予发送,过小的包,后面部分用固定的字符'\0'进行填充。

2. 将流按字符处理,抽出一个字符做转义字符(通常Java用'\'来做转义字符,比如"\n"表示换行).假如就设'\'为转义字符,发送方如果流当中出现'\',就在后面在追加一个'\',如果包结束,则用'\'做包的结束符.这样,在接收方,若读取一个单独的'\'或者流结束,就标示前面的内容构成一个包,如果连续读取两个'\',就将两个'\'用一个'\'进行替换.这样,就可以保证原来包中的信息不变,同时也能区分出每个包了。

3.在发送方发送一个包的时候,先将这个包的长度发送给对方(一般是4个字节表示包长),然后再将包的内容发送过去.接收方先接收4个字节,看看包的长度,然后按照长度来接收包,最好是大端字节序。

以上三种方法,是网络传输中经常用到的方法.后两种很常见.最后一种,在TCP长连接传输中应用最多.
综合以上的说法,就是要在TCP协议以上再封装一层协议,用来做分包的信息交换.
当然,如果TCP不是非要长连接,或者,信息包不是批量传输的情况下.可以一次TCP连接只传输一个包.这种情况下一般,一次TCP完成一次交互,即发送方发送信息包,接收方接收信息包同时发送一个接收方的响应包给发送方,表明接收方收到信息包,还是收到了错误包,或者接收方系统异常没有处理这个包之类的信息. 其实HTTP的交互过程,就是这样的.

读取数据使用DataInputStream和DataOutputStream，不要用BufferedReader和PrintStream。使用字节传送方式，使用readFully，
readFully
public final void readFully(byte[] b)
                     throws IOException参见 DataInput 的 readFully 方法的常规协定。
从所包含的输入流中读取此操作需要的字节。

指定者：
接口 DataInput 中的 readFully
参数：
b - 存储读取数据的缓冲区。
抛出：
EOFException - 如果此输入流在读取所有字节之前到达末尾。
IOException - 如果发生 I/O 错误。
另请参见：
FilterInputStream.in

--------------------------------------------------------------------------------

readFully
public final void readFully(byte[] b,
                            int off,
                            int len)
                     throws IOException参见 DataInput 的 readFully 方法的常规协定。
从所包含的输入流中读取此操作需要的字节。

指定者：
接口 DataInput 中的 readFully
参数：
b - 存储读取数据的缓冲区。
off - 数据的起始偏移量。
len - 要读取的字节数。
抛出：
EOFException - 如果此输入流在读取所有字节之前到达末尾。
IOException - 如果发生 I/O 错误。
另请参见：
FilterInputStream.in
 
 
Java code

in = new DataInputStream(new BufferedInputStream(socket.getInputStream()));
out = new DataOutputStream(socket.getOutputStream());

文/周立功

《程序员》杂志的编辑约我写一篇命题作文，想了几天都无从下手不知道写什么才好。在这篇文章里，我不打算将创业的艰辛与喜悦重新回忆一遍，我确实不想去误导大家，因为我所处的年代是一个物质缺乏的年代，成功相对来说要容易得多。每个人的成长经历都有其个性化的东西，每个人的成功创业经验虽然有一些可以遵循的普遍规律，但一般来说都很难复制，成功需要不断地创新。
对于今天很多的年轻人来说，一味注重技术至上的观念刻骨铭心，其实很多时候努力并非一定有回报。事实上，有不少出类拔萃的人才往往做出来的产品就是卖不掉，因为设计者压根儿就不了解用户的需求和心理以及产品功能的恰当定义，而总想在同事及其老板面前卖弄自己的技术和产品功能。其实有很多思维性的东西恰恰是很多人所忽视的，因为从一开始的出发点就错了，怎么可能取得辉煌的成绩呢？所以有时拥有卓越的技术并不一定代表人生的成功，很多企业就是死在一些自命不凡的“卓越人才”手中。

它山之石可以攻玉，减少“阶段0”的开发
有所“创造”确实是人人期待的，令人瞩目的发明虽然激动人心却谈何容易，人们时常将盖茨没有任何爆炸性的发明作为茶余饭后的笑料，我们不妨从另外一个角度去探索微软的成功奥妙从而为我们所用。
确实不假，盖茨的DOS源代码是从帕特森手上“买”来的。这些年来，我收集了世界各地中英文版有关微软的专著来比较研究，大家仅仅注意到盖茨为建立整个行业架构标准的远见，并叹服盖茨深得市场运作经验的精髓，我认为这些研究成果都是后来者研究微软成功经验，是“牵强附会”不可复制的理论总结。
当初微软公司还仅仅是一家很稚嫩的公司，可以说生存下去是盖茨作为老板唯一的使命。事实上，正当盖茨决定动手来写IBM所要的OS时，原计划在一年左右完成，但IBM公司只给了他几个月的时间。尽管帕特森的QDOS并不完善错误百出，但为了履行对IBM的承诺，盖茨购买了QDOS改贴标签后卖给了IBM公司。盖茨对此心知肚明，因为他知道如果用一年的时间来做OS的开发，他将失去与巨人IBM的合作机会，那是一种浪费。付一小部分的技术费用没有关系，只要能获得Know-how，获得更高的利润就好了。通过支付权利金引入技术，然后以模仿的方式学习他人的技术，再改造成符合IBM需要即可。
“买”――只要有现成的就不需要自己开发，这就是盖茨的过人之处，而且恰恰是很多人忽视的地方，值得我们所有人学习和仿效。盖茨就是由于没有“阶段0”，从而大幅度地降低开发风险。
当年，我是一个人单枪匹马借了2.15万元出来创业的，可以说是负资产，后来才开始有伙伴注资6万元。没有经验怎么办？我有一个非常好习惯，读书从不拘泥于他人的观点，也满足于人云亦云，否则那就是听别人讲故事，那不是您的东西，有入宝山空手而归。我认为，要想成功就必须“研究”成功者的轨迹，向成功者学习。
下面我会把我“第一桶金”的故事告诉你，这也是尽量减少“阶段0”开发一个非常典型的例子。
当年，《羊城晚报》几乎每天都有半版广告刊登信息台（听歌、悄悄话等）广告，一打听广告费每天几十万。当时相信不少人在利用公费电话在拨打这些信息台。后来我送货到客户那里发现电话机都外加了一个铁壳并上了一把锁，从看到那一幕开始，我决定做电话加密码锁，锁长途电话0字头，手机、BB机、信息台的9字头。通过朋友介绍，福州某公司有这个技术，于是我打了一个试探性的电话，使用5000元购买方案和源代码，对方非常爽快地同意了。我生怕有变立即坐飞机到福州去，很快就见到了郑新建工程师，他原来在福州某公司工作，我见到他的时候已经离开了福州某公司，但仍然自己写一些产品解决方案，通过福州某公司销售。买到方案与源代码之后，我立即带样机到各地去做测试，发现这台样机兼容性太差，而且市场已经开始在卖的产品也存在同样的问题，我想只要解决好兼容性的问题，如果在任何地区交换机局域网都能够使用，那就是最好的产品不愁没有市场。
我当时既没有资金也没有生产和销售经验，到底怎么将技术变成市场上所需要的产品呢？那是因为我找到了生产电话分线器的广州市白云区百新电器厂的老板陈国亮，由他生产和销售，每销售一台产品给我提成。以这个项目为起点，我们使用PIC单片机的数量很快就达到了每月100K以上，一年以后Microchip香港公司经理Andi主动找上门来将当时的广州强力电子研究所发展成为了授权分销商。
毫不否认盖茨的远见和判断力是微软至关重要的核心竞争力，但盖茨也绝非天才，否则盖茨就不会在浏览器上输给网景了，尽管微软使用的很多技术都不是微软所发明的，但毫不妨碍微软独步天下。

注重核心技术，其余的外包
通过创业以来第一个项目的成功，我深深地体会到商业模式比技术本身更重要。
通过十多年的努力，我们设计的“铁将军（Steel Mate）”品牌汽车防盗器、汽车倒车雷达不仅成为了全世界范围的“隐性冠军”，而且为GE等世界著名汽车厂商售前市场提供配套产品，与此同时我们为智能卡酒店门锁厂商设计与制造的各种智能卡门锁控制模块在国内也一直处于第一名的地位。
他们为何能够取得与众不同的成功呢？其最大的长处就是产品创意与制造、简约时尚风格的工业设计、模具制造技术以及精心打造的销售渠道，这些厂商深刻明白“注重核心技术做自己擅长的，其余的外包分段取利”的基本道理，而对于我来说就是“智慧出租”，通过与强者合作获得双赢。
通过这些成功经验的积累，我们开始全力以赴注重发展核心技术，将自己不擅长的技术全部外包。比如，我们长期投资清华大学计算机系，并建立以陈渝博士后为主Linux内核开发团队，为公司底层的技术提供良好支撑，而我们自己则将精力集中于Linux驱动开发。这种分工合作、协同开发的模式赢得市场上宝贵的时间，并快速取得了应用成果。
也许有程序员会关心JTAG开发工具问题，那也是一个“外包”的项目。当时，我们在网上发现了一个由计算机爱好者业余时间设计的H-JTAG，这是一个比较稳定的调试器软件，正好适合我们使用。于是我就同设计者联系，并决定由周立功单片机资助他继续开发，同时，其开发成果还免费提供给网上的用户下载，保证它作为一个自由软件。其实，无论是Linux还是H-JTAG都是开源软件，如果担心其它的同行因此受益而超越自己的话，难免需要在公司负担很多开发人员，面面俱到地做许多事实上是重复的开发工作。其实，我们的合作伙伴都是所在领域的专家，如果自己从头到尾去学习和开发，不仅抢了合作伙伴的饭碗，而且结果未必理想。这种情况下不但会延误宝贵的商机，而且还会影响与合作伙伴之间的关系。其实只要引入我们企业长期积累和制定的嵌入式系统工程管理思想和规范，即可得到自己想要的结果：“做你最擅长的，其余的外包”，类似这样的案例在周立功单片机将会越来越多。

专注与差异化生存
1999年1月23日我离开了原公司，先后分别创立了广州周立功单片机发展有限公司与广州致远电子有限公司，分别从事贸易业务与产品制造。
作为代理商通过为客户提供解决方案从而达到大批量销售芯片是代理行业惯常使用的手段，而实际上通过设计能够真正达到增值获得丰厚回报的代理商却少之又少。要知道过去公司的人才数量和资源是非常宝贵的，如果没有正确的战略，机会可能稍纵即逝。事实上创业开始的前几年，我们一共为用户设计了超过100个品类的产品，产品型号超过500种，可以说几乎涉及到了各行各业，但能够带来稳定而丰厚回报的案例几乎没有。我经过一段时间的思考和报表分析发现，目前公司的业务做得太多、太杂，没有将任何一个行业做精。于是我下定决心减少用户数量集中精力在1－2个行业做强、做大，直至成为顶尖的行业专家，坚持十年如一日重点做好汽车配套产品与智能卡门锁控制模块的开发。通过多年的精耕细作，我们通过为直接用户设计产品增值年销售单片机的数量已经超过了1000万片，无论是对用户还是对半导体公司来说，我们无疑是一家非常有价值的代理商。
1999年5月，PHILIPS半导体公司邀请我去上海洽谈是否有意向代理LPC700单片机，当我拿到用户手册时离去上海的时间只有5天。当时公司不像现在有250位大学生，总共只有8个人，怎么办？我一边写商业计划书，一边与大家翻译用户手册、打字和贴图，面对机会就像抓住救命稻草一样加班加点，每天只休息3－5个小时。第5天我赶到上海东亚富豪酒店时，我将整整齐齐的材料放在了来自美国PHILIPS半导体公司2位经理的面前，包括吃饭在内仅仅只洽谈了2个小时，代理权就正式谈下来了。事后他们告诉我，就是因为我与众不同，专注且非常有个性。
风雨变换诱惑莫测，人怕出名猪怕壮，这是常理！随后找上门来要求我们代理芯片的著名半导体公司不下10家。这时候，对于很多人来说不做什么就是一个艰难的选择。此时，我认为不管对方开出的条件多好，有冲突的就是不做，性能不突出的也不做，如果能够形成价值链互补，就一定要通过自己的努力和业绩表现主动去“求”半导体公司授权给我们，我就是这样取得了Keil、Catalyst、Sipex的代理权和信用额度。2004年SHARP半导体公司北京、日本、美国一共五位经理来到我的办公室要求我代理SHARP的ARM，帮助SHARP在中国推广以及制造用于全球销售的开发套件，我根本没有思考就一口回绝了，可以说SHARP给我的条件非常之好，特别是美国人觉得是非常不可思议的事情，作为商人这么好的赚钱机会都不要。为什么？我们之所以暂时“强大”，就是因为我们长期以来专注于发展PHILIPS半导体，集中精力对准焦点成为了小河里的大鱼，进而才引起了众人的关注。如果我们分散了精力，最后的结果一定会什么都不是！
当决定专注的目标之后，接下来的就是想办法如何做得与众不同，这是一件不容易的事情。最重要的就是穷举用户最大的需求和竞争者最容易忽略之处，然后将其做到最好。
为了推广好PHILIPS的单片机和ARM，我们定位于帮助初学者快速入门，至今一共编写出版了20多本专著，并将大部分版权全部捐献给了出版社用于降低成本，同时我也还会继续坚持将这项工作做下去、争取做得更好。邓小平有一句名言：“计算机要从娃娃抓起！”我认为，任何一个有远见的厂商，要想成功地推广嵌入式系统，一定要从在校大学生抓起，这必定是一件一举多得的好事。既能够提高企业的美誉度，又能获得市场占有率，还能为学生提供实践的理论基础。为何很少有厂商或者代理商心甘情愿去做？这不仅可帮助企业建立差异化，而且还能够给企业带来长远的利益，何乐而不为？
比如说，至今在国内任何一家代理商的网站上几乎都找不到完整的芯片中文数据手册、用户手册与应用手册，不是我们的同行不知道其中的重要性。首先大家普遍认为这是半导体公司的份内之事，其次大家或许感到自己做好之后放到网站任由用户免费下载，会给其它代理商占了便宜。但很多人却始终不明白，这是满足用户需求制造公司服务差异化的最佳机会。
于是我们决心从网站入手坚持长期投资，做中国最好的嵌入式系统专业技术网站，建立专业的技术支持与开发团队。特别是对于优质用户的服务，网站还专门开通了“快速绿色通道”，如果这样的用户遇到问题，都是由我、分公司经理及其相关服务部门的经理牵头负责实施“保姆式”的服务，我们实施的服务战略就是：“用有限的资源为有效的用户提供高质量的服务”。
“你若亲近神，神就亲近你！” 2001年8月一篇来自PHILIPS内部刊物的报道《风险意味着机会》，我是被推上了“本地英雄”封底人物栏目的第一位亚洲代理商；2004年PHILIPS半导体公司又给我授予了“优秀卓越贡献奖”，来自全国各地的用户连续多年通过《亚洲资源》媒体将我们公司评选为“本地十大最受客户欢迎的分销商”。没有用户崇高的忠诚度和长期的大力支持，我们不可能从1999年以来连续多年销售单片机取得PHILIPS亚太区第一名的业绩。
一个“人弃我取”的机会成就了我，尽管个人与团队的努力至关重要，但可以毫不掩饰地说，如果没有PHILIPS半导体经理的慧眼相马，一定是巧妇难为无米之炊，业界不会再有我的一席之地。
在嵌入式系统应用技术方面与我们不相伯仲或者说比我们聪明能干的人才何止万千，为何只有少数人能够脱颖而出呢？就是因为想法太多、不专注，不能坚持在一个行业里面十年如一日地下苦功夫。但面对众多的竞争者和后来者，我每天都如履薄冰，不敢有丝毫的懈怠，每天坚持学习到深夜，因为唯有不断地学习和更新思维才有可能具备远见并及时规避可能出现的失误。

关注用户的需求
其实维系企业生命的关键在于产品是否能够获得市场的青睐，我们要做的并非是成为技术的领先者，而是要将技术成果转化为迎合消费者需要的商品。
八十年代是一个物质缺乏的年代，而今天的人们更加注重消费享受和情感的分享，这是任何人都无法否认的现实。我们公司刚开始做产品时，由于我个人偏爱蓝色，所以我凭着老板的权威将所有产品的外观全部都做成蓝色，其实当时也有不少的人向我提出改进意见，但我仍然还是无动于衷，为什么？就是因为我是做技术出身的，而且从创业初期开始一直都是依靠技术一路拼杀过来的，可以说过于迷信技术的力量，因此在很长的一段时间内，公司完全走的是研究的路子。而我却恰恰忽视了用户读产品的心理需求，以至于在产品推向市场之后一直都无法打开局面。
当时，EasyPRO系列编程器面市的时候，其销售数量一年下来都不到500套，同时有用户表示对于产品的设计很不满意，这可以说是一次深刻的教训。于是我下定决心组建工业设计事业部，首先从EasyPRO系列通用编程器开始，亲自管理、研究和参与产品的外观设计，将原来的模具全部废掉重新设计。尽管是第一次设计，在产品的外观上没有做出非常杰出的效果，但无论如何，新产品外观比原有的产品出众得多。2005年10个月的时间里，EasyPRO系列通用编程器的销售数量达到了6000套。2006年我们又推出了SmartPRO系列智能型通用编程器，预计本年度销售编程器的总数量将超过10000套，而这些产品将带着我和我们公司跻身于国内编程器市场主流品牌之列。
从那次深刻的教训以后，我明白好的外观设计可以凸现产品的魅力，让产品与环境融为一体，刺激消费者产生强烈的购买欲望。即使是普通产品，经过精心设计，也会成为一件时尚产品，甚至让人们觉得它就是一件艺术品，从这一点来说，时尚、新潮、艺术化的外观设计是塑造产品品牌形象的第一要素。
从那以后，我开始改变产品简介、广告以及展示会的形象设计，为了配合新的形象，我们展开了大规模、全方位的宣传：一方面尽量多地为用户提供产品简介手册，同时通过大量的媒体广告，让用户认识并初步了解公司，从而迅速有效地提高了品牌知名度；另一方面组织各种全国巡回演讲、免费ARM技术培训活动和产品展示会，而且我们每次参加展示会都是投入4个摊位并进行特装展位设计，目的就是为了获得与用户积极沟通的机会。
2003年暑假期间，周立功单片机投资80万元邀请了行业3位著名的嵌入式系统专家组成讲师团在全国10个城市主办了免费的ARM巡回演讲，提供了免费的午餐，可以说规模空前。这次巡讲中，共有8000多人参加了这次活动，随后公司趁热打铁推出了售价400元的EasyARM2104开发学习套件，第一个月生产的1000套在15天之内抢购一空，直到销售了15000套之后才因新产品的推出而停产。这次活动不仅收回了80万元的宣传费用，而且还直接或间接地影响了超过50万嵌入式相关人员，强有力地达到了品牌宣传的目的。在赢得丰厚利润回报的同时，也打造了嵌入式行业一次非常成功的“事件营销”经典案例，我深深地体会到“俘虏”用户的心是提升品牌的唯一途径。

全球化市场意识
过去，一个公司可能需要等到10年之后才开始考虑是否全球化，而今天由于网络技术的发展，无论我们身处何地，世界各地的新信息仿佛就在眼前，谁也不会被边缘化了，所以今天成立公司明天就要准备全球销售。
这几年ARM已经到了热得不得了的程度，很多人不以为然，其实这是一种必然趋势。事实上，我在美国PHILIPS半导体公司看到，美国1997年出版的《嵌入式系统》杂志就已经大量刊登OS与32位嵌入式系统开发工具等文章和广告。在美国硅谷主办的嵌入式系统展示会上，来自欧美的上千展位展现在我眼前的是各种各样嵌入式系统产品，中国厂商普遍展示的是蜂鸣器、继电器等低档元器件。我第一次身临其境地感受到了中美之间的差距究竟有多大。中国太需要懂得国际市场需求和游戏规则的人才和企业家了。
同样是做USB分析仪，全球只有5家，我们自己的USB分析仪升级版在中国目前定价为3800元，这款产品原来的售价只有1800元，用户还认为太贵了。其实这样的产品在国内一年的销售数量也就200台，但是同样的情况在美国，一个小公司一年的销售额就能够到2000万美元，他们的单台最低售价不低于10000美元，以至于美国同行直接给我来电话，希望我在售价的基础上至少加一个0。
中国企业不做全球化销售能行吗？不行！而且中国企业必须向价值链顶端攀升，否则我们只能做欧美消费品市场的廉价加工基地。

个性化的企业文化，帮助他人走向成功
通过与用户合作所经历的共同成功过程中，用户将我教育成为了一个善良、上进、诚实、优秀的人才。我不仅懂得如何做自己最擅长事情的方式方法，而且也懂得了如何与用户、与员工分享成功的道理。一旦芯片销售数量增大成本下降就主动给用户降价，赢得了用户更长远的支持；公司效益提高了，年终就主动给员工涨工资、加奖金并对优秀员工提供购房津贴。由于公司的规模不大，我们一直以招聘二类本科应届生为主，在内部采取导师制的培养模式，为他们提供至少一年的严格训练，帮助他们规划职业生涯，想尽办法提供机会将他们培养成优秀的人才。这些年来不少公司打电话向我们公司挖人，关键人才从未出现过流失，至今跳槽的员工不超过12人，我深深地感到这就是我人生最大的快乐和财富，离开了支持我的用户和追随我的人才，我将变得一钱不值。
为了保证企业的可持续发展所带来的人才困境，我与江西理工大学合作以五年为期开办了“3＋1”嵌入式系统应用开发特训班，与此同时还设立了每人3000元共10人的“周立功奖学金”资助那些动手能力极强而成绩中等的学生，开展校企无缝联接，培养嵌入式系统创新性开发人才的有益尝试，即就是从7个班中选拔30位爱好者用3年的时间修完所有课程，我们为每一位学生提供一台计算机、全套开发工具及其设计中所发生的一切费用，由我们组织著名专家开设专题讲座和课程，学校组织1位专职辅导员和2位指导教师，并由我们提供必要的津贴，然后用一年的时间专门做毕业设计，为此我们制定了严谨、细致的培训计划。
这些年我们还不断赞助各省电子大赛、毕业设计大赛、创新设计大赛，捐赠了50所大学单片机创新实验室，以求扩大企业的知名度和广泛寻求人才的来源。

最后的话
很多开发工程师以为这些都是老板或者经理们应该考虑的问题，与己无关，其实是大错而特错。作为一位优秀而卓越的开发人员，如果希望获得人生的完全成功和快乐，我们时刻需要明白，任何一个企业的可持续发展一定是群策群力的结果。
1981年我经历了高考失败之后上了技校，1999年我作为劳动模范被保送上了大学，创业至今十多年来，往事依然历历在目，用户给予我的回报很多，很难在此一一完全道来，谨以此文与同行、用户分享和交流。
这些年来，我陆续捐资资助教育、设立奖学金以及帮助家乡修建乡村水泥公路、祠堂等公益事业回馈社会。1990年的中秋节，我只身一人南下广东打工，不曾想到会有今天这样的成绩，我一直非常珍惜这来之不易的机会。
作为一个嵌入式技术爱好者，我的愿望就是：“生命不息、奋斗不止！”力争为发展中国的嵌入式系统应用技术贡献自己的一份力量。

Windows CE下驱动开发基础

作者：付林林

　　这是我从1月6日开始主持天极网论坛嵌入式开发版以来第一次发表文章，加上以前琐碎的文章共计30篇。研究的越多就越感觉自己懂的太少，其实在驱动开发方面我还是个菜鸟，我是想再次抛砖引玉，让做驱动有N年经验的人奉献一点出来，让大家减少一些研究驱动源码而又缺少注释所带来的痛苦。
　　我想即使读者看过微软的关于驱动开发的培训教材和CE帮助文档中的驱动部分，头脑中仍然一片茫然。要想真正了解驱动程序必须结合一些驱动程序源码，在此我以串口驱动程序（COM16550）中初始化过程为线索简单讲一讲驱动开发的基础知识。
　　Windows CE下的串口驱动程序能够处理所有I/O行为类似串口的设备，包括基于16450、16550 UART（通用异步收发芯片）的设备和一些采用DMA的设备，常见的有9针串口、红外I/O口、Modem等。在%_WINCEROOT%\Public\Common\OAK\Drivers\Serial目录下，COM_MDD2子目录包含新的串口驱动MDD层函数代码。COM16550子目录包含串口驱动PDD层代码。SER16550子目录包含的一系列函数专用于控制与16550兼容的UART，这样PDD层的主要工作就是调用SER16550中的函数。还有一个ISR16550子目录包含的是串口驱动程序专用的可安装ISR（中断服务例程），而很多硬件设备驱动程序采用CE默认的可安装ISR giisr.dll。一般串口设备相应的注册表设置例子及意义如下：

　　SysIntr由CE在文件Nkintr.h中预定义，用于唯一标识中断设备。OEM可以在文件Oalintr.h中定义自己的SysIntr。常见的预定义SysIntr有SYSINTR_NOP（中断只由ISR处理，IST不再处理），SYSINTR_RESCHED（重新调度线程），SYSINTR_DEVICES（由CE预定义的设备中断ID的基值），SYSINTR_PROFILE、SYSINTR_TIMING、SYSINTR_FIRMWARE等都是基于SYSINTR_DEVICES定义的。IoBase是串口1的IO地址空间的首地址，IoLen是IO空间的大小。IO地址空间只存在于x86平台，如果在其它平台硬件寄存器必须映射到物理地址空间，那子键的名称为MemBase和MemLen。在x86平台更多硬件的寄存器由于IO空间的局限也映射到物理地址空间。DeviceArrayIndex是设备的索引，用于区分同类型的设备。Prefix是流驱动程序的前缀，当应用程序调用CreateFile函数传递COM1:参数时，文件系统负责与串口驱动程序通信，串口驱动程序是在CE启动时由device.exe加载的。

　　下面从MDD层函数COM_Init开始探索串口驱动的初始化过程。COM_Init是在串口设备被检测后由设备管理器device.exe调用的，主要的作用是初始化设备，它的唯一参数Identifier是由device.exe传递的，其类型是一个字符串指针，字符串的内容是HLM\Drivers\Active\xx，xx是一个十进制数（device.exe会跟踪系统中每个驱动程序，把加载的驱动程序记录在Active键下）。COM_Init先分配一个HW_INDEP_INFO结构体，这个结构体是独立于串口硬件的头信息（MDD、PDD、SER16550都包含自己独特的结构体，具体的结构体定义请参见串口驱动源码），分配之后再初始化结构体中每个成员，初始化结构体后调用 OpenDeviceKey((LPCTSTR)Identifier)打开HLM\Drivers\Active\xx\Key包含的注册表路径，在这里路径一般为HLM\Drivers\BuiltIn\Serial，即串口的驱动程序信息在注册表中所处的位置。COM_Init接着在HLM\Drivers\BuiltIn\Serial下查询DeviceArrayIndex、Priority256的值，Priority256指定了驱动程序的优先级，如果没有就用默认的优先级。接下来调用GetSerialObject(DeviceArrayIndex)，这个函数由PDD层定义，返回HWOBJ结构体，这个结构体主要包含PDD层和SER16550定义的函数的指针。也就是说MDD通过调用这个函数才能调用底层实现的函数。接下来的大多数工作都是调用底层函数实现初始化。第一个调用的底层函数SerInit主要设置由用户设置的硬件配置，例如线路控制、波特率。它调用Ser_GetRegistryData函数得到保存在注册表中的硬件信息，Ser_GetRegistryData在内部调用系统提供的DDKReg_GetIsrInfoDDK和DDKReg_GetWindowInfo函数得到在HLM\Drivers\BuiltIn\Serial下保存的IRQ、SysIntr、IsrDll、IsrHandler、IoBase、IoLen。IRQ是逻辑中断号，IsrDll表示当前驱动程序的可安装ISR所在的DLL名称，IsrHandler 表示可安装ISR的函数名称。在这里顺便提一下可安装ISR，读者在我以前发表的关于OAL的文章中可以了解到OEM在OEMInit函数中关联IRQ和SysIntr，当硬件设备发生中断时，ISR会禁止同级和低级中断，然后根据IRQ返回关联的SysIntr，内核根据ISR返回的SysIntr唤醒相应的IST（SysIntr与IST创建的Event关联），IST处理中断之后调用InterruptDone解除中断禁止。在OEMInit中关联的缺点是一旦编译了CE内核后就无法添加这种关联了，而一些硬件设备会随时插拔或者共享中断，要关联这样的硬件设备解决方法就是可安装ISR，可安装ISR专用于处理指定的硬件设备发出的中断，所以如果硬件设备需要可安装ISR必须在注册表中添加IsrDll、IsrHandler。多数硬件设备采用CE默认的可安装ISR giisr.dll，格式如下：

 "IsrDll"="giisr.dll"
"IsrHandler"="ISRHandler"

　　如果一个硬件驱动程序需要可安装ISR而开发者又不想自己写一个，那么可以利用giisr.dll来实现。除了在注册表中添加如上所示外，还要在驱动程序中调用相关函数注册可安装ISR。伪代码如下：

g_IsrHandle = LoadIntChainHandler(IsrDll, IsrHandler, (BYTE)Irq);
GIISR_INFO Info;
PHYSICAL_ADDRESS PortAddress = {PhysAddr, 0};
TransBusAddrToStatic(BusType, dwBusNumber, PortAddress, dwAddrLen, &dwIOSpace, &(PVOID)PhysAddr)
Info.SysIntr = dwSysIntr;
Info.CheckPort = TRUE;
Info.PortIsIO = (dwIOSpace) ? TRUE : FALSE;
Info.UseMaskReg = TRUE;
Info.PortAddr = PhysAddr + 0x0C;
Info.PortSize = sizeof(DWORD);
Info.MaskAddr = PhysAddr + 0x10;
KernelLibIoControl(g_IsrHandle, IOCTL_GIISR_INFO, &Info, sizeof(Info), NULL, 0, NULL);

　　LoadIntChainHandler函数负责注册可安装ISR，参数1为DLL名称，参数2为ISR函数名称，参数3为IRQ。TransBusAddrToStatic函数在后面讲。如果要利用giisr.dll作为可安装ISR，必须先填充GIISR_INFO结构体，CheckPort=TRUE表示giisr要检测指定的寄存器来确定当前发出中断的是否是这个设备。PortIsIO表示寄存器地址属于哪个地址空间，FALSE表示是内定空间，TRUE表示IO空间。UseMaskReg=TRUE表示设备有一个掩码寄存器，专用于指定当前设备是否是中断源，也就是发出中断，而MaskAddr表示掩码寄存器的地址。如果对Info.Mask赋值，那么PortAddr表示一个特殊的寄存器地址，这个寄存器的值与Mask的值&运算的结果如果为真，则证明当前设备是中断源，否则返回SYSINTR_CHAIN（表示当前ISR没有处理中断，内核将调用ISR链中下一个ISR），如果UseMaskReg=TRUE，那么MaskReg寄存器的值与PortAddr指定的寄存器的值&运算的结果如果为真，则证明当前设备是中断源。
　　函数SerInit接着调用函数Ser_InternalMapRegisterAddresses转换IO地址并且映射地址，Ser_InternalMapRegisterAddresses在内部调用系统提供的HalTranslateBusAddress(Isa, 0, ioPhysicalBase, &inIoSpace, &ioPhysicalBase)函数将与总线相关的地址转换为系统地址，参数1为总线类型，参数2为总线号，参数3为要转换的地址（PHYSICAL_ADDRESS类型，实际是LARGE_INTEGER型），参数4指定寄存器地址属于IO地址空间还是物理地址空间，参数5返回转换后的物理地址。观察HalTranslateBusAddress的源码得知如果是在x86平台，这个函数除了把参数3赋给了参数5其余什么都没有做，而非x86平台将inIoSpace的值置为0，表示一定是物理地址。在调用HalTranslateBusAddress前要确定从注册表中得到的寄存器地址到底是属于哪个地址空间的，例如：

ULONG inIoSpace = 1; ///1表示是IO空间
PHYSICAL_ADDRESS ioPhysicalBase = {iobase, 0}; ///相当于ioPhysicalBase.LowPart = iobase

　　在地址转换后就要将转换后的地址映射到驱动程序（一般IST和应用程序一样运行在用户模式）能够访问的虚拟地址空间（0x80000000以下）和ISR能够访问的静态虚拟地址空间中（0x80000000以上）。例如：

////如果地址属于物理地址空间
ioPortBase = (PUCHAR)MmMapIoSpace(ioPhysicalBase, Size, FALSE);
TransBusAddrToStatic(Isa, 0, ioPhysicalBase, Size, &inIoSpace, ppStaticAddress);

　　MmMapIoSpace函数负责将物理地址映射到驱动程序能够访问的虚拟地址空间中，通过源码分析MmMapIoSpace在内部分别调用：

pVirtualAddress =VirtualAlloc(0, SourceSize, MEM_RESERVE, PAGE_NOACCESS);
VirtualCopy(pVirtualAddress, (PVOID)(SourcePhys >> 8), SourceSize, PAGE_PHYSICAL | 
PAGE_READWRITE | (CacheEnable ? 0 : PAGE_NOCACHE));

　　VirtualAlloc分配一块和MemLen一样大小的虚拟地址空间，因为参数1为0，所以内核自动分配。一般MemLen小于2MB，所以会在应用程序的地址空间中分配。VirtualCopy负责将硬件设备寄存器的物理地址与VirtualAlloc分配的虚拟地址做一个映射关系，这样驱动程序访问PvirtualAddress实际上就是访问第一个寄存器。因为硬件设备寄存器的物理地址一定是在512MB（CE支持RAM的最大值）以上，所以除了最后的参数要加PAGE_PHYSICAL外，第二个参数物理地址也要右移8位（或者除以256）。映射硬件寄存器当然PAGE_NOCACHE是必须加的。TransBusAddrToStatic函数负责将物理地址映射到ISR能够访问的静态虚拟地址空间中，当出现中断共享时，ISR要负责访问硬件设备的某一个寄存器来判断中断源，所以将寄存器的物理地址映射到静态虚拟地址空间中是必要的（ISR只能访问静态的虚拟地址空间）。所谓静态虚拟地址空间是指在OEMAddressTable中定义的虚拟地址空间（当然是0x80000000以上）。在x86平台一般这个表只定义RAM的物理地址与虚拟地址对应关系，而硬件设备的寄存器地址并不在该表中定义，所以如果要创建一块静态的虚拟地址空间供ISR访问，必须在此之前调用CreateStaticMapping函数在0xC4000000到0xE0000000虚拟地址空间中分配。TransBusAddrToStatic函数在内部就是调用了CreateStaticMapping函数。注：硬件设备的寄存器地址也可以在OEMAddressTable中定义。

////如果地址属于IO空间
ioPortBase = (PUCHAR)ioPhysicalBase.LowPart;
*ppStaticAddress=ioPortBase

这种情况只属于x86平台，是IO空间就可以直接访问，即使是用户模式。
　　SerInit函数接着初始化SER_INFO结构体成员，之后调用SL_Init函数，这个函数在ser16550中定义，负责初始化SER16550_INFO结构体，在这个结构体中保存串口8个寄存器的地址。SerInit函数执行完毕后COM_Init函数创建接收缓冲区，然后调用StartDispatchThread函数初始化中断并且创建IST。StartDispatchThread函数在内部调用InterruptInitialize函数关联SysIntr和Event，然后调用InterruptDone函数告诉内核当前串口可以中断处理，接着调用CreateThread函数创建IST线程。（over吧，再往下说就和串口硬件有关了，看多了没注释的代码我也烦！！）

写作时间：2005-03-25

如果您有技术问题向我咨询请登录天极网论坛嵌入式开发版

未经本文作者同意，不准擅自转载本篇文章。联系作者请邮至windowsce@tom.com或fllsoft@sina.com

最新评论 [发表评论] [文章投稿]

查看所有评论 推荐给好友 打印

写的太好了 看完你的这篇文章，再去看串口代码，一目了然 ( daemon2005 发表于 2005-5-30 13:15:00)   写得非常精彩，能画张图表示一下就好了，俺也真正琢磨COM口驱动，真的是很经典。 ( liu_sir 发表于 2005-5-7 10:53:00)   ....................................................... More...

在 Windows CE 下申请大容量物理内存

作者：付林林

　　申请大容量的物理内存看起来不是难事。这里的大容量是指几十MB甚至更多的物理内存。对于C++程序员来说可能平时习惯了使用"new"操作符来实现。我也是这样。使用"new"非常简单，申请之后只需判断返回的指针是否是空即可。在其它的Windows操作系统上的确不需要在申请大容量物理内存上过多考虑。但是在Windows CE上就不同了。如果只用"new"就能搞定，那就太省事了。
　　不知道Windows CE下软件开发者是否遇到过这种情况，如果使用"new"申请超过30MB的物理内存，那么返回的一定是空（NULL），甚至程序会死锁无法响应。这其实不奇怪。在《Windows CE下进程、线程和内存管理》的系列文章中我早有所言，Windows CE下每个进程占有32MB的地址空间，虽然Slot 1槽存放所有的非XIP DLL，但是我们不可能占用Slot 1槽。32MB地址空间减去必要的代码段、静态数据段、默认堆和默认栈之后，所剩的地址空间少于32MB。即使程序什么都不做也无法满足超过30MB的地址空间的申请需求。所以返回为空非常正常。好在Windows CE下运行的大多数软件不需要那么多的物理内存。
　　感觉微软的技术不是支持到很远的将来，而是得过且过，只要满足目前的和不远的将来的需求就行。拿Platform Builder来说，IMGRAM64环境变量用于支持64MB物理内存。可是没有IMGRAM128或者IMGRAM256甚至IMGRAM512。可能是当时绝大多数基于Windows CE的产品都没有超过64MB物理内存。现在要支持超过64MB物理内存就必须做一些修改操作。再如现在说的用"new"分配物理内存，也只是限制在32MB以内。如果想new多少就new多少，那多爽!
　　"new"不行是因为地址空间不够，那我们可以采用虚拟内存分配，然后提交物理内存这种办法。理论上是这样，但是实际上还是不行。举例如下：

LPVOID  g_Address1, g_Address2;
g_Address1 = VirtualAlloc(0, 32 * 1024 * 1024, MEM_RESERVE, PAGE_NOACCESS);
g_Address2 = VirtualAlloc(g_Address1, 32 * 1024 * 1024, MEM_COMMIT, PAGE_READWRITE);

#define  MAXLEN  (64*1024*1024)
HANDLE  hFile;
hFile = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, MAXLEN, NULL);
if(hFile == NULL)
{
	//创建文件映射对象失败
	return;
}

LPVOID  lpAddress;
lpAddress = MapViewOfFile(hFile, FILE_MAP_WRITE|FILE_MAP_READ, 0, 0, MAXLEN);

if(lpAddress == NULL)
{
	//创建文件视图失败
	return;
}

最新评论 [发表评论] [文章投稿]

查看所有评论 推荐给好友 打印

欢迎大家到天极网嵌入式开发论坛http://club.yesky.com/bbs/jsp/list.jsp?forumID=378 ( fllsoft 发表于 2005-1-21 9:26:00)   这篇文章争议很大啊！等我把驱动部分研究透了再回头客观评价这篇文章。如果是错的我会纠正的。 ( fllsoft 发表于 2004-12-23 8:11:00)   回fllsoft "2、你以为你能轻易的得到物理内存的地址吗？你还好意思说你做了很久，我早就说过，只有自定义CE内核，你才真正懂得CE。当CE内核启动时，会将物理地址0映射到0x80000000。" 你说的这点，我表示怀疑 ce内核启动时，我这块arm板子，是把sdram物理内存映射到0x8000 0000,而不是把用作启动的rom 0000 0000地址开头的空间映射 到0x8000 0000 希望和你进行更多的交流 ( yiiang 发表于 2004-12-14 15:14:00)   “Windows CE supports both named and unnamed file-mapping objects. Unnamed files provide a method both for interprocess communication and as a way to allocate virtual memory regions larger than the 32-MB slot size limit. ”CE帮助文档的原话。充分说明了在CE中用内存映射技术来申请超过32MB的虚拟内存空间是合理的。 ( fllsoft 发表于 2004-9-15 14:48:00)   申请物理内存首先要申请虚拟空间，这是不争的事实。所以本篇文章讲的就是如何申请到足够的虚拟空间。你如果知道还说废话，实在是没必要。另外你的言语实在刻薄，原谅你没有收到良好的道德教育。 ( fllsoft 发表于 2004-9-15 8:23:00)   我不再做任何争辩了，如果你喜欢就自己接着说吧。 ( nbcool 发表于 2004-9-14 22:02:00)   "在 Windows CE 下申请大容量物理内存" “物理内存的首地址是lpAddress” 这是你文章的标题和内容，这完全说明不懂得区分物理内存和虚拟内存的人是你,要不然你就不会犯这种低级错误！ 简直让人贻笑大方。我也看到了你作为“井底之蛙”的本性，别人提意见，你就这种态度。 我是设备制造商，当然知道如何写虚拟内存和物理内存的映射算法和CE内核工作原理，不过你既然这么要面子，犯了错还遮遮掩掩，我就没必要再多说了，就此打住，争辩也没必要了。 ( nbcool 发表于 2004-9-14 21:52:00)   nbcool，你如果对我所有文章还有疑意，可以通过Email或者MSN交流。不要连虚拟地址和物理地址关系都不懂还要乱讲话。OK？ ( fllsoft 发表于 2004-9-14 9:09:00)   回应你的话： 1、你还不懂得虚拟地址和物理地址的关系。从程序员的角度讲，所有接触的地址都是进程的虚拟地址，你不会接触到实际的物理地址，而且也没必要得到实际的物理地址。举个最简单的例子，你用new得到的地址是虚拟地址，而不是实际的物理地址。每当申请物理内存时，操作系统内核会在进程的地址空间申请足够的空间，然后提交一部分物理内存，映射虚拟地址和物理地址。你不懂可以看看《windows核心编程》。所以整个文章中提到的都是虚拟地址。 2、你以为你能轻易的得到物理内存的地址吗？你还好意思说你做了很久，我早就说过，只有自定义CE内核，你才真正懂得CE。当CE内核启动时，会将物理地址0映射到0x80000000。就连CE的内核工作时都是使用虚拟地址。你还以为你申请的内存返回的地址是实际物理地址。蠢！ 3、我的《windows ce进程、线程、内存管理》非常明确的提出进程的地址空间应该是64MB，slot1专用于加载XIP DLL。你可以看看，我早就告诉你要仔细看我的文章。你没有仔细看！ ( fllsoft 发表于 2004-9-14 8:58:00)   前面我的话是有些过分了。如果要说到试验，我从PalmSize-PC开始就做过开发。相信我对WinCE以及WinCE.NET理解还是有一定程度的。 1.CreateFileMapping本来就是在虚拟内存中操作，然后通过映射回写到文件。你却把它叫做申请“物理内存”，简直让人十分奇怪，而且0x4200 0000以上是[Large Memory Area]，是在2G虚拟地址空间之内，又说明了你想说的是虚拟内存地址。 2.你这篇文章有点过时了，因为在WinCE.NET中slot1是可以被占用的，一个活动的应用程序理论上可以有64MB可用虚拟地址空间。 3.VirtualAlloc 在分配2M以上空间的时候，才会在[Large Memory Area]中分配。提交时没必要一次提交32M，一般是64K的倍数，否则一次提交32M，建立物理内存到虚拟内存的映射时，命中率会大大下降，这时，完全不能说明VirtualAlloc 不能一次提交32M的结论，因为系统可能这时根本无法找到32M可用物理内存了。 4.MapViewOfFile返回的指针是虚拟地址空间的，而不是物理内存首地址。 不否认你写的有正确的部分，但还有不少问题，我以前也浏览过你的前几篇文章，确实也存在不少问题。我也不想对你写的文章评论太多，不然你又要不高兴了。 既然你没看过Douglas Boling 的著作，那么推荐你去看看，MSDN 中的部分内容也是由他编写的，他被誉为是对 Windows CE 理解最完美的人之一。你所通过实验得到的一些方法，在他最新的第三版著作中，都有系统的总结和分析。 再给你看一篇文章， http://www.microsoft.com/china/MSDN/library/windev/WindowsCE/WCEdncenetadvmemmgmt.mspx 对你改进本文有所帮助。 ( nbcool 发表于 2004-9-13 23:00:00)   ....................................................... More...

Windows CE下拨号上网

作者：付林林

　　目前基于Windows CE的产品大多数具有上网功能，能够连接到Internet实现浏览网页、收发邮件等基本功能。要实现更多的功能取决于连接Internet的速度，而速度取决于连接Internet的方式。连接Internet的方式分为两种：有线和无线。事实上大多数产品还是采用无线上网方式。
　　基于Windows mobile的Pocket PC和Smart phone能够轻松实现上网功能。这两种产品的软件开发人员可以不必过多考虑如何实现拨号上网。而对于采用定制Windows CE内核的产品而言，相关的软件开发人员必须自己实现拨号上网。幸运的是Windows CE的SDK中包含了拨号上网的支持，使软件开发人员的工作大大减轻。
　　拨号上网的硬件设备可以是独立的带内置调制解调器和具有GPRS功能的手机，也可以是嵌入到主板中带有同样功能的手机芯片。具体是什么并不重要，因为Windows CE包含的拨号上网模块采用标准的AT命令集与硬件设备通信。软件开发人员可以直接利用CE提供的接口函数来控制整个拨号过程，直到断开连接。
　　Windows CE.NET 提供了一个被称为RAS（Remote Access Service）的服务，通过RAS基于Windows CE的产品可以通过WAN（广域网）或VPN（虚拟个人网络）连接到远程服务器上。调用RAS的应用程序通常在客户机上执行，通过电话网连接到远程服务器，这种连接使用两种标准的远程访问协议：PPP点对点协议和SLIP串行线路Internet协议。RAS结构如图1所示。从图中可以看出RAS处于ISO/OSI模型的上层，下层的TAPI（电话API）调用Unimodem，Unimodem是通用的调制解调器驱动程序，它调用串口API实现与调制解调设备的通信。


图1 RAS服务结构图

　　Windows CE.NET下RAS所具备的所有功能同PC下的相似，同样支持电话本、拨号控制脚本。不同的是CE下的RAS的电话本是存放在注册表中。这些都是次要的功能，在此不给予讲述。实现拨号必须调用的函数如下：

　　基于Windows CE的产品在设计上有的能够在断电前保存注册表数据，有的不能够。对于不能够保存注册表数据的产品，采用电话本来拨号是行不通的。只能让用户每次启动后重新输入拨号数据，或者将数据保存到永久存储器上，在下一次拨号程序启动时先读取拨号数据。
　　整个拨号状态分为同步和异步两种。同步状态下RasDial函数直到建立连接或者发生错误不能继续工作时才返回。同步模式的缺点是客户不能收到连接操作的当前状态和进度信息。但是仍然有解决方法，办法是创建一个新的线程来进行拨号（调用RasDial），另外创建一个新的线程每隔一段时间查询当前拨号状态（调用RasGetConnectStatus）。相比较异步模式在得到当前拨号状态方面要容易的多。异步模式下RasDial函数会立刻返回，接着可以调用RasGetConnectStatus得到当前拨号状态。
　　RasGetEntryDialParams和RasGetEntryProperties两个函数得到的是不同方面的数据。在此做一说明：CE为DialPrarms拨号参数定义了结构体RASDIALPARAMS。它包括拨号记录名、电话号码、用户名、密码、域名等。而对于Properties属性数据，CE定义了结构体RASENTRY。它包括连接选项、国家码、区域码、本地电话号，可以指定本地IP地址、远程DNS服务器IP、远程WINS服务器IP等，还可以指定连接控制脚本文件路径、采用的协议、调制解调器类型及名称等。在拨号前一定要设置要这些参数，不过不必每个参数都设置。最简单的办法是得到系统默认的所有参数。调用代码如下：

DWORD dwReturn;
dwReturn = RasGetEntryProperties(NULL, L"", &RasEntry, &dwSize, NULL, NULL); 
if(dwReturn != 0)    
{	
	////不能得到系统拨号参数
	return;	
}

最新评论 [发表评论] [文章投稿]

查看所有评论 推荐给好友 打印

欢迎大家到天极网嵌入式开发论坛http://club.yesky.com/bbs/jsp/list.jsp?forumID=378 ( fllsoft 发表于 2005-1-21 9:26:00)   我写的都是开发过的。没有研究或者开发过的不会随意写。另外如果有错误我会及时的在评论中指出错误和改正的结果。谢谢大家关注。 ( fllsoft 发表于 2004-8-24 16:30:00)   不错,希望大侠能写一些关于通讯方面的文章: 比如蓝牙接口,USb接口(可能这类的主控PDA还没出) ( liu_sir 发表于 2004-8-20 9:23:00)   我的MSN：windowsce@tom.com 。 大家可以用MSN与我联系。 ( fllsoft 发表于 2004-8-19 12:17:00)   ....................................................... More...

Windows CE 进程、线程和内存管理（三）


作者：付林林

三、内存管理

　　同其它Windows操作系统一样，Windows CE.NET也支持32位虚拟内存机制、按需分配内存和内存映射文件等。但是与其它Windows操作系统又有明显的不同。毕竟Windows CE是一种嵌入式实时性的操作系统，在内存管理方面必须要比其它Windows操作系统更节约物理内存和虚拟地址空间。在内存管理API方面，为了便于移植程序，Windows CE和其它Windows操作系统函数声明基本一致，这使一个在其它Windows下开发的程序员可以直接使用早就熟悉的API函数， 但是CE下内存管理的原理开发者还是应该熟悉的。

1、ROM和RAM
　　最早的基于Windows CE的民用产品，采用的存储设备都是ROM ＋ RAM ，ROM保存CE内核文件、应用程序，而RAM用于内核、所有应用程序运行时使用，关闭电源时必须给RAM提供电力来保存系统配置信息、用户产生的文件等。为了适应这样的存储硬件，CE采用了ROM文件系统和RAM文件系统。在ROM中存放的模块可以是压缩的，也可以是不压缩的，这取决于OEM。OEM在定制内核时可以设置是否压缩模块。如果是压缩的，模块在运行前先解压并全部存放到RAM中。如果是不压缩的，就本地执行（XIP，executed in place）。本地执行和其它Windows操作系统下执行应用程序、DLL方式一致，也就是应用了内存映射文件技术。在这里我顺便讲一下。在启动时应用程序或DLL的代码段不加载到物理内存中，内核只是分配虚拟地址空间给代码段，当执行代码时内核会到实际存放在硬盘上的文件中寻找代码并执行。采用这样的技术既可以节省可用内存又可以减少加载的时间。请注意，操作系统首先会到为硬盘准备的缓冲区里读取代码数据，如果没有就命令硬盘读取应用程序文件数据到缓冲区。所以缓冲区设置大点是有好处的。Windows CE的本地执行就是采用这样的技术来加载ROM内的应用程序和DLL的。所以Windows CE的DLL分为XIP DLL和非XIP DLL。这种加载方式的缺点就是执行相对较慢一点，如果用PB创建一个具有实时性特点的内核，一定不能选用XIP技术。
　　到后来基于Windows CE的产品开始采用FLASH、IDE等永久存储设备时，文件系统又加了个FAT。内核文件和其它应用程序也可以存放到永久存储设备中，内核由加载程序解压并加载到RAM的对象存储区域（object store），包含在内核中的所有系统应用程序文件和DLL文件都存放到这个区域。当执行一个应用程序时，内核将这个应用程序调用的系统DLL加载到Slot 1（0x0200 0000－0x03FF FFFF）。在Windows CE.NET中Slot 1专用于XIP DLL使用。
　　RAM文件系统专用于对象存储。在以前的文章中曾经讲过，它和ROM文件系统是Windows CE默认的文件系统。Windows CE启动后把RAM分为对象存储区域（object store）和应用程序内存区域（program memory）。对象存储区域采用RAM文件系统来保存文件，一般用于保存内核解开的所有文件。应用程序内存区域留给所有应用程序运行时使用。在Windows CE下"控制面板"－"系统"－"内存"中，可以调节这两个存储区域的比例，滑块向左，则释放对象存储区域的一些内存并将这些内存划到应用程序内存区域中。滑块向右则相反。

2、内存结构
　　Windows CE.NET只能管理512MB的物理内存和4GB大小的虚拟地址空间。不同的CPU内存管理方法也不同。对于MIPS和SHX系列CPU来说，物理地址映射是由CPU完成的，CE内核可以直接访问512MB的物理内存。对于x86系列和ARM系列的CPU来说，在内核启动过程中它会将现有物理内存地址全部映射到0x8000 0000以上的虚拟地址空间中供内核以后使用。OEM可以通过OEMAddressTable来详细定义虚拟地址和物理地址的映射关系。OEMAddressTable本身并不是一个文件，它只是存在于其它文件中描述虚拟地址和实际物理地址的映射关系的数据。比如文件oem init.asm中包含一段代码：dd 80000000h, 0, 04000000h 。它表示将整个物理地址（0x0400 0000＝64MB）共64MB映射到虚拟地址从0x8000 0000到0x8400 0000中。关于OEMAddressTable我将在以后关于PB的文章中讲述。
　　整个4GB虚拟地址空间主要划分为两部分，从0x8000 0000以上为内核使用部分，0x8000 0000以下为应用程序使用部分。详细见下表：

　

地址范围	用途
0x0000 0000到0x41FF FFFF	由所有应用程序使用。共33个槽，每个槽占32MB。槽0（Slot 0）由当前占有CPU的进程使用。槽1由XIP DLL使用。其它槽用于进程使用，每个进程占用一个槽。
0x4200 0000到0x7FFF FFFF	由所有应用程序共享的区域。32MB地址空间有时不能够满足一些进程的需求。那么进程可以使用这个范围的地址空间。在这个区域里应用程序可以建堆、创建内存映射文件、分配大的地址空间等。
0xA000 0000到0xBFFF FFFF	在这个范围内核重复定义0x8000 0000到0x9FFF FFFF之间定义的物理地址映射空间。区别是在这范围映射的虚拟地址空间不能够用于缓冲。 　　我举例来说明：假设一个产品有64MB物理内存。如上文所述定义好OEMAddressTable后。内核启动后一个物理地址映射空间范围在0x8000 0000到0x8400 0000，那么内核会从0xA000 0000到0xA400 0000定义一个同样范围的地址空间，这个地址空间和0x8000 0000到0x8400 0000映射到相同的物理地址。但这个虚拟地址空间不能够用于缓冲。
0xC000 0000到0xC1FF FFFF	系统保留空间
0xC200 0000到0xC3FF FFFF	内核程序nk.exe使用的地址空间。
0xC400 0000到0xDFFF FFFF	这个范围为用户定义的静态虚拟地址空间，但这个地址空间只能用于非缓冲使用。 　　利用OEMAddressTable定义物理地址映射空间后，每次内核启动时这个范围都不改变了，除非产品包含的物理内存容量发生变化。假如增加到128MB物理内存，那么物理地址映射空间也向后扩大了一倍。Windows CE.NET也允许用户创建静态的物理地址映射空间。用户可以调用CreateStaticMapping函数或者NKCreateStaticMapping函数来映射某一段物理地址到0xC400 0000和0xE000 0000之间的某一个范围。需要注意的是用这个函数创建的静态虚拟地址只能够由内核访问，而且不能用于缓冲。
0xE000 0000到0xFFFF FFFF	内核使用的虚拟地址。当内核需要大的虚拟地址空间时，会在这个范围内分配。

图1 Windows CE.NET内存结构

3、进程地址空间结构
　　进程地址空间结构如图2所示。这个图源至MSDN。Windows CE.NET同以前版本的Windows CE操作系统在进程地址空间上有所不同，以前的Windows CE把XIP DLL也加载到进程的32MB地址空间中，而Windows CE.NET把XIP DLL单独加载到Slot 1中，这样对于每个进程来说，它总的地址空间就大了一倍，也就是64MB。这个问题我在讲解进程的时候提到过。
　　当一个应用程序启动时，内核为这个程序选择一个空闲的槽（Slot），并且加载所有的代码、资源，并分配堆栈，加载DLL等。当这个进程得到CPU使用权时，它的整个地址空间被内核映射到Slot 0，也就是当前进程使用的地址空间，然后开始运行。图中给出的地址实际上是经过映射到Slot 0之后的结构。从图中可以看出，进程首先加载代码段，因为每个进程最低部64KB作为保留区域，所以代码段从0x0001 0000开始，内核为代码段分配足够的虚拟地址空间后，接着分配空间为只读数据和可读/可写数据，接着分配空间为资源数据，之后分配空间为默认堆和栈。非XIP DLL从进程最高地址向下开始加载。非XIP DLL的加载按如下规则：内核先检查要加载的DLL是否被其它进程加载过，如果加载过，就做一个地址的重定位。这样就避免了整个系统内多次加载相同DLL。如果没有加载过，就按照从槽的高地址到槽的低地址的顺序查找空闲的地址空间。然后分配足够的地址空间用于加载DLL。因为每个进程在执行前都要映射到Slot 0，而且进程使用的所有DLL可能来自不同的槽（Slot），为避免所有使用的DLL在映射到Slot 0中出现地址空间冲突的现象，内核的加载器（Loader）在加载DLL时会查找所有槽中加载的DLL的地址，保证在映射到Slot 0时不会发生地址冲突现象。假如系统内有两个进程，进程A只加载了DLL A，进程B需要加载DLL A和DLL B，那么进程B会留出DLL A的地址空间，然后加载DLL B，也就是说进程B映射到Slot 0时，DLL A的地址空间和DLL B的地址空间是相邻的，不会发生冲突。好在Windows CE下DLL都很小，而且一个应用程序使用的DLL多数是系统的DLL（存在于Slot 1）。所以目前来看进程的地址空间还够用。


图2 进程地址空间结构

4、堆和栈
　　堆是一段连续的较大的虚拟地址空间。应用程序在堆中可以动态地分配、释放所需大小的内存块。利用堆的优点是在一定范围内减小了内存碎块。而且开发者分配内存块前不必去了解CPU的类型。因为不同的CPU分页大小不相同，每个内存页可能是1KB、4KB或更多。在堆内分配内存块可以是任意大小的，而直接分配内存就必须以内存页为单位。当一个应用程序启动时，内核在进程所在的地址空间中为进程分配一个默认192KB大小的虚拟地址空间，但是并不立刻提交物理内存。如果在运行当中192KB不能满足需求，那么内核会在进程地址空间中重新查找一个足够大小的空闲的地址空间，然后复制原来堆的数据，最后释放原来的堆所占的地址空间。这是因为默认的堆的高地址处还有栈，所以必须重新分配一个。Windows CE.NET的堆有明显的缺点，不同于其它Windows操作系统下的堆管理，在Windows CE.NET创建的堆中创建的内存块不能够移动，多次创建内存块、释放内存块会产生内存碎块，这样的话当需要分配一个大一点的连续的内存块时，本来空闲的内存块加起来足够用，但是这些内存块是分隔的，不符合要求。像Windows 2000或98的内核会频繁的移动分散的正使用的内存块，使它们聚集在一起。这也是为什么有时需要句柄而不用指针的原因。由于Windows CE.NET的堆的缺点，开发者如果要频繁的在堆中创建、释放内存块的话，最好自己创建一个单独的堆，而不用默认的堆。而且我还建议最好直接在全局地址空间中（0x4200 0000到0x7FFF FFFF）分配所需地址空间。因为进程地址空间可用的实在太小了。关于堆函数我在这就不多说了，和其它Windows操作系统堆API基本一致。请参考帮助文档。
　　栈也是一段连续的虚拟地址空间，和堆相比空间要小的多，它是专为函数使用的。当调用一个函数时（包括线程），内核会产生一个默认的栈，并且内核会立刻提交少量的物理内存（也可以禁止内核立刻提交物理内存）。栈的大小和CPU有关，一般为64KB，并且保留顶部2KB为了防止溢出。可以修改栈的大小，具体修改方法在讲解线程的时候已经说过了，这里就不再重复了。修改栈的大小一般时候不会发生，如果采用在编译链接时修改大小，那么所有栈的大小都会改变，这不太合理。实际开发中最好不要在栈中分配很大、很多的内存块，如果分配的内存块超过了默认栈的限制，那么会引起访问非法并且内核会立刻终止进程。最好在进程的堆中分配大的内存块并且在函数返回前释放，或者在创建线程时指定栈的大小。

5、内存映射文件
　　与虚拟内存一样，内存映射文件用来保留一个地址空间，并提交物理存储器。早期的内存映射文件并不是提交物理内存供调用者使用，而是提交永久存储器上的文件数据。当然操作系统会为永久存储器保留一个读缓冲区，这样读取文件数据就快多了。内存映射文件的特点使它很适合于加载EXE或DLL文件。这样可以节省内存又减少了加载所需时间。还可以使用它来映射大容量的文件，这样就不必在读取文件数据前设置很大的缓冲区。另外内存映射文件常用于进程间通信，也是进程间通信的主要手段，其它进程之间通信机制都是基于内存映射文件来实现。为了更快的在进程之间通信，现在的内存映射文件也可以提交物理内存，这样内存映射文件既可以提交物理内存又可以提交文件。
　　Windows CE.NET同样支持无名和有名的内存映射文件。我建议在开发软件的过程中，如果需要读写大容量的文件，或者需要在不同进程内的线程之间通信，最好采用内存映射文件，而且最好在全局地址空间内（0x4200 0000到0x7FFF FFFF）分配。这会使我们事半功倍。

5.1 映射数据文件
　　第一步：调用CreateFileForMapping函数。在Windows CE.NET中推荐使用这个函数替代CreateFile函数。CreateFileForMapping函数由内核执行并创建文件，它也可以打开由CreateFile函数创建的文件。其参数同CreateFile相似。参数1指定文件路径，注意文件路径的格式是没有盘符的，参数2指定访问方式（读或写），参数3指定共享模式，参数4指定安全属性（必须设置为NULL），参数5指定是创建还是打开文件，参数6指定文件属性，参数7忽略。具体参数细节参见Windows CE.NET帮助。函数返回创建或者打开的文件的句柄。
　　第二步：调用CreateFileMapping函数。这个函数创建一个无名的或者有名的内存映射文件对象。参数1为文件句柄。这个值由CreateFileForMapping函数返回。参数2为安全属性（必须设置为NULL），参数3指定要映射的文件的保护属性（只读或者读写），参数4和参数5共同用于指定要映射的文件的大小。文件的容量过大将导致32位整数也不能表示，所以这里用64位变量表示，其中参数4为高32位数，参数5为低32位数。最后一个参数指定内存映射文件的名称。这里可以设置为NULL，表示不需要名字。
　　第三步：调用MapViewOfFile函数。这个函数用于保留一段足够的地址空间，并且将永久存储器上的文件数据映射到这个地址空间。映射后这段地址空间又叫做文件视图，映射范围可以是全部文件，也可以是部分文件。这里需要注意的是如果文件很大，那这个函数将在全局地址空间内分配地址空间。参数1指定内存映射文件对象的句柄，这个值由CreateFileMapping函数返回。参数2和CreateFileMapping函数中参数3很相似，都是用于限定访问权限。参数3和参数4共同用于指定映射区域的开始位置。其中参数3为高32位数，参数4为低32位数。参数5指定映射区域的大小。需要注意的是参数3和参数4指定的64位数开始位置可以不是64KB的倍数。而其它Windows操作系统就必须限制以64KB为单位。另外还要注意的是帮助文档中说不能保证一个文件的映射视图是连续的，并建议为了防止访问非法，应该加入结构化异常处理机制。这个可能性我认为很小，一般对于大于2MB的虚拟地址空间的申请，内核都会在全局地址空间中分配。全局地址空间（0x4200 0000到0x7FFF FFFF）近1GB的空间应该足够用了。毕竟Windows CE下的文件都很小。不过在代码中加入结构化异常处理也不是坏事。我们应该养成凡是读写文件数据时都加入结构化异常处理的习惯。
　　第四步：进行读/写操作。MapViewOfFile函数如果成功执行，那么返回映射视图的首地址。这时就可以把视图当成是一个缓冲区，开始读或写操作了。
　　第五步：执行结束工作。先调用UnmapViewOfFile函数撤销文件映射视图。参数只有一个，指定视图首地址。然后调用CloseHandle函数关闭内存映射文件对象，参数为句柄。最后再次调用CloseHandle函数，关闭打开的文件的句柄。

5.2 进程之间通信
　　进程之间有时需要通信。系统提供的进程之间的通信机制比如COM、剪贴板等，在底层实现上都是利用内存映射文件技术。其实进程之间通信的思路很简单，在这里我顺便讲一下。在其它Windows操作系统中，每个进程独自占有4GB的地址空间，高2GB是内核的地址空间，而低2GB是进程的地址空间。一个进程所能访问的所有低2GB地址都是自己的地址空间，当访问内核地址空间时就会受到内核的限制。这样一个进程当然无法访问其它进程了。为解决进程间通信的问题，内存映射文件技术被利用作为解决方案。原来内存映射文件只映射类似磁盘一类的存储器上的文件。而为了更快速地在进程之间通信，内存映射文件还可以提交物理内存。实现方法是通过访问同一个内存映射文件对象（映射到物理内存），两个进程或多个进程就能够访问到同一块物理内存，这样一个进程写到物理内存的数据，其它进程就能够看到了。而Windows CE虽然每个进程只占有32MB的地址空间，而且所有进程全部处于4GB的地址空间中，但是彼此还是不能够随意访问的。在Windows CE下除了使用内存映射文件技术外，还有一种方法也很适合使用，就是利用对象存储。对象存储本身使用RAM文件系统，用普通的操作文件的API就可以创建、读取存在于对象存储区域内的文件。\Windows 目录就存在于对象存储区域内。我们可以利用在\Windows目录下创建文件来实现进程间通信。这种方法既实现简单，只需调用几个文件API函数，又可以减少通信时间，因为\Windows目录存在于物理内存中，数据I/O当然很快了。利用对象存储来实现进程之间的通信是我自己想出来的，MSDN或其它文档并没有这方面的说明。需要注意的就是对象存储区域的大小。另外从实现的代码量上看也不如内存映射文件技术。
　　下面讲解如何利用内存映射文件实现进程之间的通信。假设进程A和进程B需要通信，那么进程A需要先创建一个内存映射文件（之前不必调用CreateFileForMapping函数来创建文件，因为不需要创建文件）。这个内存映射文件可以是在永久存储器中，也可以是在内存中。为了减小通信时间，最好提交物理内存。进程A在调用CreateFileMapping函数时，参数1指定为INVALID_HANDLE_VALUE，这表示这个内存映射文件对象将要把物理内存提交到地址空间中。最后一个参数一定要指定一个名字。进程B也同样调用CreateFileMapping函数，而且参数相同。内核会根据名字来判断是否已经存在一个内存映射文件对象，如果创建了就返回原来的对象的句柄。接下去就不用细说了。参照5.1去执行就可以了。要注意的是进程B调用CreateFileMapping函数后要按如下代码检验函数执行结果：

HANDLE  hMap;
hMap = CreateFileMapping(INVALID_HANDLE_VALUE, 
			NULL,
			PAGE_READWRITE,
			0,
			1000,
			L"abc");
if (hMap == NULL || GetLastError() != ERROR_ALREADY_EXISTS)
{
	MessageBox(L"create file mapping fail");
	return;
}      

最新评论 [发表评论] [文章投稿]

查看所有评论 推荐给好友 打印

本人刚开始接触WinCE,主要在CEPC下进行开发  有两个问题想请教一下： 1）WinCE被加载到内存以后，物理内存的布局是怎样的？ 2）WinCE支持虚拟内存吗？他的虚拟内存是否与WinXp一样，    是以硬盘为交换的？  多谢！！ ( spin 发表于 2007-9-28 15:03:00)   sorry，應該是我搞錯了。MSDN 裏面已經有很明確的説明：If your process exits without having called CreateFileMapping as well as CloseHandle, the handle returned by CreateFileForMapping is automatically closed. The CreateFileForMapping function opens a file and returns a file handle that is passed to the CreateFileMapping function. The CreateFileMapping function then returns a handle to the file mapping. For Windows CE, it is only necessary to close the mapping handle as the file handle is automatically closed when you close the mapping handle. ( JiaxWang 发表于 2006-6-4 20:57:00)   这样写 在关闭文件句柄时是正确的 h = CreateFileForMapping(...); CloseHandle(h);         // 正确 但是在其中加入一些代码就会使得关闭文件句柄出错 h = CreateFileForMapping(...); h2 = CreateFileMapping(h,...);  // 新插入语句 CloseHandle(h2);         // 新插入语句 运行正确 CloseHandle(h);          // 出错！！！ 调用 GetLastError 后得到的错误码指示说  6 The handle is invalid.  ERROR_INVALID_HANDLE  是不是不应该用 CreateFileForMapping 而应该换成 CreateFile ？ 还有付兄说 Windows CE 推荐用 CreateFileForMapping 我不以为然，MSDN 里面有说明： This function is deprecated for Windows Mobile-based devices. To create or open a file that can be used for memory mapping, call CreateFile. ( JiaxWang 发表于 2006-6-2 13:37:00)   《Windows CE进程、线程、内存管理》这三篇文章中的确有一些错误。要拿出正确的结果还需实验。最后我会把正确结果总结成一篇文章。 ( fllsoft 发表于 2004-9-17 10:13:00)   这几天公司网坏了。郁闷！！ 当然可以交朋友了。关于PB我有时间再讲。现在的确很忙啊。 ( fllsoft 发表于 2004-6-29 11:18:00)   能否讲讲Platform builder的知识。 可否交个朋友。我做WinCE也有一年多了。 My qq:36477574 ( sander 发表于 2004-6-23 10:32:00)   如果有两个processor共享内存，我们通常用到CreateFileMapping， 现在有个问题？ 如果我一个用   PAGE_READONLY，一个processor用PAGE_READWRITE， 会是怎样的效果？ ( sander 发表于 2004-6-23 10:30:00)   我忘说明一点，在此补充： 分配大块地址空间（0x4200 0000 － 0x8000 0000） 例子： g_Address = VirtualAlloc(0, 32 * 1024 * 1024, MEM_RESERVE, PAGE_NOACCESS); g_Address = VirtualAlloc(g_Address, 32 * 1024, MEM_COMMIT, PAGE_READWRITE); ( fllsoft 发表于 2004-6-21 11:53:00)   麻烦你在你的标题前面加上 Windows CE，以免误导别人 ( wei20020225 发表于 2004-6-18 9:33:00)

二、同步

　　在多数情况下，线程之间难免要相互通信、相互协调才能完成任务。比如，当有多个线程共同访问同一个资源时，就必须保证一个线程正读取这个资源数据的时候，其它线程不能够修改它。这就需要线程之间相互通信，了解对方的行为。再有当一个线程要准备执行下一个任务之前，它必须等待另一个线程终止才能运行，这也需要彼此相互通信。实际开发过程中，线程间需要同步的情况非常多。Windows CE.NET给我们提供了很多的同步机制，熟练的掌握这些机制并合理运用会使线程之间的同步更合理、更高效。进程间的通信机制在下一篇文章中讲解。
　　Windows CE.NET具有两种运行模式：用户模式和内核模式。并且允许一个运行于用户模式的应用程序随时切换为内核模式，或切换回来。线程同步的有些解决办法运行在用户模式，有些运行在内核模式。《Windows核心编程》上说从用户模式切换到内核模式再切换回来至少要1000个CPU周期。我查看过CE下API函数SetKMode的源码，这个函数用于在两种模式间切换，改变模式只需修改一些标志，至于需要多少个CPU周期很难确定。但至少可以肯定来回切换是需要一定时间的。所以在选择同步机制上应该优先考虑运行在用户模式的同步解决办法。

1、互锁函数
　　互锁函数运行在用户模式。它能保证当一个线程访问一个变量时，其它线程无法访问此变量，以确保变量值的唯一性。这种访问方式被称为原子访问。互锁函数及其功能见如下列表：
　

函数	参数和功能
InterlockedIncrement	参数为PLONG类型。此函数使一个LONG变量增1
InterlockedDecrement	参数为PLONG类型。此函数使一个LONG变量减1
InterlockedExchangeAdd	参数1为PLONG类型，参数2为LONG类型。此函数将参数2赋给参数1指向的值
InterlockedExchange	参数1为PLONG类型，参数2为LONG类型。此函数将参数2的值赋给参数1指向的值
InterlockedExchangePointer	参数为PVOID* 类型，参数2为PVOID类型。此函数功能同上。具体参见帮助
InterlockedCompareExchange	参数1为PLONG类型，参数2为LONG类型，参数3为LONG类型。此函数将参数1指向的值与参数3比较，相同则把参数2的值赋给参数1指向的值。不相同则不变
InterlockedCompareExchangePointer	参数1为PVOID* 类型，参数2为PVOID类型，参数3为PVOID。此函数功能同上。具体参见帮助

2、临界区
　　临界区对象运行在用户模式。它能保证在临界区内所有被访问的资源不被其它线程访问，直到当前线程执行完临界区代码。除了API外，MFC也对临界区函数进行了封装。临界区相关函数：

void  InitializeCriticalSection ( LPCRITICAL_SECTION );
void  EnterCriticalSection ( LPCRITICAL_SECTION );
void  LeaveCriticalSection ( LPCRITICAL_SECTION );
void  DeleteCriticalSection ( LPCRITICAL_SECTION );      

void CriticalSectionExample (void)
{
    CRITICAL_SECTION  csMyCriticalSection;
    InitializeCriticalSection (&csMyCriticalSection);  ///初始化临界区变量

    __try 
    {
       EnterCriticalSection (&csMyCriticalSection);   ///开始保护机制
       ///此处编写代码
    }

    __finally   ///异常处理，无论是否异常都执行此段代码
    {
       LeaveCriticalSection (&csMyCriticalSection);  ///撤销保护机制
    }
} 
      

CCriticalSection  cs;

cs.Lock();

///编写代码

cs.Unlock();      

　　如果一个线程既要执行大量任务同时又要响应用户的按键消息，这两个专用于等待消息的函数将非常有用。

和事件有关的函数有：

HANDLE  CreateEvent(LPSECURITY_ATTRIBUTES  lpEventAttributes, 
					BOOL bManualReset, 
					BOOL  bInitialState, 
					LPTSTR  lpName);

BOOL  SetEvent(HANDLE  hEvent );
BOOL  PulseEvent(HANDLE  hEvent);
BOOL  ResetEvent(HANDLE  hEvent);

HANDLE  OpenEvent(DWORD  dwDesiredAccess, 
				  BOOL  bInheritHandle, 
				  LPCTSTR  lpName );

HANDLE CreateMutex(LPSECURITY_ATTRIBUTES  lpMutexAttributes, 
				   BOOL  bInitialOwner, 
				   LPCTSTR  lpName);

BOOL  ReleaseMutex(HANDLE  hMutex);      

HANDLE  CreateSemaphore(LPSECURITY_ATTRIBUTES  lpSemaphoreAttributes, 
		LONG  lInitialCount, 
		LONG  lMaximumCount, 
		LPCTSTR  lpName);

BOOL  ReleaseSemaphore(HANDLE  hSemaphore, 
		LONG  lReleaseCount, 
		LPLONG  lpPreviousCount);

HANDLE  WINAPI  CreateMsgQueue(LPCWSTR  lpszName, 
			   LPMSGQUEUEOPTIONS  lpOptions);

BOOL  WINAPI  CloseMsgQueue(HANDLE  hMsgQ);
BOOL  GetMsgQueueInfo(HANDLE  hMsgQ, 
		  LPMSGQUEUEINFO  lpInfo);

HANDLE  WINAPI  OpenMsgQueue(HANDLE  hSrcProc, 
			 HANDLE  hMsgQ, 
			 LPMSGQUEUEOPTIONS  lpOptions);

BOOL  ReadMsgQueue(HANDLE  hMsgQ, 
	   LPVOID  lpBuffer, 
	   DWORD  cbBufferSize, 
	   LPDWORD  lpNumberOfBytesRead, 
	   DWORD  dwTimeout,  
	   DWORD  *pdwFlags);

BOOL  WINAPI  WriteMsgQueue(HANDLE  hMsgQ, 
			LPVOID  lpBuffer, 
			DWORD  cbDataSize,  
			DWORD  dwTimeout, 
			DWORD  dwFlags);      

Windows CE 进程、线程和内存管理（一）


作者：付林林

　　进程、线程、内存管理是一个内核最基本的服务，也是一个内核最主要的组成部分。这几方面的知识是一个软件开发人员必须掌握的基础知识。虽然一个人不懂这些知识也能编写简单的程序，但这样的程序只能算是皮毛。掌握了进程、线程和内存管理方面的知识，就能够充分利用操作系统内核提供的服务，提高你编写的软件的执行效率、更节省资源、更健壮。顺便说一下，在Windows CE.net下可以运行用Visual Studio.net开发的.net平台上运行的软件，但这样的软件是最上层的软件，离操作系统内核太远了。不但执行效率相对较低，而且还要把.net 框架加到内核中。所以在大多数情况下，EVC仍然是第一选择。


图一 CE内核结构

一、进程和线程

1、概念：
　　Windows CE.NET是一个抢占多任务操作系统，抢占多任务又被称为调度。在调度过程中，内核的调度系统包含一个当前所有进程中线程的优先级列表，并对所有的线程按优先级排列顺序。当中断发生时，调度系统重新安排所有线程的排列顺序。
　　一个进程是一个正运行的应用程序的实例。它由两个部分组成：一个是操作系统用来管理这个进程的内核对象。另一个是这个进程拥有的地址空间。这个地址空间包含应用程序的代码段、静态数据段、堆、栈，非XIP（Execute In Place）DLL。从执行角度方面看，一个进程由一个或多个线程组成。一个线程是一个执行单元，它控制CPU执行进程中某一段代码段。一个线程可以访问这个进程中所有的地址空间和资源。一个进程最少包括一个线程来执行代码，这个线程又叫做主线程。

2、进程：
　　Windows CE.NET最多支持32个进程同时运行。这是由整个系统分配给所有进程的总地址空间决定的。低于Windows CE 4.0版本（也就是低于.NET的版本）的CE操作系统，总进程空间从0x0000 0000到0x4200 0000 ，每32MB地址空间为一个槽（Slot），共33个槽。当一个进程启动时，内核选择一个没有被占用的槽作为这个进程的地址空间。其中0x0000 0000到0x01FF FFFF这个槽称为Slot 0。每个进程在即将得到CPU控制权时，将整个地址映射到Slot 0。这个进程在帮助文档中称为当前运行进程（currently running process）。分配一个槽后，内核在这个槽内按由低地址到高地址顺序为代码段、静态数据段分配足够的地址空间，然后是堆、栈，栈之后的空间为所有 DLL保留，包括XIP和非XIP DLL。注意Slot 0最底部64KB是永远保留的。从Slot 1 到 Slot32 为进程使用。前几个槽一般为系统程序使用。如filesys.exe、device.exe、gwes.exe等。
　　Windows CE.NET与低版本操作系统略有不同。这一点是从MSDN 的"Technical Articles"和"Knowledge Base"的文章中找到的，这的确让我费了一番功夫。在Windows CE.NET的帮助文件中只能找到和早期版本相同的说法，而"Technical Articles"和"Knowledge Base"中有几篇文章清楚的说明了Windows CE.NET 和低版本操作系统的不同。在低版本操作系统中，的确如上所说分为33个槽，Slot 0用于当前运行进程，共支持32个进程同时运行。而且所有DLL都加载到进程的地址空间。但Windows CE.NET下 Slot 1也用于当前进程（Slot 1只用于加载所有XIP DLL）。那么一个进程就不是占有32MB地址空间了，而是64MB。在讲解内存管理时我会具体讲解。
创建一个进程的API函数如下：

BOOL  CreateProcess(LPCTSTR  lpApplicationName, LPTSTR  lpCommandLine,
		LPSECURITY_ATTRIBUTES  lpProcessAttributes, 
		LPSECURITY_ATTRIBUTES  lpThreadAttributes, 
		BOOL  bInheritHandles, 
		DWORD  dwCreationFlags, 
		LPVOID  lpEnvironment,
		LPCTSTR  lpCurrentDirectory, 
		LPSTARTUPINFO  lpStartupInfo, 
		LPPROCESS_INFORMATION  lpProcessInformation );

HANDLE  CreateThread(LPSECURITY_ATTRIBUTES  lpThreadAttributes,
		 DWORD  dwStackSize, 
		 LPTHREAD_START_ROUTINE  lpStartAddress,
		 LPVOID  lpParameter, 
		 DWORD  dwCreationFlags,  
		 LPDWORD  lpThreadId );      

　　Windows CE.NET操作系统具有实时性，所以调度系统必须保证高优先级线程先运行，低优先级线程在高优先级线程终止后或者阻塞时才能得到CPU时间片。而且一旦发生中断，内核会暂停低优先级线程的运行，让高优先级线程继续运行，直到终止或者阻塞。具有相同优先级的线程平均占有CPU时间片，当一个线程使用完了CPU时间片或在时间片内阻塞、睡眠，那么其他相同优先级的线程会占有时间片。这里提到的CPU时间片是指内核限制线程占有CPU的时间，默认为100ms。OEM可以更改这个值，甚至设置为0。如果为0，当前线程将一直占有CPU，直到更高优先级线程要求占有CPU。这个调度算法好像是很有效、很完美，但却存在着一种情况，当这种情况发生时程序会死锁。举例来说：一个应用程序包含两个线程，线程1是高优先级，线程2是低优先级，当线程1运行过程中处于阻塞时，线程2得到时间片，线程2这次进入了一个临界区，我们都知道临界区内的资源是不会被其它线程访问的，当线程2正运行时，线程1已经从阻塞状态转变为运行状态，而这次线程1却要访问线程2的资源，这个资源却被临界区锁定，那么线程1只能等待，等待线程2从临界区中运行结束并释放资源的独占权。但是线程2却永远不会得到时间片，因为CE保证高优先级线程会先运行。这时程序就会处于死锁状态。当然系统不会死锁，因为还有更高优先级的线程、驱动程序在运行。对于这种情况，CE采取优先级转换的办法来解决。就是当发生这种情况时，内核将线程2的优先级提高到线程1的优先级水平。这样线程2就可以执行完临界区代码了，线程1也就能够访问资源了。然后内核再恢复线程2原来的优先级。
　　挂起一个线程使用SuspendThread函数。参数只有一个――线程的句柄。要说明的是如果要挂起的线程正调用一个内核功能，这时执行此函数可能会失败。需要多次调用此函数直到函数返回值不为0xFFFFFFFF，说明挂起成功。恢复线程使用ResumeThread函数。参数也只有一个――线程的句柄。
　　关于线程本地存储器和纤程，实际用到的时候非常少，这部分知识可以参考《Windows核心编程》。

写作时间：2004-06-01

未经本文作者同意，不准擅自转载本篇文章。联系作者请邮至 fllsoft@sina.com 或windowsce@tom.com

模拟器和远程调试工具（二）


作者：付林林

模拟器和远程调试工具（一）

3、远程堆查看程序（Remote Heap Walker）

　　显然“Walker”不能翻译成“查看”。你愿意怎么翻译就怎么翻译吧。在这里我就叫查看了，这样容易理解。从名字就可以看出它是用来查看操作系统中每个进程使用的堆的情况。什么是堆就不用我说了吧！堆大家都了解，但是CE下关于堆的知识也值得一说。以后我会有专门讲述CE下进程、线程、和内存管理方面的文章发表，那时会说的非常详细。利用“远程堆查看程序”能够查看到：

模拟器和远程调试工具（一）

作者：付林林

本篇文章主要讲解远程调试工具的使用方法，并采用PB下的模拟器来试验。

一、模拟器

　　模拟器（emulator）是PB的一部分。专用于调试在PB下创建的内核及应用程序。模拟器能够在PC下模拟Windows CE的物理平台。但实际上它只不过是一个运行在CPU Ring 3级别的用户程序。所以它的运行速度要比正常的物理平台要慢。模拟器仅支持x86平台，它只能调试基于"Emulator：x86"的内核和所有用x86指令集编译的程序。模拟器有很大的限制，这些限制使它只能运行简单的应用程序。但是有一点是好的，操作系统的大多数API对于任何CPU而言都是相同的。考虑到不受CPU类型影响的简单程序，还是可以在模拟器上调试的。在实际开发中我只用模拟器调试软件的界面。如果你想学习PB，用它来创建内核而又没有实际的物理平台来调试，那么模拟器非常适合。但模拟器的限制也非常多，所以即使你在模拟器下调试过所有能够调试的内核特征（feature，或者称组件），你掌握的也不过是冰山一角。在这里顺便说一句闲话：PB包含的知识量和Windows CE本身的知识量加起来好比是浩瀚的海洋，比用EVC开发软件的知识量大的多。所以如果你只会用EVC开发几个软件，那你仍然是Windows CE专业的一年级学生。


图一 模拟器

关于模拟器的硬件限制：（摘自Windows CE帮助）

微软推荐的使用模拟器的开发平台的配置：

二、创建内核并下载到模拟器上

为了测试远程调试工具，我们必须先使用PB v4.1创建一个内核：

1. 使用新内核向导创建内核：单击PB的"New Platform"，在"step 2"的"Available BSPs"中选择"EMULATOR：X86"，接着在"step 3"的"Available configurations"中选择一个预定义的内核配置，这些预定义的内核配置具有针对性。在这里我们选择"Internet Appliance"。注意：有些预定义的内核配置附带了外壳程序，有些没带。选择之后，填写工程名（例如Internet）和工程的保存路径。默认"step 4"的选项，在"step 5"中去掉所有复选框。因为我们只要内核和外壳就行了。同样去掉"step 6"中所有复选框。最后一步单击"Done"按钮。
2. 编译这个新内核：在菜单"Platform"-"Settings"－"Environment"中，单击"New"，在弹出对话框中添加变量名"IMGRAM64"和值"1"。然后单击"Build"－"Build Platform"开始编译。具体编译的时间和你的机器配置有很大关系。
3. 配置模拟器：编译成功后，单击"Target"－"Configure Remote Connection"，在弹出的对话框中找到"Download"下拉框，选择"Emulator"，单击后面的"Configure"，在弹出的对话框中设置分辨率为800 X 600或640 X 480。系统内存设置为64MB。单击"OK"后，在"Kernel"下拉框中选择"Emulator"。单击"OK"。
4. 启动模拟器：单击"Target"－"Download Initialize"。等待一会，模拟器就出来了。可以看到标准外壳的界面，也就是桌面。

在PB中编写一个应用程序并下载到模拟器：

1. 在打开了内核工程的前提下（如果刚打开PB，先打开一个内核工程）。单击PB菜单"File"－"New Project or FIle"。余下的步骤我就不用多说了。和EVC一样，添个工程名就可以编码了。只是没有MFC、ATL的支持。在这里选择一个显示"hello world"的SDK程序。然后单击"Build"－"Build All"编译程序。我一般不在PB下开发软件。麻烦！
2. 在模拟器已经打开的前提下，单击"Target"－"Run Programs"，找到你的程序名，再单击"Run"。在模拟器上就可以看到你的程序了。
3. 关闭操作：先关闭模拟器。再单击"Target"－"Disconnect"。

三、远程调试工具

　　远程调试工具用于在开发平台与实际平台间执行一些调试工作。利用远程调试工具可以在开发平台运行，得到实际平台上的文件、监视实际平台上进程或线程的状况、测试实际平台上应用程序的性能等。一部分远程调试工具是我们在开发应用程序时常用的，还有一部分是开发内核时常用的。对于不常用的远程调试工具，我在这里只给予简单的介绍。

1. 远程调用评测程序（Remote Call Profiler）
   远程调用评测程序包含评测和分析工具。利用图形图像显示出你的代码中算法的效率或者占用资源情况。远程调用评测程序包含一系列接口函数。在你想要评测的代码中调用这些接口函数，然后运行你编写的程序。远程调用评测程序就能够接收你编写的程序的数据并记录。最后利用图形显示出来。显然这个工具我们并不常使用。尤其是开发非实时性内核和软件，加上目前的嵌入式微处理器处理速度已经很快了，对于一个软件性能的评测的需求就淡化了。当然，你要是愿意，觉得有必要也可以研究一下它的接口函数，然后测一下。我目前可没这个时间。微软提供了例子程序"hello"。如果你把Windows CE安装在C盘，那么路径为：
   "C:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\sdk\wce410\samples\hello"。
   我编译了此程序并测试了一下。远程调用评测程序显示的图形如图2所示。
   
   
   图二 评测图像截图
   　
2. 远程文件浏览程序（Remote File Viewer）
   远程文件浏览程序是最常用、最易操作的工具之一。它的作用就是向实际平台导入或导出文件。假如我在调试一个显示位图的程序。位图允许用户自行选择。那么要在模拟器下调试，就必须将位图文件先导入到模拟器中。
   模拟器打开后，运行远程文件浏览程序，先弹出一个对话框，要你选择访问哪个平台。如图3所示。
   
   
   图三 平台选择对话框
   
   选择"Default Device"后。主窗口就显示出来了。如图4所示。左边目录数列出的是模拟器运行的内核的所有目录。右边是指定目录下的文件。工具栏最右边是导入和导出按钮。这里的导入和导出是相对开发平台而言的。接上个例子所说，要将一个位图文件传到模拟器中。先单击导出按钮（上箭头），在弹出的对话框中选择一个位图文件，确定后，这个文件就出现在远程文件浏览程序的右边文件窗口中了。导入也简单，先选择一个文件，再单击导入按钮，再选择路径，保存即可。
   
   
   图四 远程文件浏览程序截图

写作时间：2004-5-21

未经本文作者同意，不准擅自转载本篇文章。联系作者请邮至：
fllsoft@sina.com 或 windowsce@tom.com

最新评论 [发表评论] [文章投稿]

查看所有评论 推荐给好友 打印

有是肯定的！但不能给。公司花几万买的。我会随便给你吗。另外就算给，只有x86的就要1个GB。网上有下。自己找。 ( fllsoft 发表于 2004-5-24 14:41:00)   boyren1979@hotmail.com ( boyren 发表于 2004-5-24 10:21:00)   楼主有platform builder ？能否给俺一份啊 ( boyren 发表于 2004-5-24 10:20:00)   谢谢！ ( xiaojin 发表于 2004-5-21 22:35:00)   楼主的pb是指platform builder? ( cool_ice 发表于 2004-5-21 19:38:00)   图片下载后再看就能看到清晰的了。 ( fllsoft 发表于 2004-5-21 19:05:00)   我传的都是清晰的图片。怎么在这显示的却被缩小了。失真太多了。 ( fllsoft 发表于 2004-5-21 19:02:00)   ....................................................... More...

EVC开发实例二：保存信息（一）


作者：付林林

下载源代码

　　Windows CE下开发的软件大多和硬件紧密相关。如果写和硬件相关的技术，那只有极少数甚至没有人受益。相反写出来的文章，应该让更多的人受益，都能学而用之。任何一篇文章我都会遵循此原则。当然，本人资质甚浅。只能尽力而为。
　　题目中的信息是指很少量的数据。比如配置信息、注册表数据等。在其它Windows 操作系统中，这些信息一般都被保存在*.ini文件或注册表中。
　　嵌入式设备没有统一的要求。有的不需要保存任何数据，有的将数据保存到RAM中，在关闭设备时仍然给RAM提供电源。有的将数据保存到永久存储设备中。不同的情况有不同的解决方案，这就造成了在保存信息方面，相关的技术很繁杂，要弄明白需要时间和实践。
　　 在这篇文章中我主要讲解在Windows CE下如何将数据保存到永久存储器中。将数据保存到永久存储器中应用广泛，不易丢失数据，可以保存大量的数据，也不必在系统关闭后还要提供电源。相比较将数据保存到RAM中要不间断地提供电源，存储空间也大大受限制。

保存到*.ini文件中

　　要想让你定制的内核支持永久存储设备，需要加入对永久存储设备的支持（就是驱动程序），再加入一种文件系统。现在假如我们的存储硬件采用IDE接口，使用一种简单实用的文件系统，FAT是合适的选择。那么对应的操作步骤如下：先使用新内核生成向导，生成一个内核工程后（采用哪个平台模板都行），在PB右边“catalog”窗口中加入对存储设备的支持。在PB v4.1下具体位置为“device drivers”－“storage devices”－“ATAPI PCI/IDE Storage Block Driver”。单击右键，在弹出菜单中单击“add platform”，PB立刻将相关驱动程序源码或者编译后的文件，还有相关环境变量加到你的内核工程中。之后再加入FAT文件系统驱动。FAT组件的具体位置为：
“Core OS”－“display based devices”－“file system and data store”－“storage manager”－“FAT File System”。
　　也用同样方法加入到左边内核工程中。之后设置环境变量。方法是单击PB菜单“platform”－“settings”－“environment”－“new”，输入环境变量名“IMGRAM64”，再输入值“1”。准备工作完成后，编译整个内核。你定制的内核就应该支持永久存储了。
　　 先不考虑注册表问题。假如我们的产品不需要保存注册表数据，但是需要将一些软件使用的配置信息保存到永久存储器中，那么采用ini文件方式比较适合。不采用注册表保存数据的原因是在定制内核时需要进行复杂的设置，来保证内核能在每次启动时加载保存到永久存储设备上的注册表数据。如果只是几个软件需要使用配置信息，那就没必要为了能够保存注册表数据而设置内核。把话说简单一点：除非必要，能不用注册表保存最好。
　　虽然在EVC帮助文件中提到了MFC库中有CWinApp::WriteProfileInt和CWinApp::WriteProfileString 。而且在EVC下编译也通过了。但实际执行起来函数返回值为0，说明没有任何数据被写到硬盘上。在硬盘或者\windows目录下也没找到ini文件。这看起来很蹊跷，如果你使用EVC开发过，你就见怪不怪了。下面顺便说说我遇到过的“蹊跷”：
　　 A、有的函数在帮助文件中提到过，说CE支持此函数。但在编译时EVC不识别，或者链接时不识别。一种原因可能是你在安装了CE和EVC后，没有调整EVC的编译和链接目录，也就是包含头文件和库文件的目录。EVC在安装后，默认包含头文件和库文件的目录为Standard SDK目录，Standard SDK是专为模拟器准备的，自然内容很少，找不到某个函数也在情理中。解决办法是修改EVC的包含头文件和库文件的目录。位置在菜单“tools”－“options”－“directories”。在“CPUs”栏里选择你的CPU类型，然后分别添加头文件和库文件的目录，添加的头文件目录和库文件目录是安装Windows CE时SDK的目录。举例来说，假如开发平台使用的是x86 CPU。那么在“CPUs”中选择“Win32 (WCE x86)”，然后在“Show directories”中选择“include files”，接着在下面“Directories”栏里添加几个目录。如图1所示（SDK指软件开发包，OAK指OAL开发包，DDK指驱动开发包）。接着在“Show directories”中选择“library files”，把库文件目录也添加进去。如图2所示。另一种原因就是真的没有此函数。CE的帮助文件做的并不好。很多函数的说明、例子代码都是照抄于VC下的帮助文件。只有编译或者运行程序时你才知道这个函数是否存在。
注：如果你是在PB下创建工程编写程序，就不必设置了。


图一


图二

　　 回到正题。CWinApp::WriteProfileInt和CWinApp::WriteProfileString函数既然不能写数据到永久存储设备。那就必须自己写这两个函数和对应的读取数据函数GetProfileString和GetProfileInt。因为这四个函数使用频率很高，故我将此函数写出来，当你需要的时候就不用再写了。
注：1、函数中所有字符串均为UNICODE。2、采用了MFC类库。3、具体问题见代码。