2. 传统的UI设计模式
2.1 Windows窗体
        Windows界面程序中，最重要的概念是窗体的概念。窗体是Windows程序中，消息派发的单位，每个窗体都有自己的窗口过程，用于处理Windows派发来的消息，这些消息中，比较容易让人理解的，即是WM_ERASEBKGND消息和WM_PAINT消息。
        当窗体需要重新绘制背景时，系统就会向窗体发送WM_ERASEBKGND消息，窗体接收到这个消息以后，将会调用OnEraseBkgnd函数，刷新窗体的背景。
       当窗体需要被重新绘制时，系统会向窗体发送WM_PAINT消息，则窗体的OnPaint函数将会被调用，以达到重新绘制整个窗体的作用。
        我们不需要纠结于绘制背景和绘制窗体的区别，只需要知道窗体大概就是这样展现出来的即可，而两个消息的响应函数，也并非一定是OnEraseBkgnd和OnPaint，我们可以根据需要自行决定函数名称。
       我们将某个窗体从后台移动到前台时，则该窗体将会依次收到WM_ERASEBKGND和WM_PAINT消息。

2.2 使用Windows API来制作界面
如果纯粹使用Windows API来开发程序界面，则我们需要做的工作大致如下：
1. 设置一个WNDCLASSEX结构，使用这个结构来注册一个新的窗体类别。
2. 创建刚注册的窗口类别的一个窗体实例。
3. 编写一个窗体过程函数，响应第2步中创建的窗体的各种消息。对于不需要特殊处理的消息，则直接调用DefWindowProc处理。
后续的界面处理，有两种选择，一种是再创建子窗体，放在主窗体上，而后子窗体可以有自己的窗体过程函数，以此实现将界面划分不同模块，分开处理。另外一种选择则是将主窗体划分为不同的区域，在OnPaint函数中，根据不同的区域，调用不同的绘制模块，来实现复杂的界面处理。前者可以认为是MFC的雏形，而后者则是DirectUI的思想。

2.3 MFC框架
      MFC是微软提供的一套界面开发工具库，其全称是Microsoft Foundation Classes。早期的界面开发很多是基于MFC框架。
      MFC将对窗体操作的一系列Windows API函数封装成一个CWnd类。封装窗口过程处理函数，提供消息映射机制。即不再需要编写窗口过程，而是直接使用消息映射宏ON_MESSAGE(msg, handler)来映射msg与handler。
      框架提供从CWnd类派生的诸多其他控件类，例如CButton, CStatic, CListCtrl, CCombox, CProgressCtrl等等。每一个界面控件的实例，都包含一个窗体，可以响应发送给该窗体的消息，多个界面控件，以父子控件的层级关系，搭建在一起，就组成了复杂的界面。
MFC框架中提供的基础控件，往往难以满足复杂界面的需求，通常情况下，软件公司会对MFC库进行扩展，并建造自己的界面控件库，以满足不同的需求。

3. DirectUI技术
       MFC的框架经过多年的发展，已经比较完善，但仍然难以使用MFC开发出复杂炫丽的客户界面。很多情况下，界面开发人员都需要根据自己的界面需求，定制开发新的MFC控件，使得界面开发仍然苦难。此外，在MFC框架中，每一个控件都是一个窗体，系统对于窗体的维护需要付出较大的代价，使得程序运行效率低下。
      在这种情况下，出现了DirectUI的思想。
2.1 DirectUI简介
      DirectUI技术的精髓在于整个程序只有一个窗体，在主窗体上绘制出不同的控件。DirectUI中也有界面控件的概念，但此处的控件，仅仅保存控件区域，并负责对此区域进行自定义的绘制。
      采用DirectUI设计界面和MFC设计界面的一大不同之处在于，在MFC中，界面的设计需要通过使用MFC的资源编辑器或者手工编写代码实现。而在DirectUI技术中，界面的设计则是采用xml配置文件的形式。界面xml的配置类似于使用html编写网页。

2.2 DirectUI的实现
DirectUI的实现有多种方式，但基本上大体分为以下几个部分：
1. DirectUI框架：封装窗体功能，消息分发功能，控件基类，皮肤基类，皮肤解析等等
2. 工具封装：封装常用工具，例如字符串处理，XML文件处理等
3. 界面解析引擎：用于解析界面xml配置
4. 界面库： 封装常用的界面库，使得DirectUI可以运行起来

      DirectUI框架负责将xml界面配置转换成用户界面，并提供一系列常用界面控件。DirectUI库的使用者，可以使用xml快速配置界面，并通过响应界面控件向外发出的消息，来实现自身的业务逻辑。
      不同的公司对DirectUI的实现略有不同，但总体思路大体相当。国内有一些公司，在DirectUI的基础上进行了扩展，使得其功能更加强大。

