我们再用DEPEND来观察一下VB6.EXE, 我们可以发现VB6.EXE引入了VBA6.DLL中一些它特有的以Eb和Tip开头的函数，从这些函数的名称上可以发现它们的功能都是IDE相关的，比如79的EbShowCode和82的TipDeleteModule。VB6.EXE恰恰没有引入任何rtc开头的函数（注意一）。我们再来看看MSVBVM60.DLL，随便找一个用了MsgBox函数的编译后的文件，用DEPEND来观察它，就会发现它引入MSVBVM60.DLL输出的595号rtcMsgBox函数（注意二）。并且引入MSVBVM60.DLL中很多以下划线开头的函数，比如__vbaVarAbs（注意三）。其实从这个三个"注意"中我们已经可以进行一些猜想，无论对错，你可以先想想。
如果你没有跟着我做实验，而仅仅是看这篇文章的话，我猜想你应该有点昏了。如果你自己动手做了这些实验，现在你应该充满了疑问而急侍看到结论。所以请一定要亲手试一试，学习研究问题的方法比看结论更重要。
到这里至少我们可以得出结论：VB和VBA本就是同宗的姐妹，只不过姐姐VB的功夫要比妹妹VBA历害些。不过姐姐只会单打独斗是女强人；妹妹却只会傍大款。姐姐有生育能力，是真正的女人；妹妹却不会生崽，但深谱相夫之道，一番教导指挥之下可使她老公增色不少，而VBS呢，也是大户人家的女儿，不过没有VB和VBA姐妹优秀的血统，娇小玲珑干不得粗活只能指挥些自动听话的对象来干活，她乐于助人品德好不象VBA那样只认大款，VB、VBA、vbs三个女人我都喜欢。
2)Native Code(本地代码)到底做了什么？
打起精神，我们再深入一步。用OLEVIEW得到的类型库还不能正确的反映各对象方法对应的DLL中的函数入口，你应该已经发现用OLEVIEW得到的IDL文件中各个方法的entry属性值都是0x600000XX这样的假东西。要得到类型库中各方法在DLL中的真正入口，我们需要自己来写段程序。
即使在VB中我们也可以非常容易地获取类型库信息，再加上点COM初始化和调用代码，我们就能用自己的代码实现VB6才引入的CallByName函数（在本系列后面的《Hack COM》中我会更深入谈谈COM，作为一名VB程序员对COM的理解非常重要）。由于本文的关键不是指导如何在VB里使用类型库，所以下面提供的方法尽量从简。
新建一个标准EXE工程，添加对TypeLib Infomation的引用，在Form中放一个名为lblInfo的标签，然后添加如下代码:
'程序1
Private Sub Form_Load()
Dim oTLInfo As TypeLibInfo
Dim oMemInfo As MemberInfo
Dim sDllName As String
Dim sOrdinal As Integer
Set oTLInfo = TLI.TypeLibInfoFromFile("MSVBVM60.DLL")
lblInfo = "MATH模块包含以下方法：" & vbCrLf
For Each oMemInfo In oTLInfo.TypeInfos.NamedItem("Math").Members
With oMemInfo
.GetDllEntry sDllName, vbNullString, sOrdinal
lblInfo = lblInfo & .Name & "定义在" & sDllName & "中，" & "其编号为" & sOrdinal & vbCrLf
End With
Next
End Sub
运行以后我们就可以知道MATH模块中的Abs方法定义在VBA6.DLL中，其编号为656。在DEPEND中查看VBA6.DLL中编号为656的函数，果然就是rtcAbsVar，用VBE6.DLL试试结果相同。
还记得前面的注意一吧，VB6.EXE没有引入rtc开头的函数这说明在IDE环境中执行的VBA方法实际上是通过COM调用VBA对象库中的方法（跟踪p-code是噩梦，所以我无法验证它用的是什么绑定方式）。而注意二中提到的最终可执行程序中引入了rtcMsgBox，如我们所料最终的程序会直接调用它，这要比COM调用快一点，但在跟踪最终程序时，我发现rtcMsgBox内部却是经过了二万五千里长征后才会去调用MessageBoxA这个API，其间有多次对其它对象的COM调用，慢！可能是因为显示的是模态对话框，在多进程多线程环境有很多需要考虑的因素吧，如果你是疯狂在意效率的程序员，你应该试试用API来重写MsgBox，绝对快不少。再来看看注意三，让我们把以下的程序编译成使用本地代码的"程序2.EXE"（为了后面的实验，可以在工程属性的编译选项卡中将它设成"无优化"和"生成符号化调试信息"程序2.EXE""）：
'程序2
Private Declare Sub DebugBreak Lib "kernel32" ()
Private Sub Main()
Dim i As Long, j As Long
Dim k
i = &H1234
DebugBreak
k = 1234
j = Abs(k)
j = Abs(i)
MsgBox "ss"
j = VarPtr(i)
End Sub
用DEPEND观察"程序2.EXE"，我们可以发现"程序2.EXE"并没有如我们预期的一样在引入595的rtcMsgBox的同时引入656的rtcAbsVar，相反它引入了__vbaVarAbs和__vbaI4Abs，看看函数名就知道一个针对的是Variant，一个针对的是long。这说明VB在最终生成的代码中对象Abs这样的可以进一步针对不同类型优化的VBA函数进行了相应的处理，观察一下所有以__vba开头的函数绝大部分都是那些最基本最常用的VBA函数，可以说__vba开头的VBA函数是rtc开头的VBA函数的优化版本，它们基本上是VB开发小组重新写的，绝大多数在函数内部实现自身功能，而rtc开头的函数大多数是调用COM服务对象来完成工作。
从这么多__vba开头的函数上可以看出VB小组在Native Code（本地代码）的优化上下了不少功夫，这决对不是吹牛。它的确高度优化了不少科学计算相关的函数，以ABS为例Native Code要比p-code快4倍以上。但是并不是所有的计算函数都经过了这样的优化，比如Rnd函数，它就没有对应的__vba开头的优化函数，而是直接对应到rtcRandomNext函数上，虽然rtcRandomNext也已经优化过，但内部依然用了COM调用，还是不如自己重写的快，我不明白为什么VB开发小组没有考虑为它写一个对应的__vbaRnd。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
