前段时间为了找个WindowsMobile版的Rss阅读器，在网上找了很多，没找到合适自己需求。最后参考了一些相关的软件，实现了这个阅读器。
下载使用 MRssReader (418)
先介绍下功能：
欢迎大家下载使用，如有任何疑问或发现Bug，欢迎留言或邮件讨论（Theiter12@gmail.com or hang.zh@163.com）!!!!
下载使用 MRssReader (418)
[截图]
最近需要做点与网络连接相关的东西，研究了下WM上创建接入点的方法，把一些自己对该知识点的理解和一些代码片段记录下来。
转自：http://blog.mcuol.com/User/iwillbeback008/Article/10045_1.htm
Windows CE驱动程序结构概述
Windows CE的驱动程序可以从多种角度进行区分。
1．从加载以及接口方式来区分
可以分为本机设备驱动（Built-In Driver）、可加载驱动（Loadable Driver）以及混合型驱动。
（1）本机设备驱动
本机设备驱动即Native Device Drivers。这些驱动程序在系统启动时，在GWES的进程空间内被加载，因此它们不是以独立的DLL形式存在。这些驱动对应的设备通常在系统启动时就被要求加载，如果没有串口，也没有LCD的话，整个系统就不能和用户信息交流。另外，流驱动程序也能作为本机设备驱动而存在。
（2）可加载驱动
也被称为流驱动。
这些驱动可以在系统启动时或者和启动后的任何时候由设备管理器动态加载。通常它们以DLL动态链接库的形式存在，系统加载它们后，这些驱动程序也只是以用户态的角色运行。可加载驱动程序通过文件操作API来从设备管理器和应用程序获得命令。
在Windows CE中典型的可加载驱动有以下各类：
n PCMCIA driver（PCMCIA.dll）
n Serial driver（SERIAL.dll）
n ATAFLASH driver（ATA.dll）
n Ethernet driver（NE2000.dll，SMSC100FD.dll）
（3）混合型驱动
这类驱动综合了前两种驱动的特性。它同时使用了stream接口和custom-purpose接口。
混合型驱动主要是提供custom-purpose 接口，但是由于需要和系统中只允许使用stream接口的那些模块进行交互，因此也必须提供stream接口。例如，PC card socket驱动同时拥有两套接口。
2．从驱动层次上分
可以分为独立驱动和层次型驱动。图9-1是这两种驱动在系统中的位置。
图9-1 独立驱动和层次型驱动在系统中的位置
（1）独立驱动程序
可以将驱动程序编写成同时包含MDD和PDD层的独立驱动。独立驱动的代码应当包括中断服务例程和平台相关处理函数。使用独立驱动的好处在于可以省去MDD和PDD层驱动之间的信息传递，这一点在实时处理中非常重要。另外，如果设备的操作和MDD驱动层的接口描述相吻合，可以使用独立驱动程序提高处理性能。
（2）层次型驱动
层次型驱动分为两层，较上层的Model Device Driver（MDD）和比较下层的Platform Dependent Driver（PDD）。MDD实现的是和平台无关的功能，它描述了一个通用的驱动程序框架。而PDD是和硬件以及平台相关的代码组成。MDD调用PDD中特定的接口来获取硬件相关的信息。当使用层次型驱动的时候，一般只需要基于相近的样列驱动程序，针对特定的硬件修改PDD程序，MDD建立的框架可继续使用。由于层次间接口的层层调用以及消息的传递，使得处理速度相对独立驱动程序要慢，因此在时间要求苛刻的环境下，层次型驱动显得不是很适合。
一般MDD将完成以下任务。
n 连接PDD层，并且定义它要使用到的Device Driver Service Provider Interface（DDSI）函数集；
n 向设备管理器提供Device Driver Interface（DDI）接口集；
n 处理复杂的事件，如中断等等。
每一种MDD驱动都处理不同种类的设备。DDI是由MDD层驱动以及独立型驱动提供给设备管理器的一组接口集。DDSI是由PDD向MDD层提供的接口集。公司的设备可以用同样的DDI。
在开发过程中，MDD层驱动是不需要被修改的。微软公司不保证被修改的MDD能在系统中正确运行的。和MDD层驱动不同的是，PDD层驱动必须被修改成和特定硬件相匹配的代码。程序员可以自己开发一个PDD程序，多数情况下建议开发者在Platform Builder提供的样例驱动程序上进行修改。例如，Platform Builder提供了Wavedev驱动程序，它的代码位于%WINCEROOT%\public\common\oak\drivers\WAVEDEV下，这是一个容易理解的流接口层次型驱动程序。此样例audio驱动程序仅提供了播放及录音功能，只提供播放功能的结构框架，播放功能和音频设备的交互还需要PDD层来解决。
串口驱动分析 Auth：nasiry
串口驱动分析
http://nasiry.cnblogs.com/archive/2005/04/12/136175.aspx
Auth：nasiry
date： 2005年4月12日
abort： windowsCE.net 420串口驱动分析 相关资料
虽然串口通讯已经是普遍的标准而且广为大家熟知，但驱动中涉及的部分内容也可能在平时的应用中并不是很常用到，在这里做一个简单的介绍待后面说明到具体代码的时候可以连贯一些。
串行通讯接口是目前十分流行的通讯接口之一。由于其电气界面的简单性使其在计算机领域的应用相当的广泛。在这里提到的串行通讯接口主要是指UART(通用串行)和IRDA两种。通常的串行连接电气连接上有3wire和9wire两种。3wire的接线方式下定义了发送、接收和地三根连接。其用途就如名称一样分别用于发送、接收。下面是通常3wire连接的结构框图
通常在串行接口控制器上会有两个FIFO用作接收和发送的缓冲，当接收到数据后会直接将接收到的数据置入该缓冲器，并同时由控制电路向本地总线发出通知，以便让本地总线将缓冲器内的数据读走，这样在响应(等待和读取)的过程中仍然能通过缓冲器来接收数据。而发送发送的过程刚刚相反，本地总线可一直向发送缓冲写入数据直到器填满为止，而无需对每个数据的发送进行等待。这就是基本的收发流程(这部分逻辑流程相信大家是最熟悉的)。这一点在3wire和9wire中都是相同的。但是我们考虑下面的情况，如果接收一方的响应由于某种原因的干扰(如处理器被其他中断服务占用)的时候可能就来不及相应之前ReceiveFIFO就可能被填满了，这样后续发送过来的数据就会丢失，这样在需要数据可靠传输的情况下串行通讯的弊端也就显示出来了。如需要数据的可靠传输就需要对数据流的收发进行控制。在9wire中将串行连接定义为如下形式:
也就是说在原3wire的基础上增加了DCD,DTR,DSR,RTS,CTS,DELL六个控制线。其中RTS/CTS用于流控制，另外的DCD和DELL则留作连接modem使用。有了专门的硬件流控制引脚也就使得流控制成为可能，以完成收发两端的匹配使得数据可以可靠的传输。用RTS/CTS（请求发送/清除发送）流控制时，应将通讯两端的RTS、CTS线对应相连).在发送端准备发送数据之前设置RTS(Request to send)也就使发送请求线，若接收端以作好接收准备，就启动响应的CTS（Clear to send）引线。这样，收发双发就进入数据传输状态，在此过程中如若接收端处理数据的速度低于发送端的发送速度，接收一端还可以设置CTS引线恢复原来阻塞得状态以暂时中断数据传输，之后若需要恢复数据传输恢复CTS状态即可。这样UART的传输即实现了流控制，保障了数据传输的完备性。
在这里还要说一下软件流控制，虽然硬件已经可以完成流控制的任务但很多少时候受到连线数的限制不能使用硬件流控制也就设计了专门的软件流控制的方法。现在回到3线传输的情景，若接收端接收数据过程中缓冲器的负载到达某一限制(也就是留出一定的缓冲空间)时接收端向发送端发送一个特殊的标示位(接收停止位)，当发送端收到该标示的时候就停止发送，直到接收端缓冲器低于另一限制后发送标示(接收许可位)给发送端，这样就可以控制数据流的传输起停。这种软件流控制是在给缓冲器留余量来完成的，在收发双端处理器速度差很大的时候就不太适用了，就必须要用硬件流控制。
其他几个引脚都是与modem相关的，DSR数据装置准备好（Data set ready)用于表明MODEM处于可以使用的状态。DTR数据终端准备好(Data terminal ready)表明数据终端可以使用。这两个信号用于检查Modem是否连接。DELL脚当有电话拨入时Modem将会设置这个引脚。DCD信号是当Modem接收到数字载波信号的时候被设置，用于了解Modem接收信号的情况。
至于剩下的奇偶效验和停止位设置就只是需要针对寄存器设置无需软件干涉就可以完成了。下面我们来看具体的驱动程序。
架构
在wince中串口的驱动实现是有固定模型的，ce中的串口模型遵循ISO/OSI网络通讯模型(7层)，就是说串口属于CE网络模块的一个部分。其中rs232界面(或其它的物理介质)实现网络的物理层，而驱动和serialAPI共同组成数据链路层，其它部分都没有做定义。在典型的应用中,serialAPI与间接通过TAPI或直接与ActiveSync交互，组成CE网络的一部分。而红外本身的协议就相对复杂的多，它有专门的一套模型来描述其使用规则，对红外设备本身了解不多也就不能深入下去。在串口的这一侧，整个驱动模型也是相当的复杂的，但所幸的是驱动仅仅使用到SerialAPI这一层，在这个层次上串口的行为还是相对简单的。
我们这里仅仅涉及上面所提到的Serial/irda Driver这部分(绿色部分)。在wince提供的驱动例程中串口/红外驱动采用分层结构设计，MDD提供框架性的实现，负责提供OS所需的基本实现，并将代码设计与具体的硬件设计无关。而PDD提供了对硬件操作相应的代码。这些代码通过结构HWOBJ来相互联系。对于MDD+PDD的整体驱动来看，串口驱动模型是作为Stream来实现的。
两者合一以达到实现驱动的目的。DDSI就是指这两个部分之间的接口，这个接口并非受到强制的物理/逻辑关系来约束，而是人为的规定的。在涉及到一种特定硬件我们进行针对实现的时候往往需要的是了解硬件的物理特性和控制逻辑，然后根据DDSI的约束就来进行实现。对于这里描述的驱动模型而言结合关键在于结构指针HWOBJ的使用和具体实现。在实际的驱动应用中仅仅需要实现HWOBJ相关的一系列函数，而无需从驱动顶层完全开发。串口驱动模型作为一种常用驱动模型在windowsCE中常常用于串口/红外/USB Client的具体实现。该驱动模型中对全功能的串口进行了定义，除了常用的TX和RX引线定义以外，针对DTR、RTS等功能引脚都进行了支持，使得用该模型设计的串口驱动支持流控制、具备驱动Modem等设备的能力。
事实上，如果需要的话完全可
以将该驱动一
