最开始知道Github Page，是通过codertrace上的某些注册用户，他们的BLOG就建立在Github Page上，并且清一色的干净整洁（简陋），这看起来很酷。

Github提供了很多很合coder口味的东西，例如Gist，也包括这里提到的Page。Page并不是特用于建立博客的产品，它仅提供静态页面的显示。它最酷的地方，是通过Git的方式来让你管理这些静态页面。通过建立一个repository，并使用markdown语法来编写文章，然后通过Git来管理这些文章，你就可以自动将其发布出去。

当然，要搭建一个像样点的博客，使用Github Page还不太方便。这里可以使用Jekyll。Jekyll是一个静态网页生成器，它可以将你的markdown文件自动输出为对应的网页。而Github Page也支持Jekyll。

为了更方便地搭建博客，我还使用了Jekyll-bootstrap。jekyll-bootstrap其实就是一些模板文件，提供了一些博客所需的特殊功能，例如评论，访问统计。

基于以上，我就可以像在Github上做项目一样，编写markdown文章，然后git push即可。可以使用jekyll --server在本地开启一个WEB SERVER，然后编写文章时，可以在本地预览。

Github Page还支持custom domain，如你所见，我将我的域名codemacro.com绑定到了Github Page所提供的IP，而不再是我的VPS。你可以通过kevinlynx.github.com或者codemacro.com访问这个博客。

当然实际情况并没有那么简单，例如并没有太多的theme可供选择，虽然jekyll-bootstrap提供了一些，但还是太少。虽然，你甚至可以fork别人的jekyll博客，使用别人定制的theme，但，这对于一个不想过于折腾的人说，门槛也过高了点。

jekyll-bootstrap使用了twitter的bootstrap css引擎，但我并不懂这个，所以，我也只能定制些基本的页面样式。

1年前我编写了ext-blog，并且在我的VPS上开启了codemacro.com这个博客。本来，它是一个ext-blog很好的演示例子，但维护这个博客给我带来诸多不便。例如，每次发布文章我都需要使用更早前用lisp写的cl-writer，我为什么就不愿意去做更多的包装来让cl-writer更好用？这真是一个垃圾软件，虽然它是我写的。另一方面，codemacro.com使用的主题，虽然是我抄的，但依然太丑，并且恶心。

更别说那个消耗我VPS所有内存的lisp解释器，以及那恶心的两位数字乘法的验证码---你能想象别人得有多强烈的留言欲望，才愿意开一个计算器？

说说codertrace.com。我其实写了篇关于codertrace.com的总结，但没有作为博客发布。做这个事情的结果，简单总结来说就是瞎JB折腾没有任何结果。我真的是个苦逼双子男，我每次做件事情都需要巨大的毅力才能让自己专注下去。

整个过程中，收到了些网友的邮件，看到了些评论，虽然不多。邮件/评论中有建议的，也有单纯的交流的，也有单纯鼓励的。我想说的是，thanks guys。

Anyway, try Github Page, save your VPS money :D.

因为写 ext-blog 的原因，慢慢喜欢上github_ 。然后突然有一天产生了一个想法：如果可以把自己的博客_ 和 github主页 集中到一块展示给别人，会不会是一种很方便的自我简介方式？然后我就动手写了 codertrace.com 。

所以， codertrace.com 这个网站的作用就是用来集中让程序员炫耀的。它通过RSS抓取，将你的博客，github主页，或其他有RSS输出的信息集中到一块展示给别人。这些信息通常就可以代表一个程序员。

如果你是程序员，也不妨试试。

技术信息

不知道哪个王八蛋说的，程序员每一年得学一门新语言。我2010年末接触了Lisp，然后莫名其妙地写了 ext-blog ，又莫名其妙地在2011年末接触了Ruby。因为大学期间太痴迷C++，我勤奋努力，几乎通晓这门语言的各种细节；后来又稍微实践了下编译原理。在这若干年间，断断续续也接触过其他脚本类语言，我甚至在android上用java写过几个 小应用 。基于这些积累，我发现我可以很快上手Ruby，然后再上手Rails，然后就有了 codertrace.com （当然还做过一些小的 APP )

所以， codertrace.com 就是一个Ruby on Rails的应用。当我用这货来做WEB的时候，我才发现曾经用Lisp写博客是多么geek。这种感觉就像你在用汇编写一个GUI程序一样。我的意思是，ruby/rails的世界里有太多现成的东西，但lisp的世界里没有。

而且，ruby是一个很爽的语言。我太喜欢它的closure语法，简洁，不需要加其他关键字就可以构造（例如其他语言map(function (item) xxxx end)，或者map(lambda (item) xxx )）。但我不喜欢在使用的地方通过yield去调用---这就像一个hack。我更不喜欢ruby用proc去封装closure。好吧，这其实是我自我分裂，为什么我要把ruby看成一个函数式语言？

脚本语言真是太酷了。

服务器信息

我很穷。不管你信不信，我真的舍不得花1000RMB买个VPS来架设 codertrace.com 。目前， codertrace.com 架设在 heroku.com ，而且还使用的是免费服务。免费服务竟然只有5M数据库。 codertrace.com 后台为了异步抓取用户提供的RSS，还使用了一个单独的进程(delayed_job ruby gem)。这也不是免费的。

但ruby的世界里有太多现成的东西了，甚至有很多现成的库解决这里的两个问题：heroku_external_db，这个gem可以让codertrace使用heroku以外的数据库，然后我就在我的VPS上搭了个mysql，这下流量和网站响应速度悲剧了啊，你想你请求个页面，这个页面直接涉及到若干条数据库查询。而这些查询的请求和回应竟然是通过internet网络传输的。

workless，这个gem可以在有异步任务时，例如codertrace上读取RSS，就会自动开启这个worker进程，然后heroku开始计费，当没有任务时，它又自动关闭这个进程。虽然省了美元，但再一次让网站的响应速度打了折扣。

为了实现自定义域名，我需要将 codertrace.com 指向 heroku.com 提供的IP。但也许你会同我一样愤怒，因为它提供的几个IP都被GFW墙了！所以，目前的实现方案是，我将 codertrace.com 指向了我博客对应的VPS，然后在VPS上使用nginx反向代理到 heroku.com 提供的IP。即使如此，我最近甚至发现 codertrace.com 竟然神奇般地会域名解析错误，难道godaddy的name server也要被GFW和谐？？

故事

作为一个宅男，在工作的若干年中，若干个假期我都用来打游戏，或者写程序。

所以，当这个成为习惯的时候， codertrace.com ，就顺理成章地消费了我今年的春节假期。我发现一个人窝在租的小房子里写代码是件很爽的事情。在当前这个社会环境下，你可以专注地去干件喜欢的事情，还不用处理各种生活琐事，真是太爽了。

但为什么我平时得不到这种感觉？因为，我，是一个没钱的程序员。我和我老婆租在一个标间里。在这样狭小的空间里，多个人就是多几倍干扰。这太残酷了。

末了

曾经我以为我很牛逼，曾经我以为程序员很牛逼。后来我慢慢发现自己很垃圾。我没有写出来过牛逼的程序，大概也没能力写。还记得那个程序员的故事吗？就是有个傻逼也以为程序员很牛逼，但不幸在一家非IT公司的IT部门工作，他的程序员同事的工作就是每周填个excel表格。他后来很绝望，因为他没有为世界贡献过任何代码。后来，这货丢下一切，坐上去某地的飞机走了。

题外

飞秋是一款局域网内的IM软件，界面类似QQ，实现上与飞鸽（IP message）有点渊源，免费，不开源。

公司大概两年前开始使用这款软件作为员工之间办公吹牛的工具。最近游戏玩得少，就想彻底换到linux下，

组内也有其他两人是llinux-er，不过悲剧的是换到linux下就无法收取飞秋群里的聊天信息了，不免寂寞。

所以，就想写个协议兼容的程序（或者说改个东西）来收取群信息。

准备

我本身并不擅长逆向工程，破解什么的纯碎业余。在GOOGLE/BAIDU之后发现并没有前人留下的成果。

使用抓包程序，以及综合网络上的信息，还是可以得出不少有用的信息：

# 飞秋兼容了飞鸽的协议，其协议格式基本上基于文本形式，各个内容之间使用冒号作为分隔，例如：

1:100:user:pcname:32:message_body

# 飞秋在私聊情况下的消息内容是没有加密的，但群聊信息加密了，解密这个内容也是我的目标所在

# 在抓包软件下根据消息的目标IP地址可以推断飞秋发送群信息是基于UDP组播的，即就算你不是这个群

   的成员，也会收到群消息