3. 国内DirectUI的发展
3.1 UIPower公司
      提到国内DirectUI技术的发展，就不能不说UIPower公司，其中文名位上海勇进公司。UIPower公司是目前国内最大的DirectUI技术提供厂商之一，发展迅速，有比较多的成功案例。
      UIPower对DirectUI技术进行了扩展，这些扩展主要包括以下几个方面：
1. 在DirectUI的核心基础上，封装一层COM，使得其核心控件能够被多种语言访问到。其中最突出的是使用javascript语言访问DirectUI核心控件的接口，使得UIPower公司提供的DirectUI库可以支持使用javascript对界面进行控制。
2. 提供强大的界面设计工具，利用所见即所得的模式，设计用户界面，并自动生成界面xml文档。设计工具中，还提供使用javascript脚本对界面效果进行控制。

3.2 DUILib
DUILib是国内的开业DirectUI项目。DUILib项目基于几千年一个老外写的DirectUI论文中的一个例子。DUILib的发起者基于该例子，创建了完整的DirectUI库，并与2010年发布了第一版开源软件。
DUILib支持DirectUI的所有特性，也提供界面设计器，但由于开发人手不足，界面设计器功能简单，且不完善。目前，该项目仍在继续发展当中。

3.3 bkwin
Bkwin是金山软件公司的界面库，随着金山公司将金山卫士项目源码公开，并建立金山开源社区，bkwin作为金山公司界面库也被开放出来。
Bkwin基于wtl编写，源码小巧，功能强大，支持皮肤设置，语言设置等。实现了DirectUI技术的全部功能。Bkwin不提供界面设计器，只支持纯手工编写界面配置文件。开发者在配置了界面描述、皮肤描述、风格描述以及语言描述四个xml文件后，即可生成用户界面。
Bkwin界面库已经成功应用在金山卫士软件上，且其背后有金山软件公司的支持，因此相对于DUILib更加稳定可靠。

C++ STL 学习 ：自己写仿函数(functor)（三）

这种UI设计的方式，实际上在CSharp中也比较容易做到。我们可以轻易设计出一种控制器，来读入界面配置文件，并动态生成界面布局配置扎文件中定义的各种控件，最典型的如Button, Label之类。而后在控制器中添加控件事件响应函数，实现应用程序的业务逻辑。

采用CSharp语言实现这种动态UI配置比较容易，控件的生成，可以通过反射来实现。从配置文件指定的dll中，寻找到指定名称的控件，并动态生成即可。

那么使用C++语言进行界面设计时，可以实现这种动态界面布局么？ 答案是可以的，只是会有一些麻烦。下面我将对在MFC中实现动态界面布局的问题以及解决方案作出分析。

动态界面布局有两大基础要素，一个是动态创建控件，一个是动态的为控件指定事件响应函数。

1. 动态创建控件
我们知道在CSharp中，可以使用反射的方式，通过类名动态创建类的实例。而在C++中，并没有反射的概念。这个问题可以通过巧妙的方式来解决，在MFC中有运行时类的概念，我们可以通过RUNTIME_CLASS(classname)获取一个CRuntimeClass的指针，进而通过CRuntimeClass类来动态地创建。对于需要使用CRuntimeClass动态创建的类，需要在类的定义中添加DECLARE_DYNCREATE的声明，并在实现文件中，添加 IMPLEMENT_DYCREATE。

我们使用CRuntimeClass动态创建一个类的实例时，首先需要使用宏 RUNTIME_CLASS来获取到CRuntimeClass的实例，RUNTIME_CLASS宏的定义如下：

  #define RUNTIME_CLASS(class_name) (class_name::GetThisClass())

而 class_name::GetThisClass() 已经在IMPLEMENT_DYNCREATE中定义，最终定义为返回如下成员：

AFX_COMDAT CRuntimeClass class_name::class##class_name = {
		#class_name, sizeof(class class_name), wSchema, pfnNew,
			&class_name::_GetBaseClass, NULL, class_init };

通过查看CRuntimeClass，发现其为一个结构体，声明如下：

struct CRuntimeClass
{
// Attributes
	LPCSTR m_lpszClassName;
	int m_nObjectSize;
	UINT m_wSchema; // schema number of the loaded class
	CObject* (PASCAL* m_pfnCreateObject)(); // NULL => abstract class
#ifdef _AFXDLL
	CRuntimeClass* (PASCAL* m_pfnGetBaseClass)();
#else
	CRuntimeClass* m_pBaseClass;
#endif

// Operations
	CObject* CreateObject();
	BOOL IsDerivedFrom(const CRuntimeClass* pBaseClass) const;

	// dynamic name lookup and creation
	static CRuntimeClass* PASCAL FromName(LPCSTR lpszClassName);
	static CRuntimeClass* PASCAL FromName(LPCWSTR lpszClassName);
	static CObject* PASCAL CreateObject(LPCSTR lpszClassName);
	static CObject* PASCAL CreateObject(LPCWSTR lpszClassName);

// Implementation
	void Store(CArchive& ar) const;
	static CRuntimeClass* PASCAL Load(CArchive& ar, UINT* pwSchemaNum);

