摘要：
用过虚拟函数的程序员，肯定对switch/case 句型带有一种不想用的心理，因为如果case过多的话，至少会有以下缺点：
1） 代码太长，不适合查看和管理；
2） switch/case不够灵活；
3） 扩充性不够好，比如每增加一个case都要更改代码。
mfc有一个很好的框架，继承自cobject且通过declare_dynamic()和implement_dynamic声明......
摘要：
各位兄弟在看到标题时,可能会火冒三丈,"你这小子,欠揍吗?"在messagebox的最后参数上指定mb_yesno不就行了?众兄弟请息怒,请再看一遍标题,我说的是显示"yes"与"no",不是"是"与"否"
#include <windows.h>
hhook hhook;lresult __stdcall cbthookproc( long ncode,wparam wpara......
翻译Matt Pietrek 的 Under the Hood 专栏文章 The .NET Profiling API and the DNProfiler Tool
http://msdn.microsoft.com/msdnmag/issues/01/12/hood/default.aspx 【程序编程相关:
一些容易遗忘的小技巧】
the .net profiling api and the dnprofiler tool 【推荐阅读:
CDC使用技巧之最快最方便的实现放大缩小】
随着系统的发展变得越来越复杂,能够理解系统的内部工作机制变得越来越有价值.在windows®,调查可执行程序装载器.内存管理器的操作机制将展示很多不同的技巧.另外,有些技巧在window 9x 平台下能够正常工作,但是在windows nt® 与windows 2000不能工作,反之亦然.在win32®下,查看进程的内部操作的最好方式是使用调试api,但是它也只能是包含很少的一部分. 【扩展信息:
ATL Style 模板学习手记】
微软的.net common language runtime(clr)内部提供了很多机制来创建更容易使用.更面向对象的平台.包括垃圾回收.标准的跨语言异常处理.广泛的类库.元数据.与已存native代码的互操作性.远程处理.也包括跨cpu指令格式（中间语言,il）与将il编译成能够在目标cpu上运行的代码的即时编译器.
在.net下就完全不同了.因为clr运行时是任何.net程序的中心,它提供了一个逻辑位置来插入钩子以便观察.net的内部.预计到工具开发者.系统级程序员的需要,microsoft使用.net来提供了一个非常详细的.一致的方式去观察进程的内部操作.本月,我要描述这种机制.并提供一个程序（dnprofile）来记录.net运行时的操作.
the .net profiling api
观察.net运行时动作的一种方式时使用剖析api.剖析api的命名不好,因为它对很多种事情都很有用,而不仅仅是剖析.考虑可以被剖析api观察的.net动作列表,如下:
figure 1 functions of the profiling api
clr startup and shutdown
application domain creation/shutdown
assembly loads/unloads
module loads/unloads
class loads/unloads
com interop vtable creation/destruction
jit-compiles, code pitching, and pre-jited method searches
thread creation/destruction/suspends
remoting activity
exception handling
managed/unmanaged code transitions
garbage collection and managed heap objects
method entry/exit
正如keanu reeves会说whoooa! 相对于经过了多年的艰苦探索找到的如何给windows安装钩子来讲,microsoft使观察clr的行为变得非常容易了.列表中的每一个动作可以看作一个完全不同的callback.理论上讲,仅仅在callback函数中写需要的代码就可以了.
现在,最好的剖析api文档是.net sdk下的profiling.doc,在tool developers guide\docs目录下.对于beta2 来讲,这个文档与实现稍微有些不同步.在本期刊中,我不会广泛的讨论剖析api的每一个方面,而是重点讨论剖析api能做的大的方面.
.net的一个大的卖点是它不再使用com.这不是真的,事实上,剖析api就是基于com的.使用剖析api包括创建一个进程内服务器,它实现了单一的接口.每一个接口方法代表了figure 1中的一个事件.在callback方法内部,代码可以使用另外的com接口（由clr提供）来得到观察事件的信息.
个人来讲,我喜欢更简单的api来对所感兴趣的每一个事件进行注册.将api实现作为一个com对象强迫你写几乎同样的代码以便使用com对象.既然剖析api是基于com的,剖析api的用户很可能使用c++.
尽管使用典型的com而不是使用托管.net代码起初看起来有些奇怪,仔细考虑之后就会明白.如果用托管代码实现接口,它将对监视的所有事件的产生负面影响.例如,如果实现接口的托管代码触发了异常怎么办?在api没有激活的情况下,异常事件也不会发生.
一旦你有一个实现了profiling接口的com服务器,下一步是强迫clr装载com服务器.调用它的方法.技巧是设置环境变量.跟注册表.xml文件比较起来,环境变量是挺古老的.
为什么不用注册表（配置文件）告诉clr应该调用profiling api?我从microsoft开发者那里听说的一个原因是那要求.net程序在启动时检查注册表将会有性能影响.考虑到.net启动时有很多事情要做,这样的原因考虑的也是很慎重的.虽然如此,使用环境变量可以对所有程序起作用（如果在系统环境变量）或单独的进程.在后者情况下,调试器.剖析器等工具可以在启动程序时指定环境变量.稍后我将讨论所需要的环境变量.
the .net profiling api interfaces...
下一页 摘要：
在dialog程序中使用wh_keyboard_ll类型hook的方法:
setwindowshookex(wh_keyboard_ll, (hookproc)lowlevelkeyboardproc, afxgetapp()->m_hinstance, null);
lresult callback lowlevelkeyboardproc (int ncode, wparam wp......