有用的文章： 《局域网内实现飞鸽欺骗》、《飞鸽传书数据加密分析》(个人感觉没有任何实质内容，而

且飞鸽传书并不是飞秋，属于误导性文章，但是依然有用）。最重要的，稍微浏览IP message的代码，

以及linux下的iptux（另一个兼容飞鸽的局域网IM）代码，都是对接下来的破解有益的。

破解

我希望我提供更多的，是一种crack的思路，虽然我不是一个cracker。破解和写程序不太一样，它需要

更多的耐心、运气、程序之外的思考。如前所做的准备，尤其重要。

工具及环境：飞秋2.4版本、OllyDbg，为了方便接收群信息，最好有两台电脑。

STEP 1 找入手点

在开始面对一大推汇编代码时，我们需要一个最接近目标的点。获取这个点根据目标的不同而不同。例如，

这里主要是针对网络数据的解密。所以，最直接的就是去找这些网络数据。当然，根据具体程序的表现，也

可以从其他点入手，例如飞秋收到群消息后会在任务栏闪烁图标，也可以从这个功能逆向过去。

因为飞秋使用UDP协议，所以我们可以在recvfrom函数下断点（bp recvfrom）。因为接收UDP包的接口

可能还有WSARecvFrom，甚至winsock1.0中的recvfrom，所以最好都下断点。另一台机器发送群消息，

程序在winsock1.0里的recvfrom断下来：

71A43001 >  8BFF            mov     edi, edi
71A43003    55              push    ebp
71A43004    8BEC            mov     ebp, esp
71A43006    51              push    ecx

这个不是我们需要的，我们需要根据这个点获得用户层代码，这将是整个破解过程的起点。所以，OD中

ALT+K查看调用堆栈，然后跳到调用recvfrom的函数处：

00490890  /$  56            push    esi                              ;  接收数据的函数入口
00490891  |.  8B7424 08     mov     esi, dword ptr [esp+8]
00490895  |.  8D46 10       lea     eax, dword ptr [esi+10]
00490898  |.  50            push    eax                              ; /pFromLen
00490899  |.  56            push    esi                              ; |pFrom
0049089A  |.  C700 10000000 mov     dword ptr [eax], 10              ; |
004908A0  |.  8B09          mov     ecx, dword ptr [ecx]             ; |
004908A2  |.  6A 00         push    0                                ; |Flags = 0
004908A4  |.  8D46 18       lea     eax, dword ptr [esi+18]          ; |
004908A7  |.  68 FF3F0000   push    3FFF                             ; |BufSize = 3FFF (16383.)
004908AC  |.  50            push    eax                              ; |Buffer
004908AD  |.  51            push    ecx                              ; |Socket
004908AE  |.  E8 C7F30C00   call    <jmp.&WSOCK32.#17>               ; \recvfrom

邪恶的OD已经将调用recvfrom时传入参数的指令标记出来了。中文注释是我分析时加的。recvfrom里传入

的接收缓存，是我们应该关注的。如果能跟进这个缓存，假设程序的流程比较简单：接收了数据，然后在某个

地方直接解密，不管它的加密方式是什么，只要能找到这个缓存数据从加密变为解密的地方，对于整个破解而言，

都算是迈进了一大步。

于是，在00490890（上面找到的函数入口）下断点，准备跟进接收缓存。注意：在OD里调试跟在vc里不一样，

跳到调用堆栈里的某个函数，寄存器依然是当前的值。所以需要重新跟。

STEP 2 内存断点

F9让程序继续运行，再次在另一台机器上发送群消息。这回程序在00490890处断下，然后跟接收缓存：

004908AC  |.  50            push    eax                              ; |Buffer = 0011F4CC
004908AD  |.  51            push    ecx                              ; |Socket
004908AE  |.  E8 C7F30C00   call    <jmp.&WSOCK32.#17>               ; \recvfrom

接收缓存Buffer的值为0011F4CC，如前所述，我们要跟进这个地址指向的内存的变化情况。F8单步运行到

recvfrom后，也就是接收了网络数据后，查看内存内容

(d 0011F4CC)：

0011F4CC  31 5F 6C 62 74 34 5F 30 23 31 32 38 23 38 38 41  1_lbt4_0#128#88A
0011F4DC  45 31 44 44 34 36 36 46 44 23 30 23 30 23 37 32  E1DD466FD#0#0#72
0011F4EC  3A 31 32 39 35 37 32 31 32 31 33 3A 41 64 6D 69  :1295721213:Admi
0011F4FC  6E 69 73 74 72 61 74 6F 72 3A 50 43 2D 32 30 31  nistrator:PC-201
0011F50C  30 31 31 30 34 32 30 30 35 3A 34 31 39 34 33 33  011042005:419433
0011F51C  39 3A 5E 3B 83 A1 14 6D A4 D2 E3 D8 E8 AB B1 3A  9:^;儭mひ阖璜?
0011F52C  5B BC C2 FE E9 DA CB DD 00 BC 59 FC 9D A7 D7 91  [悸谒?糦鼭ё

内容开头正是飞秋的协议头，未加密，不过没多大用。根据之前获取的飞秋协议，可知，在0011F51E

处就是聊天内容的密文。

很自然地，为了监视这段内存的变化情况，在该位置下内存访问断点（右击数据区即可看到下断点的选项）。

F9继续走，然后马上断下来：

0049010F  |.  F3:A5         rep     movs dword ptr es:[edi], dword ptr [>
00490111  |.  8B4A 04       mov     ecx, dword ptr [edx+4]
00490114  |.  C74424 24 000>mov     dword ptr [esp+24], 0
0049011C  |.  894D 64       mov     dword ptr [ebp+64], ecx
0049011F  |.  33C9          xor     ecx, ecx

程序到了一个陌生的环境（在这种满世界都是汇编代码的情况下，几乎一不小心就会迷失其中），看了下

附近的代码，没什么可疑。通过下内存访问断点的思路，似乎显得荆棘丛生。

STEP 3 靠近目标

不妨冷静下来思考，如果没有直接的路，我们可能需要悲惨地大海捞针。在写一个网络程序时，网络底层

收到数据包，无非要么直接进行逻辑处理，要么缓存到一个逻辑处理队列里稍后处理。后者虽然对于程序员

而言是个好方法，但是因为跨了线程，又涉及到队列缓存，对于逆向而言，绝对是悲剧。

但是如果使用了前者呢？对于一个网络客户端程序而言，也许直接进行逻辑处理才是最KISS的方法。（这种猜测

的破解方式，绝对需要运气。）所以，如果是直接进行处理，那么在接收到网络数据附近，必然就有解密函数。

所以，不妨顺着收包函数附近随意浏览一番。（但不要走进太深的call，不然又迷失了。）

0048FE10  /$  B8 18400000   mov     eax, 4018                          
0048FE15  |.  E8 560A0C00   call    00550870
0048FE1A  |.  8D4424 00     lea     eax, dword ptr [esp]
0048FE1E  |.  56            push    esi
0048FE1F  |.  8BF1          mov     esi, ecx
0048FE21  |.  50            push    eax
0048FE22  |.  E8 690A0000   call    00490890                             ;  接收网络数据

0048FE10函数调用了刚才发现的收包函数。这个函数在收完数据后，不久就调用了另一个函数：

0048FE3F  |.  51            push    ecx
0048FE40  |.  52            push    edx
0048FE41  |.  8BCE          mov     ecx, esi
0048FE43  |.  E8 88020000   call    004900D0                             ;  似乎很可疑？

进到004900D0函数，发现这个函数真TMD巨大。随意浏览之，发现OD有这种提示：

00490178  |.  68 34FD5E00   push    005EFD34                             ;  ASCII "_lbt"
0049017D  |.  8D4C24 14     lea     ecx, dword ptr [esp+14]
00490181  |.  89BC24 544000>mov     dword ptr [esp+4054], edi

_lbt，恩，消息头里有这个字符串标识。估计是在做些消息头的逻辑操作。这个函数太长，里面还有若干call，

可谓头大。所以说，代码写得丑，可读性差，对于防破解还是颇有益处的。跳回到0048FE43，发现当前

函数基本完了。

于是往上看，来到调用这个函数的地方：

0050F647  |.  E8 C407F8FF   call    0048FE10
0050F64C  |.  BF 01000000   mov     edi, 1

回顾下，我们有函数A接收网络数据，有函数B调用A，现在回到了C，来到了调用B的地方0050F647。C函数

也很巨大，直接往下浏览，会发现一些switch语句：

0050F71A  |.  81E6 FF000000 and     esi, 0FF
0050F720  |.  8D46 FF       lea     eax, dword ptr [esi-1]               ;  Switch (cases 1..D3)
0050F723  |.  3D D2000000   cmp     eax, 0D2
0050F728  |.  0F87 8C000000 ja      0050F7BA
0050F72E  |.  33C9          xor     ecx, ecx
0050F730  |.  8A88 60315100 mov     cl, byte ptr [eax+513160]
0050F736  |.  FF248D 403051>jmp     dword ptr [ecx*4+513040]
0050F73D  |>  8D9424 F40000>lea     edx, dword ptr [esp+F4]              ;  Case 1 of switch 0050F720

往后浏览下这个switch…case，发现非常之大，这个函数也因此非常巨大。不妨猜测这个是根据不同消息做不同

逻辑处理的地方。这个想法正是给予我们灵感的关键。

群聊消息必然也有个类型，通过之前OD获取到的网络数据（或者截取网络封包所得），群聊消息的类型为：4194339

（16进制400023H），去掉高位，也就是23H。仔细地对比每一个case，果然发现了一段处理代码：

00512787  |> \39AC24 640100>cmp     dword ptr [esp+164], ebp             ;  Case 23 of switch 0050F720
0051278E  |.  75 07         jnz     short 00512797                       ;  群聊天处理
00512790  |.  8BC7          mov     eax, edi
00512792  |.  E9 8C080000   jmp     00513023

这个代码之下的处理也有不少代码。在不涉及到更多细节之前，我们可以大胆地将注意力放在接下来的call上。从这个case

往下，第一个call为：

005127E6  |.  50            push    eax
005127E7  |.  E8 A4A20000   call    0051CA90                             ;  非常可疑
005127EC  |.  B8 01000000   mov     eax, 1
005127F1  |.  E9 2D080000   jmp     00513023

STEP 4 多尝试

有怀疑，就用事实来证明。果断地在005127E6处下断点。然后发群消息，程序断下来。因为这个函数压入了

eax作为参数，且对ecx做了赋值：

005127E4  |.  8BCB          mov     ecx, ebx
005127E6  |.  50            push    eax
005127E7  |.  E8 A4A20000   call    0051CA90                             ;  非常可疑

在调用一个函数前对ecx做赋值，一般都是C++成员函数调用。eax作为一个参数，非常值得关注，果断查看eax

指向的内存值：

001235C8  41 64 6D 69 6E 69 73 74 72 61 74 6F 72 00 6D 00  Administrator.m.
001235D8  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
001235E8  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
001235F8  00 00 50 43 2D 32 30 31 30 31 31 30 34 32 30 30  ..PC-20101104200
00123608  35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  5...............
00123618  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00123628  8A 7B 00 00 C0 A8 00 03 09 79 00 00 01 00 00 00  妠..括..y.....
00123638  04 00 00 00 00 00 00 00 80 00 00 00 38 38 41 45  .......€...88AE
00123648  31 44 44 34 36 36 46 44 00 00 00 00 00 00 00 00  1DD466FD........
00123658  00 00 00 00 F4 C7 23 00 FD 22 3B 4D 23 00 40 00  ....羟#.?;M#.@.
00123668  49 00 00 00 36 00 00 00 5E 3B 83 A1 14 6D A4 D2  I...6...^;儭mひ

有用户名、机器名、发送者MAC地址，这么多可疑信息。完全可以猜测，eax传入的是一个结构体地址，

当然对象地址也可以，反正是个复杂数据结构。更重要的，在这块内存往下不远处，果断地发现了从

网络接收到的加密的聊天内容：

00123670  5E 3B 83 A1 14 6D A4 D2 E3 D8 E8 AB B1 3A 5B BC  ^;儭mひ阖璜?[
00123680  C2 FE E9 DA CB DD 00 BC 59 FC 9D A7 D7 91 CF 5A  漫橼溯.糦鼭ё懴Z

F8直接步过0051CA90函数。任务栏开始出现闪烁的图标（虽然没有闪），上面的内存数据变了：

00123670  74 65 73 74 7B 2F 66 6F 6E 74 3B 2D 31 34 20 30  test{/font;-14 0
00123680  20 30 20 30 20 34 30 30 20 30 20 30 20 30 20 31   0 0 400 0 0 0 1
00123690  33 34 20 33 20 32 20 31 20 32 20 CB CE CC E5 20  34 3 2 1 2 宋体

test正是我发的内容。

STEP 5 缩小范围

实际上走到这里，凭借运气和程序编写的常识，已经找到关键点。不过看来0051CA90这个函数做的事情

有点多，除了解密内容似乎还有UI上的一些处理（例如那个闪烁的任务栏图标）。所以，我们要做的是，进一步

跟进，找到关键点。

现在缩小范围要容易得多，因为我们得到了一个会变化的内存地址：00123670。只需要F8一步一步地

运行代码，一旦发现内存内容改变，则可以进一步进如，从而找到关键call。具体过程我就不给了，大概为：

0051CB02  |.  52            push    edx
0051CB03  |.  68 00400000   push    4000
0051CB08  |.  56            push    esi
0051CB09  |.  50            push    eax
0051CB0A  |.  56            push    esi
0051CB0B  |.  E8 F041F7FF   call    00490D00                             ; 跟进

00490DB0  |.  6A 00         push    0
00490DB2  |.  83E1 03       and     ecx, 3
00490DB5  |.  6A 22         push    22
00490DB7  |.  F3:A4         rep     movs byte ptr es:[edi], byte ptr [es>
00490DB9  |.  8BBC24 344000>mov     edi, dword ptr [esp+4034]
00490DC0  |.  50            push    eax                                  ;  数据长度
00490DC1  |.  8D4424 20     lea     eax, dword ptr [esp+20]
00490DC5  |.  57            push    edi                                  ;  输出缓存
00490DC6  |.  50            push    eax                                  ;  输入缓存（加密内容）
00490DC7  |.  8D4C24 20     lea     ecx, dword ptr [esp+20]
00490DCB  |.  E8 5049F7FF   call    00405720                             ;  最终解密函数

00405720函数内的实现基本上全是数据操作指令。加解密算法无非就是捣鼓这些数据，所以当我进到

00405720函数时，基本上可以断定它就是最终的解密函数。

STEP 6 解密

事实上我们并不需要去弄懂它的具体解密算法，就算是直接的C++代码，没有算法论文的话也很难看懂，更何况

是这里的汇编。最直接的方式，就是查看这个解密函数对外界的依赖情况，例如需要的参数，this里是否有依赖

的数据。在了解了这些情况后，大可以将这段汇编复制出来直接作为C++内嵌汇编代码使用。

不过，这里我想到了更简单的方式。因为我注意到飞秋和飞鸽在实现上有着不解之缘，而且我琢磨着作者也不会

为了一个加解密不太重要的应用场合而去整些高深的算法。我想到，飞秋也许会直接使用飞鸽里的加解密代码！

在IP message的源码里，有blowfish加密算法的实现，我们来看接口：

class CBlowFish
{
private:
    DWORD    *PArray;
    DWORD    (*SBoxes)[256];
    void    Blowfish_encipher(DWORD *xl, DWORD *xr);
    void    Blowfish_decipher(DWORD *xl, DWORD *xr);

public:
            CBlowFish(const BYTE *key=NULL, int keybytes=0);
            ~CBlowFish();
    void    Initialize(const BYTE *key, int keybytes);
    DWORD    GetOutputLength(DWORD lInputLong, int mode);
    DWORD    Encrypt(const BYTE *pInput, BYTE *pOutput, DWORD lSize, int mode=BF_CBC|BF_PKCS5, _int64 IV=0);
    DWORD    Decrypt(const BYTE *pInput, BYTE *pOutput, DWORD lSize, int mode=BF_CBC|BF_PKCS5, _int64 IV=0);
};

从接口实现来说算是简洁漂亮友好和谐。我也用Decrypt这个函数的参数比对了上面没找到的那个call（00405720），

因为这里只是怀疑这个call就是这里的Decrypt，但并没有确切的证据。不过，对比下他们的参数就可以非常肯定了：

最重要的，是参数mode。Decrypt默认参数mode是BF_CBC|BF_PKCS5的位组合，结果，恰好为22！

所以，基本上可以断定：飞秋的加解密实现，就是使用了IP message的blowfish算法：blowfish.cpp/h/h2。

STEP 7 密钥

查看CBlowFish的使用，在解密前需要初始化，大概就是传入密钥之类。如果我们上面的猜测没有错，那么我们

从网络上取得的数据，然后取得密钥，直接使用blowfish的源码，就可以解密出消息内容。

接下来的关键就是，找到这个密钥。关于这个密钥，之前在飞秋的配置文件FeiqCfg.xml里绕了很久的圈子，因为

发现加入一个群的时候，这个文件里就会多出一项很长的16进制字符串。也一度猜测密钥就是保存在这个字符串的

某个偏移里。接下来会让人大跌眼镜。

因为CBlowFish这个类确实简单，使用它的最简单方式就是直接创建局部对象，然后传入key和keysize，即可完成

初始化。在之前展示的思路里，我也一度先去尝试最简单的方法。对于C++局部对象的创建，有个显著特征就是

mov ecx, dword ptr [esp+xxx]，也就是往ecx里写入一个栈地址。而且可以肯定的是，这个构造代码，必然发生

于call 00405720前面不远处，往上跟进：

00490D3F  |> \8B8C24 304000>mov     ecx, dword ptr [esp+4030]
00490D46  |>  51            push    ecx                                  
00490D47  |.  52            push    edx                                  
00490D48  |.  8D4C24 0C     lea     ecx, dword ptr [esp+C]
00490D4C  |.  E8 3F3DF7FF   call    00404A90                             

一个压入两个参数的函数调用，对比CBlowFish的构造函数，刚好是2个参数。跟进00404A90：

00404A90  /$  56            push    esi
00404A91  |.  8BF1          mov     esi, ecx
00404A93  |.  6A 48         push    48
00404A95  |.  E8 69301600   call    00567B03
00404A9A  |.  68 00100000   push    1000
00404A9F  |.  8906          mov     dword ptr [esi], eax
00404AA1  |.  E8 5D301600   call    00567B03

又是可爱的立即数！48H、1000H，这种特别的立即数总能让人安心，对比CBlowFish构造函数实现：

CBlowFish::CBlowFish (const BYTE *key, int keybytes)
{
    PArray = new DWORD [NPASS + 2];//NPASS=16
    SBoxes = new DWORD [4][256];

    if (key)
        Initialize(key, keybytes);
}

sizeof(DWORD)*18=48H，sizeof(DWORD)*4*256=1000H！这么极具喜剧意义的汇编C++代码映射，

基本可以肯定，00404AA1处，正是构造CBlowFish对象的地方，而构造的参数，正是我们魂牵梦萦的解密密钥：

00490D46  |> \51            push    ecx                                  ;  key长度
00490D47  |.  52            push    edx                                  ;  密钥key
00490D48  |.  8D4C24 0C     lea     ecx, dword ptr [esp+C]
00490D4C  |.  E8 3F3DF7FF   call    00404A90                             ;  构造blowfish对象

在此处下断点，发送群消息，程序断下来，看看密钥究竟是什么。如果它确实是FeiqCfg.xml里的某个值，

那么我们还要进一步跟这个值具体在哪个配置项里。看看吧，密钥edx：

edx=00123644, (ASCII "88AE1DD466FD")

TM的密钥居然是发送者的MAC地址！当我看到这个的时候我几乎快摔倒地上。如果飞秋使用一个MAC地址

作为密钥，那么这意味着：通过自己写的程序，可以取得局域网内其他群里的聊天内容！这个实在太邪恶了。

上回抓包的时候，虽然看不到内容，但可以看到美术、策划在群里聊的无比欢乐。这回有喜感了。

STEP END 可略

看看时间，悲剧地发现整篇文章花了接近3个小时才写完。此刻我正踌躇要不要把代码发上来，但转念一想

最后那个STEP的发现实在让人蛋疼，所以还是算了。打算稍微封装下，然后使用这份代码在iptux 上改改包装

个界面，目的就算达成了。相信浏览完整篇文章，写出自己的代码不是什么大问题。

其实我大可以直接给结论，但是我依然乐于分享过程和思路。一来算是自我总结记录（每次拿起OD，总是快捷

键一路忘）；二来也给有心人一个指引。

最后，对这种东西还是有必要出个免责声明：根据本文章所造成的一切后果与文章作者无关。为了不糟蹋我这3个

小时的时间，转载麻烦注明出处。

PS，最后回顾下结论，其实发现这个解密非常非常简单。你说如果直接给卢本陶（飞秋作者）发封邮件，他会不

会直接告诉我？

在我自己写的一个工厂类实现中，每个产品会注册创建接口到这个工厂类。工厂类使用这些
注册进来的创建接口来完成产品的创建。其结构大致如下：

product *factory::create( long product_type )
{
    creator c = m_creators[product_type];
    return c();
}

factory::instance().register( PRODUCT_A_TYPE, productA::create );
...
factory::instance().create( PRODUCT_A_TYPE );

这个很普通的工厂实现中，需要写上很多注册代码。每次添加新的产品种类时，也需要修改
这些的注册代码。而恰好，这些注册代码可能会被放在一个统一的地方。为了消除这个地方
，我使用了偶然间看到的<Modern C++ design>里的做法：

const bool _local = factory::instance().register( PRODUCT_A_TYPE,...

也就是说，通过对全局常量_local的自动初始化，来自动完成对该产品的注册。

结果，因为这些代码全部被放置于一个静态库。最终的代码文件结构大致为：

lib
    - product_a.cpp : 定义了全局常量_local
    - product_a.h
    - factory.cpp
    - factory.h
exe
    - main.cpp

现在看起来世界很美，因为factory甚至不知道世界上还有个跟上层逻辑相关的product_a。
这种模块耦合几乎为0的结构让我窃喜。

悲剧的事情首先发生于，开VC调试器，发现打在product_a.cpp里的断点失效。就是那个总
是提示说没有为该文件加载调试符号。开始还不在意，以为又是代码和调试符号文件不匹配
的原因，折腾了好久，不得其果。

后来分析了下，发现这个调试提示，就像我开着调试器打开了一个非本工程的代码文件，而
断点就打在这个文件里一样。也就是说，VC把我product_a.cpp当成不是这个工程里的代码
文件。

按照这个思路写些实验代码，最终发现问题所在：VC链接器根本没链接进product_a.cpp里
的代码。表现出来的情况就是，该编译单元里的全局常量（全局变量一样）根本没有得到初
始化，因为我跟到factory::register并没有被调用到。为什么VC不链接这个编译单元对应
的目标文件？或者说，为什么VC不初始化这个全局常量？

原因就在于，product_a.cpp太独立了。一个在整个编译链接阶段都无法确定该文件是否被
使用的文件，VC就直接不链接了。相反，当在factory.cpp里写下类似代码：

void test()
{
    product_a obj;
}

虽然说test函数不会被调用，一切情况也变得正常了。好了，不扯了，给最后我的结论：

1、如果静态库中某个编译单元在编译阶段被确认为它并没有被外部使用，那么当这个静态
库被链接进可执行文件时，链接器忽略掉该编译单元里的代码，那么，链接器自然也不会为
该编译单元里出现的全局变量常量生成初始化代码（关于这部分初始化代码可以阅读
<linker and loader>一书）；
2、上面那条结论存在一种传染性，意思是，当可执行文件里的代码使用到静态库中文件A里
的代码，A里又有地方使用到B里的代码，那么B依然会被链接。这种依赖性，应该可以让编
译器在编译阶段就发现（显然，上面我举的例子里，factory只有在运行期间才会依赖到
product_a.cpp里的代码）

恰好最近在做一个GUI工具，想在界面开发上尽量快一点。每一次用上MFC都让我觉得浑身难受，总有些常用的

界面功能它就是没有。在接口实现上，MFC基本上就只是封装了WIN API而已。想想世界上还有什么强大的GUI库，

找了一下，其实不管GUI库封装的怎么样，我更多地还是需要一个工具，能够快速地堆积出界面。

于是，在网上下载了被国人精简了的bcb2009。然后，噩梦开始了。首先，我需要把逻辑层代码（也就是实现具体

功能的那一层）移植到BCB下。然后得到了很多和语法相关的编译错误：

1.
E2397: Template argument cannot have static or local linkage

这个错误发生于：

void func()
{

    struct Info

    {

    };

   std::queue<Info> abc;
}

它的意思是，模板参数必须是全局链接的，总之它不允许std::queue的参数是一个在函数内部临时定义

的类型（谁来告诉我这是C++标准）。

2.

E2357 Reference initialized with 'FileLoader::RawData', needs lvalue of type 'FileLoader::RawData'

这个错误发生于：

FileLoader::RawData FileLoader::GetRawData() const;

FileLoader::RawData &raw = loader.GetRawData(); //不能用引用

很久没看C++书，所以，谁又来告诉我C++标准里，这里到底能不能用引用？

3.

E2515 Cannot explicitly specialize a member of a generic template class

这个错误发生的情景更复杂些：

template <typename _Tp>

class Test
{

   template <typename _U>

   class Other;

   template <>

   class Other<void>

   {

   };
};

意思是说，我不能在一个模板类里特化成员模板类。谁又来告诉我标准规定的是什么？

4.

void func( Obj &a )
{
}

func( Obj() );这个也被视为错误。必须得在调用func之前自己定义个临时变量。

5.

我曾经留下了关于宏递归的一些代码，被用在我写的lua-binder和lua-caller中自动生成代码。这下好了，

BCB开始警告我，我的这些宏不能工作了。它和MSVC在某些事情上分歧可真是大：

#define PARAM( n ) ,typename P##n //注意这个宏包含一个逗号

#define CHR( x, y ) CHR1( x, y )

#define CHR1( x, y ) x##y

#define BCB_ERROR( a, b ) CHR( a, b )

BCB_ERROR( 1, PARAM( 1 ) ) 当这样使用宏时，基于我在GNU C上看到的关于宏的规则，会先展开

PARAM(1)，于是得到BCB_ERROR( 1, ,typename P2 )。然后，BCB认为PARAM(1)展开的逗号需要参与

BCB_ERROR的展开了。于是，我的整个宏库无法工作了。

关于这个问题，我直接用MSVC写了个生成器，让MSVC替我生成各种参数的lua-binder和lua-caller，然后

写成外部头文件，最后直接在BCB里包含了这些头文件。从而使我的lua-binder和lua-caller可以继续使用。

然后，我的1W多行代码终于在BCB下50多个WARNINGS的提示下编译成功了。怀揣着兴奋的心情，想自己终

于可以rapid开发界面了。创建了个VCL FORM APPLICATION，噩梦又开始了：

1.

BCB莫名其妙地在我编译一个CPP文件时给出如下提示：

F1004 Internal compiler error at 0x59b4ea8 with base 0x5980000

看起来像是BCB的编译器给崩溃了。囧。google了一下，发现不是我人品问题，很多人遇到相同的问题。

别人给出的解决方案是：restart your bcb。从昨天晚上到现在为止，这个错误发生了好几次。

2.

new std::ofstream();会让程序崩溃，往不该写的地方写了东西。我就奇怪了，你BCB自己带的C++IO实现，

难道还有BUG？再次google，还真发现是BCB自己的BUG，并且在几个版本之前就存在这个BUG。那个天真

的老外还说希望在BCB2009下能被修复。修改方案如下：

1）xlocale文件里把这句话注释了：*(size_t *)&table_size = 1 << CHAR_BIT;

2）xlocale里把成员_Id_cnt访问属性改为public，然后在自己的文件里定义一次。

3.

程序终于可以运行了。但是BCB的IDE环境总是不那么贴心。我移动了几个窗口改成我习惯的样子，但是一重启

居然又恢复成default（难道是因为盗版）。它的智能提示似乎总是跟着鼠标指针，有时候指向某个符号，鼠标

就显示忙。为了提示某个类的成员，某个函数的原型，BCB偶尔都会卡一下。其实我不介意我的编辑器没有这

些提示功能，在MSVC下我也从不用VA来帮我写代码。我甚至不厌其烦地在VIM下敲代码切窗口去看函数原型，

但是，你他妈作为一个IDE就得像个IDE的样子，要不，你干脆关掉所有功能，别给我卡就行了。

这个时候我开始怀疑选择BCB会不会是一个错误的开始，或者说在使用某个东西时，总会带着使用其他同类东西

的感觉甚至偏见去看待这个新事物。但是，在我想坚持继续使用BCB时，我一compile，它又提示我：

F1004 Internal compiler error at 0x59b4ea8 with base 0x5980000

其实，我们都知道，auto_ptr这些东西始终是无法避免野指针和空指针带来的灾难。
SAFE_DELETE也不能阻止别人使用这个空指针。

在我看过的一些开源项目的代码中，这些代码给人的感觉就是别人总能详细地掌控各种资源
（包括指针及其他变量）的使用情况。相比之下，公司隔壁组的老大则显得保守很多。他要
求我们几乎要对所有指针的使用进行空值判断（野指针也判断不了），当然，各种成员变量
也要进行即使现在看上去没多大用的初始化。

也许，这样做后程序是不会挂掉了。但是，就我们的观点来看，这样反而会隐藏一些BUG。
为什么我们不能详尽地去管理一个指针？一个指针变为空了，总是因为在这之前发生了错误
。当然，野指针本身就是愚蠢代码产生的东西，这里没必要讨论。空指针之所以为空，也是
因为在很多时候我们把空作为失败/错误/无效的标志。

恰好上周我的一些代码就真的在空指针上出现了问题。外网的服务器随时会因为玩家的一些
临界操作行为而崩溃掉。虽然我通过修改脚本来屏蔽这个问题（因为不能说停机维护就停机
维护），但是总感觉程序是不安全的。人不吃点教训绝对不学乖。

后来我对这个问题彻底思考了一下。很多程序员都自认聪明。在写C++程序时，我从来不提
供没用的public接口，尤其是set/get。我也从来不对没必要的成员变量进行初始化。我给
的理由是对于这些东西我都有很清晰的把握，我为什么要做stupid的事情？

但是，我几乎从来没有界定，指针在哪些情况下需要去判断为空？函数的参数绝对不需要。
假如函数的参数就是个空指针，那是client程序员的责任。仅供模块内使用的指针（包含其
他资源）在内部使用时也不需要去判断。如果去判断了，那说明你对你自己写的模块都缺乏
精确的把握，证明你的设计思维不够清晰。

什么时候需要判断？当指针依赖于外部环境时，例如读配置文件、载入资源，因为外部因素
不确定不在自己控制范围内，那么进行判断。同样，当使用了其他模块返回的指针值时，也
需要判断。这个其实和“外部环境”属于同一种情况。因为我们对其他模块也不清楚，更为
隐蔽的是（随着其他模块的改变，将来会在你的模块里爆发崩溃错误），其他模块由别人维
护，其变化更不受自己控制。之前我对这一点界定不是很清楚，这也是我犯错的原因。

现在想想，像游戏服务器这种程序，里面塞着各种各样的游戏功能。无论是哪一个模块出现
个空指针访问出错的问题，都会直接让服务器崩掉。关键是这个结果经常伴随着玩家的损失
。所以理想状态下，把每一个模块都放置在单独的进程里，确实是很有好处的。

做一些诸如ALPHA混合旋转缩放的操作，在游戏客户端应该是很容易的事。但是这事要在服务

器做，就不得不引入一些第三方库。反正我们的服务器运行于WINDOWS下，这里又需要处理

JPG图片的加载，我就考虑到了GDI+。

在这之前对GDI+没有过任何接触。直接翻了MSDN，还好居然有个一系列的usage。GDI+的Image

本身支持JPG的直接载入。但是并没有我理想中的CreateFromMemory( const void *buf )接口。

看起来唯一可以从内存创建Gdiplus::Image对象的方法是从一个叫IStream*的COM东西。我揣摩

微软为什么没有提供我理想中的那个接口，或者说要把GDI+设计成这样，可能还是考虑到对多语

言的支持。于是问题转换为如何将一个C语言的const void*转换为IStream*。我甚至在开始的时候

感觉到是不是要自己实现个Stream。后来在google上找到了一个似乎是标准的方法：首先创建个

HGLOBAL对象，然后通过GlobalLock就可以将一个C的const void*直接memcpy到这个HGLOBAL

里，最后，通过CreateStreamOnHGlobal这样的接口就可以得到一个IStream。

恶心的是，基于之前对服务器内存使用的优化，我现在对于内存的使用非常敏感（谁说现在内存

大了就可以任意malloc了？？）。上面那个过程对于资源的管理在MSDN文档中似乎显得有点

模糊。CreateStreamOnHGlobal函数的第二个参数指定当IStream->Release的时候，是否会自动

删除这个HGLOBAL对象。我虽然对COM不懂，但也知道它的对象是基于一种引用计数的管理方式。

逐字看了下文档，发现一个final单词，原来是IStream->Release最后一次释放时，会同时释放掉

这个HGLOBAL对象。更让人发指的是，我猜测Image( IStream * )来创建Image时，Image又

会对这个IStream进行一次AddRef。我发觉MSDN对于Gdiplus::Image::FromStream函数的说明

也有点模糊。我揣摩使用FromStream获得的Image*，是否需要手动去delete？这个地方的内存

资源管理，一定得搞个水落石出。结果是，FromStream的实现就是简单地new了个Image。而

Image内部肯定会对IStream进行AddRef，并且，如果在Image销毁前销毁这个HGLOBAL，这个

Image基本也就废了。

也就是说，Image本身不对HGLOBAL中的图片数据进行复制。囧。别想让我再写个wrap class把

HGLOBAL和Image纠结在一起，简单考虑，将CreateStreamOnHGlobal第二个参数设为TRUE。

要将一个Image保存为一段内存，也比较麻烦。我的方法和google上的相同。当然，微软的库依

然让我在很多细节上栽跟斗（如前所说，可能这是基于多语言支持的考虑）。首先需要创建个空

的IStream，即CreateStreamOnHGlobal第一个参数为NULL。然后将Image Save到这个IStream。

再根据该IStream::Seek获取其大小，自己再分配段内存，最后IStream::Read读取进来。同样，

需要注意相关内存资源的管理。

下午简单把以上两个过程简单封装了下。

    NeoplPack_Bill\0 (16 bytes)
    file_count( 4 bytes)
    item1:offset(4 bytes), size(4 bytes)
    item2:offset(4 bytes), size(4 bytes)
    ...
    itemn:offset(4 bytes), size(4 bytes)
    ...

    文件列表之后，就是具体的每个文件的内容。开始我还在担心npk会为每一个声音文件
加密。或者只保存声音文件的具体数据，而声音文件文件头则只保存一份（因为所有文件的
文件头很有可能全部是一样的）。后来稍微搜索了下WAV的格式，只需要比对下npk中某一个
文件内容的头部是否和WAV格式的头部相同，就可以基本断定其是否加密。
    结果是，npk对包内的每一个WAV文件没做加密。
    然后立即写了个程序，根据文件列表中的偏移值和大小值，将每一个WAV单独取出来，就
OK了。
    完整的格式为：

    NeoplPack_Bill\0 (16 bytes)
    file_count( 4 bytes)
    item1:offset(4 bytes), size(4 bytes)
    item2:offset(4 bytes), size(4 bytes)
    ...
    itemn:offset(4 bytes), size(4 bytes)
    file1
    file2
    ...
    filen

    我想图片资源也应该差不多，不过图片资源肯定要复杂些。下午公司网络好了，网上搜
索了下，发现居然已经有了DNF资源提取工具了，唉。

    提供下源代码和MingW编译好的可执行文件，另声明：本文及相关工具代码只作学习研究
用，任何后果与作者无关。

于是我想，如果每次在我签入代码前，VC或者alienbrain或者其他工具能根据我的设置检查我的代码中是否存在这种不想签入的代码，然后提示我。问了一下向来很熟悉工具的FOX（很抱歉，我甚至不会使用WORD，我真不敢相信我的坦率:D），结果他也不知道。今天闲来无事翻了下alienbrain附带的文档，发现EventsScript。

alienbrain里的EventScript总的来说是一种让用户定制更多功能的机制。它定义诸如签入签出获取版本等动作为event，然后用户可以使用alienbrain支持的VBScript和JavaScript脚本来处理这些事件。例如，当你签出一个文件时，ab(alienbrain)会调用你的脚本，让你来处理这一事件）。当脚本返回时，ab继续处理刚才的操作（如果你实在想中止这一动作也可以）。

这正是我需要的一种机制。迅速地看完了EventScript这一节的文档。再想想我的需求，大体思路就是：给check in挂个脚本，让该脚本调用一个外部程序，处理将要check in的文件，分析这个文件。我可以规定在我的代码中凡是不想签入的代码都可以附加一个tag，例如：#include "vld.h" //DUMMY，分析该代码文件时，发现代码中有//DUMMY字符串，就提示我说该代码文件有不想被签入的代码，位于某某行。

看来我似乎需要一个grep工具，万恶的是windows只有find。不过find基本可以满足我的需求，但是find的输出结果看起来并不是那么友好，并不是可以被另一个程序处理的格式。（linux下通过建立标准的输入输出格式，从而可以轻松地让多个程序协作起来更好地完成很多事）无论如何，我需要使用ab提供给我的接口来试验下我的想法。

然后噩梦开始了。先是发现NxNLauncher（ab提供的一个接口，大致是这样拼写的，现在机器上没ab）的Exec接口是异步执行进程，从而StdOut属性及ExitCode总是得不到正确的值。后来一不小心在ab的wiki上看到，说Exec有个隐藏参数，用来标识是同步执行进程还是异步执行，显然，这个隐藏参数undocumented。- -!

再然后是每次执行find后，find程序倒是被执行起来了，结果却崩溃了。万恶的是我执行其他程序却很正常。google了一下居然发现没人遇到这个问题。最近我的windows总是崩溃各种程序，visual stdio, word, find。但是，我并不打算自己写个find，即使是简化版的。于是我决定写个findwrapper，让ab来调用我自己写的程序，然后我这个程序调用find。然后为了搞定两个程序的通信，又想起了管道pipe。当然，这里的通信很简单，我只需要让find的输出重定向到我的findwrapper，然后我的findwrapper又会被重定向到ab，然后我的ab脚本就可以捕获这些输出，然后再分析这些输出就可以了。- -！

其实，最简单的解决方法，就是我自己写个撇脚的程序，自己去分析要签入的文件是否含有//DYMMY字符串。但是很显然，我更喜欢证明我最初的想法是否正确。

然后，在我的findwrapper里，再一次让find崩溃。经过几次试验，显然问题出在共享管道上。find和ping的不同在于，find可以从标准输入里获取输入，而ping只需要一个标准输出（也许还有stderr）。在CreateProcess里传入的startup info结构体里，需要提供标准输入、标准输出、及错误输出三个handle。显然，问题出在标准输入上，我提供了错误的值。按照一般的接口设计，我以为我如果不提供输入句柄，find就会忽略。但是find显然没那么聪明，或者说，find更喜欢直接*ptr = 10而不是if( ptr != 0 ) *ptr = 10。无论如何，当我把输入句柄填为输出句柄后，findwrapper可以捕获find的输出了，当然，find也不崩溃了。

我总觉得折腾windows api有点噩梦的感觉。我记得几年前刚学windows编程的时候很多函数总要试验很多次才能得到正确的结果，基本上我要尝试各个参数的诸多组合。这还不包括上下文的影响，你要RegisterClass出了问题，CreateWindow楞是不会给你一点点有意义的error code，OMG。

附上全部源代码（对于代码我还是比较满意的:D），下载

struct MyLess
{
    bool operator() ( long left, long right )
    {
        //...
    }
};

DEBUG模式下编译没问题，RELEASE模式下却出现C3848的错误。这就有点奇怪了，如果确实存在语法错误，
那么DEBUG和RELASE应该一样才对。查了下MSDN，C3848的错误是因为const限定符造成的，如：

const MyLess pr;
pr(); // C3848

于是，在operator()后加上const，就OK了。看了下VC std::map相关代码，以为是DEBUG和RELEASE使用了不
同的代码造成。但是我始终没找到不同点。另一方面，就STL内部的风格来看，应该不会把predicator处理
成const &之类的东西，全部是value形式的。奇怪了。

第二个问题，涉及到静态变量。这个东西给我的印象特别深刻，因为以前去一家外企应聘时被问到，当时
觉得那个LEADER特别厉害。回来后让我反思，是不是过多地关注了C++里的花哨，而漏掉了C里的朴素？导致
我至今对纯C存在偏好。

说正题，我现在有如下的文件关系：

// def.h
struct Obj
{
    Obj()
 {
  ObjMgr::AddObj( id, this );
 }
 int id;
};

struct ObjMgr
{
    static void AddObj( int id, Obj *t )
 {
  ObjTable[id] = t;
 }
 static std::map<int, Obj*> ObjTable;
};

static Obj _t;

// ObjMgr.cpp
#include "def.h"

static std::map<int, Obj*>::ObjMgr ObjTable;

// main.cpp
#include "def.h"

这里举的例子可能有点不恰当，我在一台没有编译器的机器上写的这篇文章。忽略掉这些旁支末节。我的意思，
就是想让Obj自己自动向ObjMgr里添加自己。我们都知道静态变量将在程序启动时被初始化，先于main执行之前。

上面代码有两个问题：

一、
代码没有按照我预期地执行，如果你按照我的意思做个测试，你的程序甚至在进main之前就crash了。我假定你
用的是VC，因为我没在其他编译器上试验过。问题就在于，Obj的构造依赖于ObjTable这个map对象。在调试过程
中我发现，虽然ObjTable拥有了内存空间，其this指针有效，但是，map对象并没有得到构造。我的意思是，Obj
的构造先于ObjTable构造（下几个断点即可轻易发现），那么在执行map::operator[]时，就出错了，因为这个时候
map里相关数据还没准备好。

那是否存在某种机制可以手动静态变量的初始化顺序呢？不知道。我最后怎样解决这个问题的？

二、
在还没有想到解决办法之前（不改变我的设计），我发现了这段代码的另一个问题：我在头文件里定义了静态
变量：static Obj _t; 这有什么问题？想想预编译这个过程即可知道，头文件在预编译阶段被文本展开到CPP
文件里，然后，ObjMgr.cpp和main.cpp文件里都将出现static Obj _t;代码。也就是说，ObjMgr.obj和main.obj
里都有一个文件静态变量_t。

看来，在头文件里放这个静态变量是肯定不对的。于是，我将_t移动到ObjMgr.cpp里：

// ObjMgr.cpp
#include "def.h"

static std::map<int, Obj*>::ObjMgr ObjTable;
static Obj _t;

按照这样的顺序定义后，_t的构造居然晚于ObjTable了。也就是说，放置于前面的变量定义，就意味着它将被
首先构造初始化。这样两个问题都解决了。

但是，谁能保证这一点特性？C标准文档里？还是VC编译器自己？

Preface

    本文可能是<代码自动生成-宏带来的奇技淫巧>的续写。我尽力阐述如何让宏递归（或者说重复）地有规律地产生一
些符号，而让我们少写很多重复代码，也许这些代码只有那么一点点的不同。将这项小技巧用于底层库的编写，会让代码
看起来干净不少，同时文件尺寸也会骤然下降。

Problem

    如果你曾经写过functor，那么你肯定对某些代码进行粘贴复制然后修改。更让人郁闷的是，这些代码基本是一样的。
例如，一个典型的functor可能为：

    template <typename Prototype>
    class functor;
    template <typename R, typename P1>
    class functor<R(P1)>;
    template <typename R, typename P1, typename P2>
    class functor<R(P1,P2)>;

    //好，接下去你可能厌烦了，可能会复制一个带有两个参数的functor，然后修改为处理3个参数的。
    这只是一个很简单的问题。宏不是c++里的东西，本文自然也不是讨论各种花哨的模板技术的。如果我之前那篇关于
宏的文章只是让你去分析问题以及更深层次地认识宏，那么现在我将分享我的这部分思想给你。
    关于上面的问题，我们期待得到这样的解决方案：

    template <typename R, DEF_PARAM( 2 )>
    class functor<R( DEF_ARG( 2 ) )>;

    那么，它将自动生成：

    template <typename R, typename P1, typename P2>
    class functor<R(P1,P2)>; 

    也就是说，DEF_PARAM(n)这个宏将根据n值自动生成一串符号，例如DEF_PARAM(2)就生成typename P1, typename P2。
同样，DEF_ARG(n)也会根据参数生成类似于P1,P2,...,Pn的符号串。

思考

    仔细思考下，我们可以看出DEF_PARAM和DEF_ARG这样的宏具有一种递归的特性（其实说成重复可能更合适）：每次展
开的内容基本一样，不断调用自身直到遇到终止条件。
    那么，我们的目标锁定于，用宏来实现递归。

Pre-Implement

    在开始之前，我需要告诉你一些基本的东西：
    在阅读一个宏时，你最好按照预处理的处理方式去逐个展开。当我说到展开时，我的意思是把宏替换为宏体。预处理器
展开宏的过程大致为：如果宏参数也是个宏，那么先将宏参数全部展开，再展开该宏；这个时候会扫描展开后的宏，如果
遇到其他宏，则继续展开。例如有一下宏：

#define PI 3.14
#define MUL_PI( n ) n * PI
#define TWO 2

    当我们写下MUL_PI( TWO )时，预处理发现MUL_PI的参数TWO 是个宏，那么先将TWO展开得到2，然后将2放进宏体展开
得到 2 * PI；预处理器对 2 * PI 进行扫描，发现还有宏PI，于是对PI做展开，得到 2 * 3.14。这个过程是递归的。
    但是也有例外，如果MUL_PI对宏参数进行了#或者##，那么该宏参数不会被展开。（参见以前那篇文章吧）
    任何时候，你可以通过以下宏去查看某个宏展开后的样子，可以方便你调试你的宏：

#define TO_STRING( x ) TO_STRING1( x )
#define TO_STRING1( x ) #x 

    （为什么要写个TO_STRING1，因为这是为了让x充分展开，避免上面提到的那个例外）   

    其他规则我会在文中需要的地方提出来。
实现

    就像大部分介绍递归函数时候给的例子，这里我也将阶乘作为例子。考虑如下典型的阶乘函数：

    int fac( int n )
    {
        if( n == 1 ) return 1;
        return n * fac( n - 1 );
    } 

    其核心部分在于 n * fac( n - 1 )，我们假设我们的宏也可以写成这样的的形式：

    #define FAC( n ) n * FAC( n - 1 )

    但是这样的宏是有问题的：
    当宏被展开时，如果遇到了自身，那么将被处理为一般符号，例如展开FAC( 3 )时，会遇到 FAC( 2 )，那么就把FAC
( 2 )中的FAC当成了一搬符号。
    这样的限制注定了我们无法让宏真正地调用自身来实现递归。于是，我们不得不写下以下丑陋的符号，从而去模拟递
归的每一次符号调用：

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##(n-1)( n - 1 )
#define FAC_3( n ) n * FAC_##(n-1)( n - 1 ) 

    这系列宏有点别扭（如果你足够细心），因为我们明显知道FAC_2返回的将是2，而FAC_3返回的当时6。我们这里只是
模拟，同样，这使得我们可以把FAC_1作为递归的终止条件。
    我们的预想是，当调用FAC_3时，它把n-1的值2合并到FAC_中，从而调用FAC_2，以此类推。
    但是这依然有问题，编译器会提示‘找不到符号FAC_’。导致这个问题的原因在于：宏展开只是单纯的字符替换，是我们
想太多了，预处理器并不会去计算( n - 1 )的值是多少，也就是我们无法得到FAC_2这个宏。

    所以，FAC_3( 3 ) 会被初次替换为 3 * FAC_(3-1)( 3 - 1 )。这个时候编译器就把FAC_当成了一个普通符号。我们可以
自己定义个FAC_来证明这一点：

#define FAC_( n ) T 

    那么，FAC_3( 3 )就被替换为 3 * T(3-1)( 3 - 1 )。

    解决这个问题的办法关键在于，让预处理器自动计算出( n - 1 )。记住，我们解决问题的唯一办法是：字符替换。
所以，我们可以写下如下代码：

#define DEC_1 0
#define DEC_2 1
#define DEC_3 2 

#define DEC( n ) DEC_##n 

    通过，DEC( n )这个宏，我们可以获取到一个( n -1 )的数。例如，DEC( 3 )被替换为 DEC_3，继续替换为 2。

    于是，我们新的FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * FAC_##DEC( n )( n - 1 )
#define FAC_3( n ) n * FAC_##DEC( n )( n - 1 ) 

    不好意思，这样依然是不正确的！预处理器直接把FAC_和DEC( n )连接成符号了，而不是单个地先处理他们，最后再
合并他们。

    OK，先解决这个问题：先处理FAC_和DEC( n )，再合并他们，而不是先合并他们。要解决这个问题，可以通过第三个宏
来实现：

#define CHR( x, y ) x##y 

    作为连接两个符号为一个符号的宏，这个宏显然是不正确的，因为宏展开还有个规则：如果宏体对宏参数使用了#或##，
那么宏参数不会被展开，也就是说：如果CHR( FAC_, DEC( 3 ) 那么得到的只会是 FAC_DEC( 3 )。通常情况下我们是
再写个宏：

#define CHR( x, y ) CHR1( x, y )
#define CHR1( x, y ) x##y 

    从而可以保证在正式连接x和y前，x和y都被完全展开。

    这个时候，我们的FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( n - 1 )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( n - 1 ) 

    结果呢？结果还是有问题。= =
    我们假设CHR( FAC_, DEC( n ) )已经真的按我们预想展开为 FAC_2了，那么FAC_3( 3 )会被展开为什么呢？
被展开为 3 * FAC_2( 3 - 1 )。这是错误的，传给 FAC_2 的参数是 3 - 1就意味着错误。我们又臆想预处理器会
帮我们计算 3 - 1的结果了。我们必须保证传给 FAC_2的参数是个数字2。解决这个问题的办法就是通过DEC(n)宏。

   于是，FAC系列宏变为：

#define FAC_1( n ) 1
#define FAC_2( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) )
#define FAC_3( n ) n * CHR( FAC_, DEC( n ) )( DEC( n ) ) 

    这个时候，FAC_3( 3 )将会被替换为：3*2*1。这就是我们要的结果。

In practice

    以上只是向你展示一个过程，用宏去计算阶乘，就像用模板去计算阶乘（模板元编程）一样，只是一个用于展示的东西，
没有什么实际价值。接下来我们开始有实际的工作，完成之前的预想：

template <typename R, typename P1, typename P2, typename P3>
class functor<R (P1, P2, P3)> 

    直接:

template <typename R, PARAM( 3 )>
class functor<R (ARG( 3 ))> 

    先考虑PARAM宏，该宏的任务就是生成类似于：typename P1, typename P2, typename P3这样的符号。我们假象它每一次
递归都生成 typename Pn, 的字符串，那么当他递归完时，可能就生成typename P1, typename P2, typename P3, 结果
多了个逗号，也许最后一次结果不该有逗号。

    ARG宏和PARAM宏本质上相同，只是重复的符号不是typename Pn，而是Pn。

    最直接想到的是：

#define PARAM_1( n ) typename P##n
#define PARAM_2( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n
#define PARAM_3( n ) CHR( PARAM_, DEC( n ) )( DEC( n ) )##,typename P##n 

    结果我们得到了个错误的展开结果：
typename PDEC( 2 ),typename PDEC( 3 ),typename P3

    这个问题出在：PARAM_3( 3 )当替换为 PARAM_2( DEC( n ) )时，因为PARAM_2(n)宏对于宏参数n使用了##，也就是那个
typename P##n，所以这里不会把 DEC( n )展开，而是直接接到P后面。所以就成了typename PDEC( 3 )。

    为了消除这个问题，我们改进PARAM为：

#define TYPE( n ) ,typename P##n
#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) ) 

    之所以加入TYPE(n)，是因为 ,typename P##n 这个宏本身存在逗号，将其直接用于宏体会出现问题。

    于是，我们得到了正确的结果。

    其实，PARAM系列宏宏体基本是一样的，除了终止条件那个宏，为什么我们要写这么多呢？理由在于宏体不能自己调用
自己，所以才有了PARAM_3, PARAM_2。

    我们可以将上面的一系列宏抽象化，使其具有可复用性：

#define PARAM( n ) ,typename P##n
#define PARAM_END typename P 

#define ARG( n ) ,P##n
#define ARG_END P 

#define PARAM_1( n ) CHR( typename P, n )
#define PARAM_2( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) )
#define PARAM_3( n ) CHR( CHR( PARAM_, DEC( n ) )( DEC( n ) ), TYPE( n ) ) 

#define REPEAT_1( n, f, e ) CHR( e, n )
#define REPEAT_2( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) )
#define REPEAT_3( n, f, e ) CHR( CHR( REPEAT_, DEC( n ) )( DEC( n ), f, e ), f( n ) ) 

#define DEF_PARAM( n ) REPEAT_##n( n, PARAM, PARAM_END )
#define DEF_ARG( n ) REPEAT_##n( n, ARG, ARG_END ) 

    我们创建了可重用的REPEAT系列宏，用于创建诸如typename P1, typename P2, typename P3或者P1,P2,P3之类的符号，
通过更上层的DEF_PARAM(n)和DEF_ARG(n)，就可以直接创建出我们上面所需要的符号串，例如：

    DEF_PARAM( 3 ) 就得到 typename P1, typename P2, typename P3
    DEF_ARG( 3 ) 就得到 P1, P2, P3

More in practice

    下载中提供了我使用这个宏递归技术写的lua_binder(如果你看过<实现自己的LUA绑定器-一个模板编程挑战 >)，你
可以与上一个版本做一下比较，代码少了很多。
    同样，我希望你也能获取这种宏递归的思想。   

相关下载

   使用宏递归的lua_binder

需求

    受WOW的影响，LUA越来越多地被应用于游戏中。脚本被用于游戏中主要用于策划编写游戏规则相关。实际运用中，
我们会将很多宿主语言函数绑定到LUA脚本中，使脚本可以更多地控制程序运行。例如我们可以绑定NPCDialog之类的函数
到LUA中，然后策划便可以在脚本里控制游戏中弹出的NPC对话框。
    我们现在面临这样的需求：对于宿主程序而言，某些功能是不能阻塞程序逻辑的（对于游戏程序尤其如此），但是为
了方便策划，我们又需要让脚本看起来被阻塞了。用NPCDialog举个例子，在脚本中有如下代码 ：

    ret = NPCDialog( "Hello bitch" )
    if ret == OK then print("OK") end

    对于策划而言，NPCDialog应该是阻塞的，除非玩家操作此对话框，点击OK或者关闭，不然该函数不会返回。而对于
宿主程序C++而言，我们如何实现这个函数呢：

    static int do_npc_dialog( lua_State *L )
    {
        const char *content = lua_tostring( L, -1 );
       
        lua_pushnumber( ret );
        return 1;
    }

    显然，该函数不能阻塞，否则它会阻塞整个游戏线程，这对于服务器而言是不可行的。但是如果该函数立即返回，那
么它并没有收集到玩家对于那个对话框的操作。
    综上，我们要做的是，让脚本感觉某个操作阻塞，但事实上宿主程序并没有阻塞。

事件机制

    一个最简单的实现（对于C程序员而言也许也是优美的），就是使用事件机制。我们将对话框的操作结果作为一个事件。
脚本里事实上没有哪个函数是阻塞的。为了处理一些“阻塞”函数的处理结果，脚本向宿主程序注册事件处理器（同GUI事件
处理其实是一样的），例如脚本可以这样：

    function onEvent( ret )
        if ret == OK then print("OK") end
    end
    -- register event handler
    SetEventHandler( "onEvent" )
    NPCDialog("Hello bitch")

    宿主程序保存事件处理器onEvent函数名，当玩家操作了对话框后，宿主程序回调脚本中的onEvent，完成操作。
    事实上我相信有很多人确实是这么做的。这样做其实就是把一个顺序执行的代码流，分成了很多块。但是对于sleep
这样的脚本调用呢？例如：

    --do job A
    sleep(10)
    --do job B
    sleep(10)
    --do job C
   

    那么采用事件机制将可能会把代码分解为：

    function onJobA
        --do job A
        SetEventHandlerB("onJobB")
        sleep(10)
    end
    function onJobB
        --do job B
        SetEventHandlerC("onJobC")
    end
    function onJobC
        --do job C
    end
    -- script starts here
    SetEventHandlerA( "onJobA" )
    sleep(10)

    代码看起来似乎有点难看了，最重要的是它不易编写，策划估计会抓狂的。我想，对于非专业程序员而言，程序的
顺序执行可能理解起来更为容易。

SOLVE IT

    我们的解决方案，其实只有一句话：当脚本执行到阻塞操作时（如NPCDialog），挂起脚本，当宿主程序某个操作完
成时，让脚本从之前的挂起点继续执行。
    这不是一种假想的功能。我在刚开始实现这个功能之前，以为LUA不支持这个功能。我臆想着如下的操作：
    脚本：
    ret = NPCDialog("Hello bitch")
    if ret == 0 then print("OK") end
    宿主程序：

    static int do_npc_dialog( lua_State *L )
    {
       
        lua_suspend_script( L );
       
    }

    某个地方某个操作完成了：
    lua_resume_script( L );
    当我实现了这个功能后，我猛然发现，实际情况和我这里想的差不多（有点汗颜）。

认识Coroutine

    coroutine是LUA中类似线程的东西，但是它其实和fiber更相似。也就是说，它是一种非抢占式的线程，它的切换取决
于任务本身，也就是取决你，你决定它们什么时候发生切换。建议你阅读lua manual了解更多。
    coroutine支持的典型操作有：lua_yield, lua_resume，也就是我们需要的挂起和继续执行。
    lua_State似乎就是一个coroutine，或者按照LUA文档中的另一种说法，就是一个thread。我这里之所以用’似乎‘是
因为我自己也无法确定，我只能说，lua_State看起来就是一个coroutine。
    LUA提供lua_newthread用于手工创建一个coroutine，然后将新创建的coroutine放置于堆栈顶，如同其他new出来的
对象一样。网上有帖子说lua_newthread创建的东西与脚本里调用coroutine.create创建出来的东西不一样，但是根据我
的观察来看，他们是一样的。lua_newthread返回一个lua_State对象，所以从这里可以看出，“lua_State看起来就是一个
coroutine”。另外，网上也有人说创建新的coroutine代价很大，但是，一个lua_State的代价能有多大？当然，我没做过
测试，不敢多言。
    lua_yield用于挂起一个coroutine，不过该函数只能用于coroutine内部，看看它的参数就知道了。
    lua_resume用于启动一个coroutine，它可以用于coroutine没有运行时启动之，也可以用于coroutine挂起时重新启动
之。lua_resume在两种情况下返回：coroutine挂起或者执行完毕，否则lua_resume不返回。
    lua_yield和lua_resume对应于脚本函数：coroutine.yield和coroutine.resume，建议你写写脚本程序感受下coroutine，
例如：

    function main()
        print("main start")
        coroutine.yield()
        print("main end")
    end
    co=coroutine.create( main );
    coroutine.resume(co)

REALLY SOLVE IT

    你可能会想到，我们为脚本定义一个main，然后在宿主程序里lua_newthread创建一个coroutine，然后将main放进去，
当脚本调用宿主程序的某个’阻塞‘操作时，宿主程序获取到之前创建的coroutine，然后yield之。当操作完成时，再resume
之。
    事实上方法是对的，但是没有必要再创建一个coroutine。如之前所说，一个lua_State看上去就是一个coroutine，
而恰好，我们始终都会有一个lua_State。感觉上，这个lua_State就像是main coroutine。（就像你的主线程）
    思路就是这样，因为具体实现时，还是有些问题，所以我罗列每个步骤的代码。
    初始lua_State时如你平时所做：

    lua_State *L = lua_open();
    luaopen_base( L );

    注册脚本需要的宿主程序函数到L里：

    lua_pushcfunction( L, sleep );
    lua_setglobal( L, "my_sleep" );

    载入脚本文件并执行时稍微有点不同：

    luaL_loadfile( L, "test.lua" );
lua_resume( L, 0 ); /**//* 调用resume */

    在你的’阻塞‘函数里需要挂起coroutine：

    return lua_yield( L, 0 );

    注意，lua_yield函数非常特别，它必须作为return语句被调用，否则会调用失败，具体原因我也不清楚。而在这里，
它作为lua_CFunction的返回值，会不会引发错误？因为lua_CFunction约定返回值为该函数对于脚本而言的返回值个数。
实际情况是，我看到的一些例子里都这样安排lua_yield，所以i do what they do。

    在这个操作完成后（如玩家操作了那个对话框），宿主程序需要唤醒coroutine：

    lua_resume( L, 0 );

    大致步骤就这些。如果你要单独创建新的lua_State，反而会搞得很麻烦，我开始就是那样的做的，总是实现不了自己
预想中的效果。

相关下载：
    例子程序中，我给了一个sleep实现。脚本程序调用sleep时将被挂起，宿主程序不断检查当前时间，当时间到时，resume
挂起的coroutine。下载例子

8.13补充

   可能有时候，我们提供给脚本的函数需要返回一些值给脚本，例如NPCDialog返回操作结果，我们只需要在宿主程序里lua_resume

之前push返回值即可，当然，需要设置lua_resume第二个参数为返回值个数。

2.9.2010
    lua_yield( L, nResults )第二个参数指定返回给lua_resume的值个数。如下：

   lua_pushnumber( L, 3 );
   return lua_yield( L, 1 );
 ..
   int ret = lua_resume( L, 0 );
   if( ret == LUA_YIELD )
   {
         lua_Number r = luaL_checknumber( L, -1 );
   }

什么是min heap ?

    首先看什么是heap，heap是这样一种数据结构：1.它首先是一棵完成二叉树；2.父亲节点始终大于(或其他逻辑关系
)其孩子节点。根据父亲节点与孩子节点的这种逻辑关系，我们将heap分类，如果父亲节点小于孩子节点，那么这个heap
就是min heap。
    就我目前所看到的实现代码来看，heap基本上都是用数组(或者其他的连续存储空间)作为其存储结构的。这可以保证
数组第一个元素就是heap的根节点。这是一个非常重要的特性，它可以保证我们在取heap的最小元素时，其算法复杂度为
O(1)。
    原谅我的教科书式说教，文章后我会提供我所查阅的比较有用的关于heap有用的资料。

What Can It Do?
    libevent中的min_heap其实不算做真正的MIN heap。它的节点值其实是一个时间值。libevent总是保证时间最晚的节
点为根节点。
    libevent用这个数据结构来实现IO事件的超时控制。当某个事件(libevent中的struct event)被添加时(event_add)，
libevent将此事件按照其超时时间(由用户设置)保存在min_heap里。然后libevent会定期地去检查这个min_heap，从而实现
了超时机制。

实现

    min_heap相关源码主要集中在min_heap.h以及超时相关的event.c中。
    首先看下min_heap的结构体定义：

typedef struct min_heap
{
    struct event** p;
    unsigned n, a;
} min_heap_t;

    p指向了一个动态分配的数组(随便你怎么说，反正它是一个由realloc分配的连续内存空间)，数组元素为event*，这也是
heap中的节点类型。这里libevent使用连续空间去保存heap，也就是保存一棵树。因为heap是完成树，所以可以保证其元素在
数组中是连续的。n表示目前保存了多少个元素，a表示p指向的内存的尺寸。
    struct event这个结构体定义了很多东西，但是我们只关注两个成员：min_heap_idx：表示该event保存在min_heap数组中
的索引，初始为-1；ev_timeout：该event的超时时间，将被用于heap操作中的节点值比较。

    接下来看几个与堆操作不大相关的函数：
    min_heap_elem_greater：比较两个event的超时值大小。
    min_heap_size：返回heap元素值数量。
    min_heap_reserve：调整内存空间大小，也就是调整p指向的内存区域大小。凡是涉及到内存大小调整的，都有一个策略问
题，这里采用的是初始大小为8，每次增大空间时以2倍的速度增加。
    看几个核心的：真正涉及到heap数据结构操作的函数：往堆里插入元素、从堆里取出元素：
    相关函数为：min_heap_push、min_heap_pop、min_heap_erase、min_heap_shift_up_、min_heap_shift_down_。

heap的核心操作：

- 往堆里插入元素：
    往堆里插入元素相对而言比较简单，如图所示，每一次插入时都从树的最右最下(也就是叶子节点)开始。然后比较即将插入
的节点值与该节点的父亲节点的值，如果小于父亲节点的话(不用在意这里的比较规则，上下文一致即可)，那么交换两个节点，
将新的父亲节点与其新的父亲节点继续比较。重复这个过程，直到比较到根节点。

 
    libevent实现这个过程的函数主要是min_heap_shift_up_。每一次min_heap_push时，首先检查存储空间是否足够，然后直接
调用min_heap_shift_up_插入。主要代码如下：

void min_heap_shift_up_(min_heap_t* s, unsigned hole_index, struct event* e)
{
    /**//* 获取父节点 */
    unsigned parent = (hole_index - 1) / 2;
    /**//* 只要父节点还大于子节点就循环 */
    while(hole_index && min_heap_elem_greater(s->p[parent], e))
    {
        /**//* 交换位置 */
        (s->p[hole_index] = s->p[parent])->min_heap_idx = hole_index;
        hole_index = parent;
        parent = (hole_index - 1) / 2;
    }
    (s->p[hole_index] = e)->min_heap_idx = hole_index;

- 从堆里取元素：
    大部分时候，从堆里取元素只局限于取根节点，因为这个节点是最有用的。对于数组存储结构而言，数组第一个元素即为根
节点。取完元素后，我们还需要重新调整整棵树以使其依然为一个heap。
    这需要保证两点：1.依然是完成树；2.父亲节点依然小于孩子节点。
    在具体实现heap的取元素操作时，具体到代码层次，方法都是有那么点微小差别的。libvent里的操作过程大致如图所示（实际上libevent中父节点的时间值小于子节点的时间值，时间值的比较通过evutil_timercmp实现）：

    主要过程分为两步：
    1.比较左右孩子节点，选择最大的节点，移到父亲节点上；按照这种方式处理被选择的孩子节点，直到没有孩子节点为止。例如，
    当移除了100这个节点后，我们在100的孩子节点19和36两个节点里选择较大节点，即36，将36放置到100处；然后选择原来的36的
左右孩子25和1，选25放置于原来的36处；
    2.按照以上方式处理后，树会出现一个空缺，例如原先的25节点，因为被移动到原先的36处，25处就空缺了。因此，为了保证完
成性，就将最右最下的叶子节点(也就是连续存储结构中最后一个元素)，例如这里的7，移动到空缺处，然后按照插入元素的方式处理
新插入的节点7。
    完成整个过程。

    libevent完成这个过程的函数主要是min_heap_shift_down_：

/**//* hole_index 为取出的元素的位置，e为最右最下的元素值 */
void min_heap_shift_down_(min_heap_t* s, unsigned hole_index, struct event* e)
{
    /**//* 取得hole_index的右孩子节点索引 */
    unsigned min_child = 2 * (hole_index + 1);
    while(min_child <= s->n)
    {
        /**//* 有点恶心的一个表达式，目的就是取两个孩子节点中较大的那个孩子索引 */
        min_child -= min_child == s->n || min_heap_elem_greater(s->p[min_child], s->p[min_child - 1]);
        /**//* 找到了位置，这里似乎是个优化技巧，不知道具体原理 */
        if(!(min_heap_elem_greater(e, s->p[min_child])))
            break;
        /**//* 换位置 */
        (s->p[hole_index] = s->p[min_child])->min_heap_idx = hole_index;
        /**//* 重复这个过程 */
        hole_index = min_child;
        min_child = 2 * (hole_index + 1);
    }
    /**//* 执行第二步过程，将最右最下的节点插到空缺处 */
    min_heap_shift_up_(s, hole_index,  e);
} 

STL中的heap

值得一提的是，STL中提供了heap的相关操作算法，借助于模板的泛化特性，其适用范围非常广泛。相关函数为：
make_heap, pop_heap, sort_heap, is_heap, sort 。其实现原理同以上算法差不多，相关代码在algorithm里。SGI的
STL在stl_heap.h里。

参考资料：

What is a heap?

Heap_(data_structure)

Heap Remove

前言

    可以说对于任何网络库(模块)而言，一个缓冲模块都是必不可少的。缓冲模块主要用于缓冲从网络接收到的数据，以及
用户提交的数据(用于发送)。很多时候，我们还需要将网络模块层(非TCP层)的这些缓冲数据拷贝到用户层，而这些内存拷贝
都会消耗时间。
    在这里，我简要分析下libevent的相关代码(event.h和buffer.c)。

结构

    关于libevent的缓冲模块，主要就是围绕evbuffer结构体展开。先看下evbuffer的定义：

/**//*event.h*/
struct evbuffer {
    u_char *buffer;
    u_char *orig_buffer; 

    size_t misalign;
    size_t totallen;
    size_t off; 

    void (*cb)(struct evbuffer *, size_t, size_t, void *);
    void *cbarg;
};

    libevent的缓冲是一个连续的内存区域，其处理数据的方式(写数据和读数据)更像一个队列操作方式：从后写入，从前
读出。evbuffer分别设置相关指针(一个指标)用于指示读出位置和写入位置。其大致结构如图：

    orig_buffer指向由realloc分配的连续内存区域，buffer指向有效数据的内存区域，totallen表示orig_buffer指向的内存
区域的大小，misalign表示buffer相对于orig_buffer的偏移，off表示有效数据的长度。

实际运作

    这里我将结合具体的代码分析libevent是如何操作上面那个队列式的evbuffer的，先看一些辅助函数：

evbuffer_drain:
    该函数主要操作一些指标，当每次从evbuffer里读取数据时，libevent便会将buffer指针后移，同时增大misalign，减小off，
而该函数正是做这件事的。说白了，该函数就是用于调整缓冲队列的前向指标。

evbuffer_expand:
    该函数用于扩充evbuffer的容量。每次向evbuffer写数据时，都是将数据写到buffer+off后，buffer到buffer+off之间已被
使用，保存的是有效数据，而orig_buffer和buffer之间则是因为读取数据移动指标而形成的无效区域。
    evbuffer_expand的扩充策略在于，首先判断如果让出orig_buffer和buffer之间的空闲区域是否可以容纳添加的数据，如果
可以，则移动buffer和buffer+off之间的数据到orig_buffer和orig_buffer+off之间(有可能发生内存重叠，所以这里移动调用的
是memmove)，然后把新的数据拷贝到orig_buffer+off之后；如果不可以容纳，那么重新分配更大的空间(realloc)，同样会移动
数据。
    扩充内存的策略为：确保新的内存区域最小尺寸为256，且以乘以2的方式逐步扩大(256、512、1024、...)。

    了解了以上两个函数，看其他函数就比较简单了。可以看看具体的读数据和写数据：

evbuffer_add:
    该函数用于添加一段用户数据到evbuffer中。很简单，就是先判断是否有足够的空闲内存，如果没有则调用evbuffer_expand
扩充之，然后直接memcpy，更新off指标。

evbuffer_remove:
    该函数用于将evbuffer中的数据复制给用户空间(读数据)。简单地将数据memcpy，然后调用evbuffer_drain移动相关指标。

其他

    回过头看看libevent的evbuffer其实是非常简单的(跟我那个kl_net里的buffer一样)，不知道其他人有没有更优的缓冲管理
方案。evbuffer还提供了两个函数：evbuffer_write和evbuffer_read，用于直接在套接字(其他文件描述符)上写/读数据。

    另外，关于libevent，因为官方提供的VC工程文件有问题，很多人在windows下编译不过。金庆曾提供过一种方法。其实主要
就是修改event-config.h文件，修改编译相关配置。这里我也提供一个解决步骤，顺便提供完整包下载：

1. vs2005打开libevent.dsw，转换四个工程(event_test, libevent, signal_test, time_test)
2. 删除libevent项目中所有的文件，重新添加文件，文件列表如下：
   buffer.c
   evbuffer.c
   evdns.c
   evdns.h
   event.c
   event.h
   event_tagging.c
   event-config.h
   event-internal.h
   evhttp.h
   evrpc.h
   evrpc.c
   evrpc-internal.h
   evsignal.h
   evutil.c
   evutil.h
   http.c
   http-internal.h
   log.c
   log.h
   min_heap.h
   strlcpy.c
   strlcpy-internal.h
   tree.h
   win32.c
   config.h
   signal.c
3. 替换event-config.h，使用libevent-iocp中的
4. 项目设置里添加HAVE_CONFIG_H预处理宏
5. 修改win32.c中win32_init函数，加入WSAStartup函数，类似于：
       WSADATA wd;   
        int err;
        struct win32op *winop;
        size_t size;
        if( ( err = WSAStartup( MAKEWORD( 2, 2 ), &wd ) ) != 0 )
            event_err( 1, "winsock startup failed : %d", err );
6. 修改win32.c中win32_dealloc函数，在函数末尾加上WSACleanup的调用：
        WSACleanup();
6. 至此libevent编译成功；
7. 几个例子程序，只需要加入HAVE_CONFIG_H预处理宏，以及连接ws2_32.lib即可；
   (time_test需要修改time-test.c文件，即在包含event.h前包含windows.h)

libevent-1.4.5-stable-vs2005.zip下载

Kevin Lynx

引言

在一个高效的系统中，我们经常会将一些费时的操作转换为异步操作。例如往数据库中写日志。如果数据库
配置在网络上，那么往数据库中插入一些日志信息将非常慢(相对于程序其他部分)。

如何转换为异步？

将类似于以上过程转换为异步操作，一个典型的做法是：建立一个单独的数据库日志线程，一个线程安全的
队列。要写日志时，只需要往队列里放入数据，数据库日志线程则从这个队列里取数据然后完成写操作。

大致的过程类似于：

typedef safe_list<std::string> SafeList;
SafeList gLogList; 

// database thread.read log string.
unsigned int __stdcall DBThread( void *p )
{
    while( true )
    {
        // read gLogList and write log string into the database
    } 

    _endthreadex( 0 );
    return 0;
} 

// other threads. write log string.
void wrtie_log( const std::string &log )
{
    gLogList.push_back( log );
} 

将他们包装起来

我们很有可能会在同一个系统中多次遇到类似需要转换为异步操作的地方，如果每一次都手动去创建一个队列和一
个线程，那将会多么乏味啊！懒惰的程序员喜欢重用各种代码。所以，我自己觉得很有必要将这一切封装起来。我
们只需要封装这个队列和创建线程的繁琐细节，让应用层全部专注于具体的逻辑处理：

template <typename _NodeType>
class async_operator
{
public:
    /**//// the list node type.
    typedef _NodeType node_type;
    /**//// the list.
    typedef multi_list<node_type, Mutex, Semaphore> list_type;
    /**//// operator signature
    typedef functor<void, TYPE_LIST1( list_type& )> operator_type;
    /**//// init function signature, called when the thread starts.
    typedef functor<void> init_type;
    /**//// called before the thread exits.
    typedef functor<void> release_type; 

public:
    /**////
    /// start the thread and execute the operation.
    /// @param op the callback function operate the list node.
    /// 
    void execute( operator_type &op, init_type &init = init_type(), release_type &release = release_type() ); 

    /**////
    /// exit the thread.It will block until the thread exited.
    ///
    void exit(); 

    /**////
    /// get the list so that you can pust list nodes.
    ///
    list_type &list(); 

private:
    list_type _list;
    operator_type _operator;
    init_type _init;
    release_type _release;
    thread _thread;
}; 

我利用了已有的组件：线程安全的容器multi_list、包装任意执行体的functor、线程维护类thread。那么，现在，
应用层只需要定义队列节点类型，写应用相关的回调函数(任意可被functor包装的广义函数)。(见附件例子)

之所以为这个组件加上init和release，是因为有些东西(例如COM)需要在线程启动时初始化，而在线程快结束时释放，例如对于
使用COM的应用来说，就需要在线程初始化时CoInitialize，结束时CoUninitialize。

闲说下其他东西

在本文的附件代码里，你可以获取到functor、thread、multi_list这些东西，所以我有必要提一下。

关于functor，你可以参看<实现functor - 增强型的函数指针>，基本上可以看成增强版的C回调函数；至于multi_list，基本上
是一个container adapter (套用下STL的概念)，使用条件变量参与线程同步，据说效率要比简单的互斥高点；至于thread，我需要
特别说下：

thread最为重要的就是为其附加了一个windows的消息队列(只要调用PeekMessage之类的函数该队列就存在)，本意是可以让其他线
程传送数据到该线程，但是目前只用于线程退出，即其他线程可以在任何时候要求该线程安全地退出(该线程没有阻塞的情况下，
阻塞时获取不到消息)。我不知道这个安全退出策略是否真的有必要存在，但是我讨厌看到各种撇脚的退出方法(例如设置全局标志
变量，增加额外的--没封装前---event对象之类)。

结束

不知道其他人是如何做这种异步转换操作的，在这里我只是起个抛砖引玉的作用，欢迎大家提出意见。

SGI实现的STL里，所有的容器都使用SGI自己定义的allocator。这个allocator实现了一个small object的内存池。
Loki里为了处理小对象的内存分配，也实现了类似的内存管理机制。

该内存池大致上，就是一大块一大块地从系统获取内存，然后将其分成很多小块以链表的形式链接起来。其内部
有很多不同类型的链表，不同的链表维护不同大小的内存块。每一次客户端要求分配内存时，allcator就根据请求
的大小找到相应的链表(最接近的尺寸)，然后从链表里取出内存。当客户端归还内存时，allocator就将这块内存
放回到对应的链表里。

我简单地画了幅图表示整个结构：

allocator内部维护一个链表数组，数组元素全部是链表头指针。链表A每一个节点维护一个8bytes的内存块，链表
B每一个节点维护一个16bytes的内存块。

当客户端请求分配10bytes的内存时，allocator将10调整为最接近的16bytes(只能大于10bytes)，然后发现16bytes
这个链表(链表B)里有可用内存块，于是从B里取出一块内存返回。当客户端归还时，allocator找到对应的链表，将
内存重新放回链表B即可。

大致过程就这么简单，也许有人要说用链表维护一块内存，链表本身就会浪费一些内存(在我很早前接触内存池时，
总会看到类似的论点= =|)，其实通过一些简单的技巧是完全可以避免的。例如，这里allocator维护了很多内存块，
反正这些内存本身就是闲置的，因此我们就可以直接在这些内存里记录链表的信息(下一个元素)。

还是写点代码详细说下这个小技巧：

struct Obj
    {
        Obj *next;
    }; 

    void *mem = malloc( 100 );
    Obj *header = (Obj*) mem;
    Obj *cur_obj = header;
    Obj *next_obj = cur_obj;
    for( int i = 0; ; ++ i )
    {
        cur_obj = next_obj;
        next_obj = (Obj*)((char*)next_obj + 10 );
        if( i == 9 )
        {
            cur_obj->next = 0;
            break;
        }
        else
        {
            cur_obj->next = next_obj;
        }
    }
    free( mem );

这样，通过header指针和next域，就可以逐块(这里是10byts)地访问mem所指向的内存，而这些链表的节点，都
是直接保存在这块内存里的，所以完全没有额外消耗。

我用C模仿着SGI的这个allocator写了个可配置的内存池，在其上按照STL的标准包装了一个allocator，可以直接
用于VC自带的STL里。测试代码稍微测试了下，发现在不同的机器上有明显的差距。

这里所说的VC下的错误对话框时指在VC中开调试器运行程序时，IDE弹出的对话框。

1.不是错误的错误：断言 .

将断言视为错误其实有点可笑，但是因为有些同学甚至不知道这个，所以我稍微提一下。断言对话框大致上类似于：

断言对话框是由assert引起的，在对话框上通常会给出表达式，例如assert( 0 ); 弹出对话框时就会将0这个表达式显示出来（Expression:0)。关于assert的具体信息建议自己google。这里稍微提一下一个技巧：有时候为了让assert提供更多的信息，我们可以这样写一个assert:

assert( expression && "Function : invalid argument!" );

因为字符串被用在布尔表达式中时，始终为true，不会妨碍对expression的判断，当断言发生时(expression为false) 时，断言对话框上就会显示这个字符串，从而方便我们调试。

要解决这个问题，首先要确定断言发生的位置，如果是你自己设置的断言被引发，就很好解决，如果是系统内部的函数产生的，那么一般是因为你传入的函数参数无效引起。

2.内存相关：最简单的非法访问：

C、C++程序中经常误用无效的指针，从而大致各种各样的非法内存访问（写/读）。最简单的情况类似于：

这样的情况由类似以下代码引起：

char *p = 0;

*p = 'a';

当你看到类似于“写入位置XXXX时发生访问冲突“时，那么你大致可以断定，你的程序在某个地方访问到非法内存。开调试器对调用堆栈进行跟踪即可找出错误。

3.内存相关：不小心的栈上数组越界：

当你写下类似以下的代码时：

char str[3];

strcpy( str, "abc" );

就将看到如下的对话框：

对话框大致的意思就是说str周围的栈被破坏了，因为str本身就被放在栈上，所以strcpy(str,"abc")多写入的'\0'就写到非法的栈区域。看到这样的对话框可以根据调用堆栈定位到错误发生的函数，然后检查此函数内部定义的数组访问，即可解决问题。

4.内存相关：不小心的堆上数组越界：
并不是每次数组越界都会得到上面所描述的错误，当数组是在堆上分配时，情况就变得隐秘得多：

char *str = new char [2];

strcpy( str, "ab" ); //执行到这里时并不见得会崩溃

delete [] str;//但是到这里时就肯定会崩溃

以上代码导致的错误对话框还要诡异些：

似乎不同的DAMAGE对应的错误号（这里是47）都不一样，因为这里的错误发生在delete，而delete跟new很可能在不同的地方，所以这个错误调试起来不是那么容易，很多时候只能靠经验。

当看到类似的对话框时，根据调用堆栈跟到delete时，你就可以大致怀疑堆上数组越界。

5.调用相关：函数调用约定带来的错误：

这是所有我这里描述的错误中最诡异的一种，先看下对话框大致的样子：

对话框大致的意思就是说（没开调试器时对话框样式可能不一样），通过函数指针调用某个函数时，函数指针的类型（函数原型）可能与函数指针指向的函数的类型不一样。这里的类型不一致主要是调用约定(call conversation）不一样。如果函数类型（参数个数，返回值）不一样，一般不会出错。

调用约定是指调用一个函数时，函数参数的压入顺序、谁来清理栈的内容等。例如默认的C、C++调用约定__cdecl，对于函数的参数是从右往左压入。而__stdcall（WIN API的调用约定）则是从左向右压。我这里所说的函数类型不一样，就是指一个函数是使用__cdecl，还是__stdcall。例如以下代码：

#include <iostream> 

void __stdcall show( const char *str )

{

} 

void __stdcall show2()

{

} 

int main()

{

typedef void (*Func)( const char *);

void *p = show;

Func my_func = (Func) p;

my_func( "kevin" );

return 0;

} 

因为Func默认地被处理为__cdecl，而show是__stdcall的，所以当通过函数指针my_func时，就导致了以上对话框的出现。但是当p指向show2时，又不会出错，这是因为show2没有参数，不同的调用约定不影响这个规则。

6.异常相关：默认终止程序

当我们使用C++库时，因为库本身可能会抛出C++异常，如果你不捕获这个异常，那么C++默认就会调用abort（或者exit）函数终止程序。例如：

void test()
{
    throw std::exception( "some exceptions" );
}

当你调用test函数时，如果不catch这个异常，开调试器就会得到类似的错误对话框：

而如果不开调试器，则会得到：

当你看到类似于“This application has requested the Runtime to terminate it…”之类的字眼时，那就表明程序调用了abort（或exit）函数，导致程序异常终止。其实这个错误只要开调试器，一般可以准确定位错误的发生点。

7.VC运行时检查-未初始化变量

VC的调试器会对代码进行运行时检查，这可能会导致VC弹出对你看上去正确的代码。这也许不是一个错误。例如：

int test_var;

if( test_var == -1 )
{
    test_var = 0;
}

test_var没有初始化就进行if判断，当运行以上代码开调试器时，就会得到如下对话框：

8.破坏的堆

VC对于在堆上分配的内存都做了记录，我想这主要用于free释放内存时做归还处理。

char *p = (char*) malloc( 100 );
p += 10;
free( p );

当执行以上代码时，因为p的值已经改变，提交到free的指针值变化，VC就会给出以下错误提示：

On regular intervals, it forms segments to be transmitted using IP. The size of the segment is
controlled by two primary factors. The first issue is that there is an overall limit to the size
of a segment, chosen to prevent unnecessary fragmentation at the IP layer. This is governed by a
parameter called the maximum segment size (MSS), which is determined during connection establishment.
The second is that TCP is designed so that once a connection is set up, each of the devices tells the
other how much data it is ready to accept at any given time. If this is lower than the MSS value, a
smaller segment must be sent. This is part of the sliding window system described in the next topic.

Since TCP works with individual bytes of data rather than discrete messages, it must use an
identification scheme that works at the byte level to implement its data transmission and tracking
system. This is accomplished by assigning each byte TCP processes a sequence number.

Since applications send data to TCP as a stream of bytes and not prepackaged messages, each
application must use its own scheme to determine where one application data element ends and the
next begins.

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

当软件作为release模式被发布给用户时，当程序崩溃时我们很难去查找原因。常见的手法是输出LOG文件，根据LOG文件分析
程序崩溃时的运行情况。我们可以通过SEH来捕获程序错误，然后输出一些有用的信息作为我们分析错误的资料。一般我们需要
输出的信息包括：系统信息、CPU寄存器信息、堆栈信息、调用堆栈等。而调用堆栈则是最有用的部分，它可以直接帮我们定位
到程序崩溃时所处的位置(在何处崩溃)。(codeproject上关于这个专题的常见开场白 = =#)

要获取call stack(所谓的调用堆栈)，就需要查看(unwind)stack的内容。We could conceivably attempt to unwind the
stack ourselves using inline assembly. But stack frames can be organized in different ways, depending on compiler
optimizations and calling conventions, so it could become complicated to do it that way.(摘自vld文档)要获取栈的
内容，我们可以自己使用内联汇编获取，但是考虑到兼容性，内联汇编并不是一个好的解决方案。我们可以使用微软的dbghelp
中的StackWalk64来获取栈的内容。

StackWalk64声明如下：
BOOL StackWalk64(
  DWORD MachineType,
  HANDLE hProcess,
  HANDLE hThread,
  LPSTACKFRAME64 StackFrame,
  PVOID ContextRecord,
  PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,
  PFUNCTION_TABLE_ACCESS_ROUTINE64 FunctionTableAccessRoutine,
  PGET_MODULE_BASE_ROUTINE64 GetModuleBaseRoutine,
  PTRANSLATE_ADDRESS_ROUTINE64 TranslateAddress
);

具体每个参数的含义可以参见MSDN。这里说下ContextRecord参数，该参数指定了CPU各个寄存器的内容。StackFrame指定了stack
frame的内容。stack frame是什么，我也不知道。(= =) StackWalk64函数需要用户指定当前frame的地址，以及当前程序的指令
地址。这两个信息都被填充进ContextRecord，然后传进StackWalk64函数。

那么如何获取当前的stack frame地址和当前程序指令地址呢？如前所说，你可以使用内联汇编。(对于程序指令地址，因为要获取
EIP寄存器的内容，而该寄存器不能被软件访问)也可以使用GetThreadContext一次性获取当前线程当前运行情况下的CPU各个寄存器
内容。补充下，当前frame地址被放在EBP寄存器里，当前程序指令地址放在EIP寄存器里。但是，如同MSDN对GetThreadContext函数
的说明一样，该函数可能获取到错误的寄存器内容(You cannot get a valid context for a running thread)。

另一种获取Context(包含EBP and EIP)的方法就是使用SEH(结构化异常处理)，在__except中使用GetExceptionInformation获取。

GetExceptionInformation 传回一个LPEXCEPTION_POINTERS指针，该指针指向一个EXCEPTION_POINTERS结构，该结构里包含一个
Context的指针，即达到目标，可以使用StackWalk函数。

补充一下，你可以直接使用StackWalk函数，StackWalk被define为StackWalk64(windows平台相关)。

unwind栈后，可以进一步获取一个stack frame的内容，例如函数名。这里涉及到SymFromAddr函数，该函数可以根据一个地址返回
符号名(函数名)。还有一个有意思的函数：SymGetLineFromAddr，可以获取函数对应的源代码的文件名和行号。

当然，这一切都依赖于VC产生的程序数据库文件(pdb)，以及提供以上API函数的dbghelp.dll。

参考一段简单的代码：

/**////
///
///
#include <windows.h>
#include <stdio.h>
#include <dbghelp.h>

#pragma comment( lib, "dbghelp.lib" )

void dump_callstack( CONTEXT *context )
{
 STACKFRAME sf;
 memset( &sf, 0, sizeof( STACKFRAME ) );

 sf.AddrPC.Offset = context->Eip;
 sf.AddrPC.Mode = AddrModeFlat;
 sf.AddrStack.Offset = context->Esp;
 sf.AddrStack.Mode = AddrModeFlat;
 sf.AddrFrame.Offset = context->Ebp;
 sf.AddrFrame.Mode = AddrModeFlat;

 DWORD machineType = IMAGE_FILE_MACHINE_I386;

 HANDLE hProcess = GetCurrentProcess();
 HANDLE hThread = GetCurrentThread();

 for( ; ; )
 {
  if( !StackWalk(machineType, hProcess, hThread, &sf, context, 0, SymFunctionTableAccess, SymGetModuleBase, 0 ) )
  {
   break;
  }

  if( sf.AddrFrame.Offset == 0 )
  {
   break;
  }
  BYTE symbolBuffer[ sizeof( SYMBOL_INFO ) + 1024 ];
  PSYMBOL_INFO pSymbol = ( PSYMBOL_INFO ) symbolBuffer;
 
  pSymbol->SizeOfStruct = sizeof( symbolBuffer );
  pSymbol->MaxNameLen = 1024;

  DWORD64 symDisplacement = 0;
  if( SymFromAddr( hProcess, sf.AddrPC.Offset, 0, pSymbol ) )
  {
   printf( "Function : %s\n", pSymbol->Name );
  }
  else
  {
   printf( "SymFromAdd failed!\n" );
  }

  IMAGEHLP_LINE lineInfo = { sizeof(IMAGEHLP_LINE) };
  DWORD dwLineDisplacement;

  if( SymGetLineFromAddr( hProcess, sf.AddrPC.Offset, &dwLineDisplacement, &lineInfo ) )
  {
   printf( "[Source File : %s]\n", lineInfo.FileName ); 
   printf( "[Source Line : %u]\n", lineInfo.LineNumber ); 
  }
  else
  {
   printf( "SymGetLineFromAddr failed!\n" );
  }
 }
}

DWORD excep_filter( LPEXCEPTION_POINTERS lpEP )
{
 /**//// init dbghelp.dll
 if( SymInitialize( GetCurrentProcess(), NULL, TRUE ) )
 {
  printf( "Init dbghelp ok.\n" );
 }

 dump_callstack( lpEP->ContextRecord );

 if( SymCleanup( GetCurrentProcess() ) )
 {
  printf( "Cleanup dbghelp ok.\n" );
 }

 return EXCEPTION_EXECUTE_HANDLER;
}

void func1( int i )
{
 int *p = 0;
 *p = i;
}

void func2( int i )
{
 func1( i - 1 );
}

void func3( int i )
{
 func2( i - 1 );
}

void test( int i )
{
 func3( i - 1 );
}

int main()
{
 __try
 {
  test( 10 );
 }
 __except( excep_filter( GetExceptionInformation() ) )
 {
  printf( "Some exception occures.\n" );
 }

 return 0;
}

以上代码在release模式下需要关掉优化，否则调用堆栈显示不正确(某些函数被去掉了?)，同时需要pdb文件。