	// CRuntimeClass objects linked together in simple list
	CRuntimeClass* m_pNextClass;       // linked list of registered classes
	const AFX_CLASSINIT* m_pClassInit;
};

由此我们知道RUNTIME_CLASS宏实际上最后获取到了一个CRuntimeClass结构体，并对结构体中的各个域进行了赋值。之后我们即可以调用获取到的CRuntimeClass实例的成员函数CreateObject来创建实例。

CreateObject是如何实现的呢？我们注意到CRuntimeClass结构中有一个域叫做 m_pfnCreateObject， 大胆猜测CreateObject函数就是调用此函数指针来创建新的对象。 而我们在RUNTIME_CLASS宏获取到CRuntimeClass时，对m_pfnCreateObject域的赋值是pfnNew。pfnNew实际是由IMPLEMENT_DYNCREATE宏传入IMPLEMENT_RUNTIMECLASS宏的一个宏参数，这个定义如下：

#define IMPLEMENT_DYNCREATE(class_name, base_class_name) \
	CObject* PASCAL class_name::CreateObject() \
		{ return new class_name; } \
	IMPLEMENT_RUNTIMECLASS(class_name, base_class_name, 0xFFFF, \
		class_name::CreateObject, NULL)

其中 class_name::CreateObject即是pfnNew，这个宏定义了创建对象的方法，即是 new class_name

至此，我们已经了解了使用CRuntimeClass来动态创建一个类的方法。即在类中首先生命DECLEAR_DYNCREATE，在实现文件中加入宏 IMPLEMENT_DYNCREATE。

在需要动态创建实例时，如下代码即可实现：

     CRuntimeClass* pRuntimeClass = RUNTIME_CLASS("MyCtrl");
     CObject* pCtrl = pRuntimeClass->CreateObject();

2. 动态为控件指定事件响应函数

控件的事件响应函数比较多，我们以按钮的点击事件为例。在CSharp中，为控件指定事件响应函数很简单，可以直接订阅一个按钮对象的点击事件。 然而在C++中却不是这样。 一方面，C++中没有事件的概念，只有设置回调函数的概念。 MFC的CButton控件中，并没有提供设置回调函数的接口。

MFC中使用消息机制来控制控件的事件，我们以在代码中添加消息响应的方式，来指定按钮的响应函数，例如：

    ON_BN_CLICKED(IDC_BTN_TEST, OnBtnTest)

上述代码将IDC_BTN_TEST按钮的点击事件，关联到OnBtnTest函数上。这种方式是在编译期就进行了事件和处理函数之间的绑定，无法实现根据配置文件对按钮响应事件进行动态绑定的需求。

如果我们能够使用一个函数处理所有的按钮点击的事件，切这个函数能获取到被点击的按钮的ID，那么我们可以在此函数中，自行根据按钮ID来分发事件，实现动态控制按钮点击响应函数的目的。

在这个想法的指导下，首先试试看能不能把所有的按钮ID设置为同一个，然后在OnBtnTest函数中，根据ID分发事件。很可惜，OnBtnTest函数的参数为void，无法获取到具体的按钮ID。

转而一想，按钮点击的本质是系统消息，系统消息是带有wParam和lParam参数的，ON_BN_CLICKED只是在系统消息上的一层封装，这一层封装就直接将控件ID给过滤掉了，因此我们可以分析ON_BN_CLICKED，依次追踪此宏定义：

#define ON_BN_CLICKED(id, memberFxn) \
	ON_CONTROL(BN_CLICKED, id, memberFxn)

#define ON_CONTROL(wNotifyCode, id, memberFxn) \
	{ WM_COMMAND, (WORD)wNotifyCode, (WORD)id, (WORD)id, AfxSigCmd_v, \
		(static_cast< AFX_PMSG > (memberFxn)) },

通过上述定义，我们发现实际上ON_BN_CLICKED宏是定义了WM_COMMAND消息的响应函数，且其wNodifyCode被定义为了BN_CLICKED。 在MSDN中查询 WM_COMMAND 的消息参数可知：
wParam：高字节表示wNotifyCode，低字节表示控件ID
lParam： 表示控件的句柄

因此，我们可以在窗体的消息处理函数WndProc中，拦截ON_COMMAND消息，获取到按钮点击事件，并进行动态分发：

LRESULT CDynamicButtonTestDlg::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
	if (message == WM_COMMAND)
	{
		int wNodify = (wParam >> 16);
		int wID = (wParam & 0xffff);

		HWND hWnd = reinterpret_cast(lParam);
		CWnd* pWnd = CWnd::FromHandle(hWnd);

		// 此处可以开始动态分发事件
		switch (wNodify)
		{
		case BN_CLICKED:
			Dispatch_BN_Clicked(wID, hWnd);
			break;
		}
	}

	return CDialog::WindowProc(message, wParam, lParam);
}

在上述代码中，我们已经可以对所有的按钮的Click事件作出分发，这个分发动作在Dispatch_BN_Clicked中实现。除了按钮以外，其他所有的控件事件，都可以在WndProc函数中截获，并在分析之后，根据配置文件中的配置进行手工重新分发。

1. Nginx 介绍

Nginx 是俄罗斯人编写的十分轻量级的HTTP服务器,它的发音为“engine X”， 是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器．Nginx是由俄罗斯人 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发的，从2004年开始它已经在该站点运行了七八年了。Igor Sysoev在建立的项目时,使用基于BSD许可。
英文主页：http://nginx.org.

Nginx以事件驱动的方式编写，所以有非常好的性能，同时也是一个非常高效的反向代理、负载平衡。
现 在，Igor将源代码以类BSD许可证的形式发布。Nginx因为它的稳定性、丰富的模块库、灵活的配置和低系统资源的消耗而闻名．业界一致认为它是 Apache＋mod_proxy_balancer的轻量级代替者，不仅是因为响应静态页面的速度非常快，而且它的模块数量也非常非常丰富。对 proxy 和 rewrite模块的支持很彻底，还支持mod_fcgi、ssl、vhosts ，适合用来做mongrel clusters的前端HTTP响应。
nginx做为HTTP服务器，有以下几项基本特性：
处理静态文件，索引文件以及自动索引；打开文件描述符缓冲．
无缓存的反向代理加速，简单的负载均衡和容错．
FastCGI，简单的负载均衡和容错．
模块化的结构。包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter。如果由FastCGI或其它代理服务器处理单页中存在的多个SSI，则这项处理可以并行运行，而不需要相互等待。
支持SSL 和 TLSSNI．
Nginx专为性能优化而开发，性能是其最重要的考量,实现上非常注重效率。它支持内核 epoll、kqueue 等高性能并发模型，能经受高负载的考验。
Nginx具有很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速连接时，也很可能会导致服务器物理内存耗尽频繁交换，失去响 应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显非常缓慢了。而Nginx采取了分阶段资源分配技术，使得它的 CPU与内存占用率非常低。nginx官方表示保持10,000个没有活动的连接，它只占2.5M内存，所以类似DOS这样的攻击对nginx来说基本上 是毫无用处的。就稳定性而言,nginx比lighthttpd更胜一筹。
Nginx支持热部署。它的启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下，对软件版本进行进行升级。
Nginx采用master-slave模型,能够充分利用SMP的优势，且能够减少工作进程在磁盘I/O的阻塞延迟。当采用select()/poll()调用时，还可以限制每个进程的连接数。
Nginx代码质量非常高，代码很规范，手法成熟， 模块扩展也很容易。特别值得一提的是强大的Upstream与Filter链。 Upstream为诸如reverse proxy,与其他服务器通信模块的编写奠定了很好的基础。而Filter链最酷的部分就是各个filter不必等待前一个filter执行完毕。它可以 把前一个filter的输出做为当前filter的输入，这有点像Unix的管线。这意味着，一个模块可以开始压缩从后端服务器发送过来的请求，且可以在 模块接收完后端服务器的整个请求之前把压缩流转向客户端。
当然，nginx还很年轻，多多少少存在一些问题，比如：Nginx是俄罗斯人创建，目前文档方面还不是很完善．因为文档大多是俄语，所以文档方面这也是个障碍．尽管nignx的模块比较多，但它们还不够完善。对脚本的支持力度不够。
这些问题，nginx的作者和社区都在努力解决，我们有理由相信nginx将继续以高速的增长率来分享轻量级HTTP服务器市场，会有一个更美好的未来。

2. 准备工作
去官方主页 http://nginx.org/ 下载最新的Nginx源码包，这里给出目前最新的源码包的直接连接： http://nginx.org/download/nginx-1.0.0.tar.gz

[zieckey@freebsd7.2 ~]$ mkdir nginx
[zieckey@freebsd7.2 ~]$ cd nginx
[zieckey@freebsd7.2 ~/nginx]$ wget http://nginx.org/download/nginx-1.0.0.tar.gz
[zieckey@freebsd7.2 ~/nginx]$ tar zxf nginx-1.0.0.tar.gz
[zieckey@freebsd7.2 ~/nginx]$ mkdir module_dev_urlquery
[zieckey@freebsd7.2 ~/nginx]$ cd module_dev_urlquery/
[zieckey@freebsd7.2 module_dev_urlquery]$

这里我们下载了 nginx-1.0.0 的源码，然后准备开发一个 module_dev_urlquery 的module嵌入到nginx中

3. 准备好 module_dev_urlquery 模块的配置文件
一个 nginx module 一般都以个文件夹的方式存在，module源文件和该module的配置文件都在这个文件下面。
这里我们的module叫 module_dev_urlquery，其路径为 /home/zieckey/nginx/module_dev_urlquery 。
其配置文件名为：config ，其路径为 /home/zieckey/nginx/module_dev_urlquery/config
[zieckey@freebsd7.2 module_dev_urlquery]$ vim config
然后输入以下内容：

[zieckey@freebsd7.2 module_dev_urlquery]$ vim config
ngx_addon_name=ngx_http_p2s_module
HTTP_MODULES="$HTTP_MODULES ngx_http_p2s_module"
NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_p2s_module.c"

这里三行内容稍稍解释下：
第一行是表示这个 nginx module 在程序中名字
第二行表示这是一个HTTP module，后面的名字与第一个行保存一致
第 三是这个module的源文件路径，值得说明的是 $ngx_addon_dir 这个变量是 nginx 的内置脚本的内置变量，代表了这个 module 的文件夹的绝对路径，这里就是 /home/zieckey/nginx/module_dev_urlquery

4. 准备源代码文件 ngx_http_p2s_module.c
这里的文件名和路径必须与上面 config 文件中的一致
[zieckey@freebsd7.2 module_dev_urlquery]$ vim ngx_http_p2s_module.c
输入以下源程序内容：


#include "ngx_core.h"
#include "ngx_http.h"
#include "nginx.h"

return conf;
}/*}}}*/


5. 编译运行
现在可以编译nginx和我们刚刚写好的模块了。

[zieckey@freebsd7.2 ~/nginx]$ cd
[zieckey@freebsd7.2 ~]$ cd nginx/
[zieckey@freebsd7.2 ~/nginx]$ mkdir bininstalled
[zieckey@freebsd7.2 ~/nginx]$ cd nginx-1.0.0
[zieckey@freebsd7.2 nginx-1.0.0]$ ./configure--add-module=/home/zieckey/nginx/module_dev_urlquery--prefix=/home/zieckey/nginx/bininstalled
./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre= option.

第一次错误，我们现在这个freebsd系统上没有pcre库，太悲催了，不过还好，这里给出了提示，说可以通过 –without-http_rewrite_module 来禁用使用pcre库的 HTTP rewrite 模块，我们试一试：

[zieckey@freebsd7.2 nginx-1.0.0]$ ./configure--add-module=/home/zieckey/nginx/module_dev_urlquery--prefix=/home/zieckey/nginx/bininstalled --without-http_rewrite_module
adding module in /home/zieckey/nginx/module_dev_urlquery
+ ngx_http_p2s_module was configured

重点看到上面几行信息，说明我们自己写的模块module_dev_urlquery已经被nginx接纳，生成makefile成功。

[zieckey@freebsd7.2 nginx-1.0.0]$ make
[zieckey@freebsd7.2 nginx-1.0.0]$ make install
[zieckey@freebsd7.2 nginx-1.0.0]$ cd /home/zieckey/nginx/bininstalled/
[zieckey@freebsd7.2 bininstalled]$ ls
conf html logs sbin
[zieckey@freebsd7.2 bininstalled]$ cd conf
[zieckey@freebsd7.2 conf]$ vim ngi
nginx.conf nginx.conf.default
[zieckey@freebsd7.2 conf]$ vim nginx.conf

默认的配置文件是下面（将‘#’开头的注释行删除之后）

worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
}
}

我们在最上面添加如下选项：daemon off; 可以让程序不以daemon的方式运行，这样我们可以看到一些调试的打印信息。
另外，在 server 里面添加一个 URI ：

location /urlquery {
p2s_urlquery;
}

最后，我们修改下http监听的端口号，从默认的80改为8088，因为有些时候，我们并没有权限在80端口上监听连接。
修改之后的配置文件全文如下：

daemon off;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 8088;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
location /urlquery {
p2s_urlquery;
}
}
}

好了，到此为止，我们的所有工作就都准备好了，可以启动nginx

[zieckey@freebsd7.2 conf]$ cd /home/zieckey/nginx/bininstalled/sbin/
[zieckey@freebsd7.2 sbin]$ ./nginx
ngx_http_p2s_create_conf
ngx_http_p2s_create_conf
ngx_http_p2s_create_conf
ngx_http_p2s_create_conf
ngx_http_p2s_urlquery_set


新开一个终端，用curl来发起一个http post请求，post数据由-d参数指定：

[zieckey@freebsd7.2 ~]$ curl -d "user=zieckey&verifykey=123456"http://localhost:8088/urlquery
daemon off;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 8088;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
location /urlquery {
p2s_urlquery;
}
}
}
[zieckey@freebsd7.2 ~]$

然后可以看看nginx服务器的一些输出信息：

[zieckey@freebsd7.2 sbin]$ ./nginx
ngx_http_p2s_create_conf
ngx_http_p2s_create_conf
ngx_http_p2s_create_conf
ngx_http_p2s_create_conf
ngx_http_p2s_urlquery_set
ngx_http_p2s_urlquery_handler
p2s_urlquery_process_handler
get_raw_http_body
time=1303552000.000000 http body data len=29:
user=zieckey&verifykey=123456
----------------------http body data end-------------------

6. 其他说明
6.1 配置文件和ngx_command_t的对应关系：

static ngx_command_t ngx_http_p2s_commands[] =
{/*{{{*/
{ ngx_string("p2s_urlquery"), // 命令名，请对照 nginx.conf 看这个
NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_NOARGS,
ngx_http_p2s_urlquery_set,
0,
0,
NULL },

ngx_null_command
};/*}}}*/

nginx.conf 中的 location 字段的配置是这样的：

location /urlquery {
p2s_urlquer;
}

这里的 /urlquery 是 URL 请求里的 URI 部分，
例如 http://localhost/urlquery 这条URL的请求会被这条配置项处理，
这条配置项，会去找命令名为“p2s_urlquery”的 ngx_command 去处理。

6.2 模块名
代码中的模块变量名必须与config配置文件的名字一致
config 配置文件的内容：ngx_addon_name=ngx_http_p2s_module
代码中的内容：

ngx_module_t ngx_http_p2s_module =
{/*{{{*/
NGX_MODULE_V1,
&ngx_http_p2s_module_ctx, /* module context */
ngx_http_p2s_commands, /* module directives */
NGX_HTTP_MODULE, /* module type */
NULL, /* init master */
NULL, /* init module */
NULL, /* init process */
NULL, /* init thread */
NULL, /* exit thread */
NULL, /* exit process */
NULL, /* exit master */
NGX_MODULE_V1_PADDING
};/*}}}*/


模 块的config配置文件会帮助 configure 生成一个ngx_modules.c文件，该文件里会引用 ngx_module_t ngx_http_p2s_module 这个外部定义的变量，所以必须保持一致。在执行 ./configure 完后，在nginx-1.0.0源码的根目录会多出来一个文件夹objs，在这里可以找到ngx_modules.c文件。

6.3 代码调用关系
nginx程序启动的时候，会去读配置文件 conf/nginx.conf ，每读到一个配置项，就会调用 module 注册的回调函数，所以这里可以看到nginx启动的时候调用 ngx_http_p2s_create_conf 函数好几次。 这个函数是由

static ngx_http_module_t ngx_http_p2s_module_ctx =
{/*{{{*/
NULL, /* preconfiguration */
NULL, /* postconfiguration */

ngx_http_p2s_create_conf, /* create location configration */
NULL /* merge location configration */
};/*}}}*/

指定的。

然 后，在一个客户端发起http请求的时候，例如我们这里的 “curl http://localhost:8088/urlquery” 命令实际上是发起一个 http 请求，URI 是 urlquery，所以，nginx 根据配置文件的配置项，找到 urlquery 对应的处理模块名 p2s_urlquery， 然后调用 p2s_urlquery 这个名字关联的 ngx_http_p2s_urlquery_set 回调函数。
ngx_http_p2s_urlquery_set 回调函数又会设置一个 ngx_http_p2s_urlquery_handler 回调函数，ngx_http_p2s_urlquery_handler 回调函数会在 nginx 读取客户端发过来的http数据的时候被调用。
ngx_http_p2s_urlquery_handler 又会设置一个 p2s_urlquery_process_handler 回调函数，
p2s_urlquery_process_handler 会在 nginx 读取完客户端发过来的http数据之后的时候被调用，
不难发现，p2s_urlquery_process_handler函数是我们真正的处理逻辑，因为这个时候已经收完了客户端的http数据。

p2s_urlquery_process_handler 函数先调用 get_raw_http_body 这个我们自己封装的函数将客户端发送过来的 http data 读取到一个缓冲区中，然后处理（这里我们只是简单的printf）。然后，我们准备好数据，发送会客户端。

到此，我们完成了一个很简单的模块的开发和调试工作，也不是那么困难。
同时对一些函数调用，配置文件关系等等比较含糊的地方做了详细说明。

参考wikipedia的定义：
Memory barrier, also known as membar or memory fence or fence instruction, is a type of barrier and a class of instruction which causes a central processing unit (CPU) or compiler to enforce an ordering constraint on memory operations issued before and after the barrier instruction.

http://en.wikipedia.org/wiki/Memory_barrier

一个例子：
Processor #1:
x = f = 0
loop:
load the value in location f, if it is 0 goto loop
print the value in location x

Processor #2:
store the value 42 into location x
store the value 1 into location f

上面的例子中，变量 x f 初始化值都是0。我们期望输出“42”。但是结果并不总是这样。
如果 Processor #2 的执行顺序是乱序的（out-of-order execution），也就是说，对f赋值的语句先于对x赋值的语句，那么就有可能输出“0”
对于大多数的程序来说，这种特例情况是不能容忍的。
如果将内存屏障置于对f赋值的语句之前，那么就能保证 Processor #2 先对x赋值，然后才对f赋值。这样就能得到我们期望的结果，输出“42”

Windows路径是我们经常使用的东西，它看似简单，实际上隐含许多细节，这些都是在平常的使用过程中注意不到的。下面让我们来看看各种各样的Windows路径。

提起路径，我们都会想到“绝对路径”和“相对路径”，实际上绝对路径是一个广泛的概念，它表示的是可以唯一定位一个文件或文件夹的路径，有多种形式的路径都属于绝对路径的范畴，例如：

完整路径（Full path）

我们平时所说的“绝对路径”通常就是指完整路径，它的格式如下：
C:\Windows\System32\calc.exe

UNC（Universal Naming Convention通用命名规范）路径

UNC路径用于在局域网上定位文件或文件夹，在通过网上邻居访问其它系统上的共享文件时使用的就是UNC路径。UNC路径的格式如下：
\\PC101\ShareFiles\job.doc
其中PC101是目标系统的计算机名，ShareFiles是目标系统上的共享文件夹名称。

以\\?\开头的路径

在某些手工辅助杀毒的工具中可以看到以\\?\开头的路径，这种路径我还找不到正式的名称。完整路径和UNC路径都可以以\\?\开头：
\\?\C:\Windows\System32\calc.exe
\\?\UNC\PC101\ShareFiles\job.doc

相对路径（Relative path）

上面四种路径都可以在本地或网络上绝对定位一个文件，因此属于绝对路径。另一种我们常常使用的是相对路径，这种路径需要与进程的当前文件夹（Current directory）一起合作才可以定位一个文件或文件夹。进程的当前文件夹并不是指EXE文件所在的文件夹，它是每个进程都有的一个属性。例如在命令提示符中显示的路径就是这个cmd.exe进程的当前文件夹，使用cd命令可以改变当前文件夹，无论当前文件夹如何改变，cmd.exe文件所在的文件夹总是不变的。在进程启动的时候可以指定它的当前文件夹，例如在快捷方式的属性中有一个“起始位置”输入框，这个就是进程启动后的当前文件夹。如果在启动时不指定进程的当前文件夹（直接双击EXE文件的情况），那么EXE文件的所在文件夹就会作为它的当前文件夹。

纯粹的相对路径格式如下：

Windows\System32\calc.exe
要注意的是相对路径的开头不能有\，很多人以为有没有\都是一样的，其实不然，以\开头的路径是另外一种路径，下文会详细介绍这种路径。

如果在进程中操作文件时传递一个相对路径，那么进程会将当前文件夹的路径与这个相对路径合并，得到一个完整路径。例如命令提示符的当前文件夹是C:\Windows，如果执行start System32\calc.exe命令，程序就会将两个路径合并得到C:\Windows\System32\calc.exe。
由于这样的特性，当前文件夹又称为工作文件夹，因为进程使用相对路径时都是针对该文件夹的。

除了上面所说的纯粹的相对路径，还有两种特殊的相对路径，为了不至于混淆，不再将它们称为相对路径。

以\开头的路径

上面说过相对路径不能以\开头，一旦如此，它就表示相对于当前文件夹根目录的路径。例如进程的当前文件夹是C:\Windows，那么\System32\calc.exe就表示C:\System32\calc.exe。不论当前文件夹的路径有多深，只取根目录进行合并。可以在命令提示符中进行验证：首先将C:\Windows设置为当前文件夹，然后执行start \System32\calc.exe命令，将会提示错误，所找不到文件。再执行start \Windows\System32\calc.exe命令，这时计算器程序成功启动了，证明了上面的说法。

以盘符和冒号开头的路径

这种路径就像是拼写错误的完整路径，它的格式如下：
C:System32\calc.exe

盘符加冒号是一种特殊的表示法，表示的是进程在“该分区上的当前文件夹”。这里又蹦出来了一个当前文件夹，这与上文的当前文件夹是不同的。简单来说，对于每一个分区，进程都会保存在这个分区上最后使用的当前文件夹。可能解析的不够好，那么可以使用命令提示符来操作一遍以加深理解。

运行cmd，执行cd /d C:\Windows\System32命令进入该文件夹，然后切换到其它的分区，再执行C:calc.exe命令，可以看到计算器程序启动了。

我们在执行cd命令进入C:\Windows\System32文件夹后，进程便以此为当前文件夹，当切换到其余的分区时，进程先将这个文件夹的路径保存起来，再进行切换。使用盘符和冒号的形式读取指定分区上的当前文件夹。

路径中的限制

除了路径格式上的限制，还有很多字符上的限制，下面一一来看看各种路径有什么限制。

除了以\\?\开头的路径之外，其它路径的长度都不能超过260个字符（包括结尾的\0字符），而\\?\开头的路径长度可以达到约32000个字符（系统在处理\\?\前缀的时候可能将它扩展成更长的字符串）。网络上流传的一则技巧：文件路径太长而不能被删除，可以在执行del命令时在路径前加上\\?\前缀。

文件或文件夹名称的最后一个字符不能为空格或句点。但在路径中，最后一个字符可以为句点，因为路径中的句点表示的是当期文件夹（这与上文的当前文件夹完全不同），两个句点表示的是上一级文件夹。以\\?\开头的路径中不能使用句点表示当前文件夹或上一级文件夹，在资源管理器的地址栏中虽然可以这么做，那是因为资源管理器对其作了处理。

文件或文件夹名称不能包含的字符 ：
< > : ” / \ | ? *
在路径中可以使用 : \ ?，冒号是与盘符一起使用的，问号是\\?\前缀中特有的，除此之外不能出现这两个字符；而\是文件夹分割符。虽然我们也能使用/作为分隔符，实际上这是不允许的，系统在处理路径时会将/替换成\。另外，如果路径最后一个字符是\，那么该路径表示的是文件夹；否则表示的是一个文件。

UNC路径的计算机名部分不能出现以下字符：
` ~ ! @ # $ % ^ & * ( ) = + _ [ ] { } \ | ; : . ‘ “ , < > / ?
确实是够多的了，实际上标准的计算机名推荐只使用26个英文字母、10个数字以及-（连字符），否则可能会出现找不到计算机的情况。在更改计算机名的时候如果出现非标准字符，系统会作出提示。

建立测试环境

测试环境的建立，请参考soft-bin.com上之前的文章 “P/INVOKE使用方法万惊油”，查看C#文章分类即可找到这篇文章。

在建立了测试环境以后，我们可以编写C的程序供C#调用，我们还可以开启 Unmanaged Code Debugging来对C#传入到C中的参数进行调试查看。

字符串作为传入参数

很多函数要求将字符串传入其中，例如FindWindow函数。我们可以编写自己的C++测试函数：

void TestString(char* strIn)
{
    cout << strIn << endl;
}

这几乎是最简单的字符串测试了，在C#中作如下声明即可使用这个函数：

public static extern TestString(
    [MarshalAs(UnmanagedType.LPStr)]
    string strIn
);

为了简便起见，我将函数声明前的DllImport属性省去不写。

PINVOKE中使用字符串的关键在于为参数加上 MarshalAs属性，并指明其封送的格式，这里我指定的是 UnmanagedType.LPStr，也就是字符串。

我们知道，在C++中，字符串可能是较为原始的单字节字符串，也可能是宽字节的字符串。而UnmagedType中对应地也提供了： LPStr, LPTStr和LPWStr三种数据格式，分别对应C++中的 CHAR, TCHAR和WCHAR。

CHAR即表示ANSI字符，TCHAR则表示到底是ANSI还是UNICODE根据编译选项来决定，WCHAR则表示UNICODE字符。

三种对应使用的方式如下：

void TestString(TCHAR* strIn)
{
    cout << strIn << endl;
}

public static extern TestString(
    [MarshalAs(UnmanagedType.LPTStr)]
    string strIn
);

void TestString(WCHAR* strIn)
{
    cout << strIn << endl;
}

public static extern TestString(
    [MarshalAs(UnmanagedType.LPWStr)]
    string strIn
);

我们知道在C#中，字符串有两种表示方法，一种是string，另一种则是 StringBuilder。在字符串作为参数传入C函数时，我们即可以用string，也可以用StringBuilder。使用StringBuilder只需要将上例中的string替换为StringBuilder即可。

字符串作为函数返回值的情况

字符串作为返回值的情况与作为参数时是完全一样的，如下：

char* Greeting()
{
    static char* p = "Hello";
    return p;
}

[DllImport("Target.dll")]
[return:MarshalAs(UnmanagedType.LPStr)]
public static extern string Greeting();

对于TCHAR和WCHAR的处理，也同上，且我们同样可以使用 StringBuilder接受返回值。

字符串作为参数返回值的情况

这种情况的典型例子如下：

void GetString(char* pOut)
{
    ASSERT(pOut);
    strncpy(pOut, "hello", 5);
}

这种情况与前述string使用方法有些不同，前面 两种情况，我们可以选择string或者StringBuilder来封送数据，而在这种情况下，我们只能选择StringBuilder，即，只能以如下方式调用：

public static extern void GetString(
    MarshalAs(UnmanagedType.LPStr)]
    StringBuilder pOut
);

也就是说，对于传出型的参数，我们只能使用StringBuilder，这个其实很好理解，在C#中，string的内容是不可改变的，而StringBuilder中的内容则可以改变，我们可以将string视为 const char*， 则以下代码是不可接受的：

char a[10];
const char* p = a;
GetString(p);

总结