我用W32Dasm(Ver 8.93)解开一个比较复杂的VB程序，其中用到了许多API 函数比如GetPrivateProfileString、OSfCreateShellLink、SHBrowseForFolder 等来自很多DLL的API。解开以后却发现程序只用到了一个DLL:msvbvm50.dll(我用的还是VB5)！VC、Delphi等程序语言编译出的程序可是直接引用DLL的。经过研究发现程序使用了如下几个主要的来自MSVBVM50.dll的API：
rtcRandomize ：Randomize 函数的对应API；
rtcMidCharVar ：Mid 函数的对应API；
rtcLeftCharVar、rtcRightCharVar ：看出来了吧，这些是Left、Right函数的对应API；
rtcUpperCaseVar ：UCase 函数的对应API；
rtcKillFiles ：Kill 语句的对应API；
rtcFileCopy ：FileCopy 语句的对应API；
rtcFileLength ：EOF、FileLen函数的对应API；
rtcGetTimer ：Randomize Timer中获取Timer的对应API；
rtcShell ：Shell函数的的对应API；
rtcMakeDir ：MkDir 语句的对应API；
rtcRemoveDir ：RmDir 语句的对应API；
rtcDir ：Dir 函数的对应API；
rtcSpaceVar ：Space 函数的对应API；
没问题的人应该看出来了：VB的所有函数、语句、方法都是由调用MSVBVM50.dll 中的API实现的，一般是由“rtc”接上函数或语句的全名，涉及字符串的API一般还得在最后加上“Var”。另外还有一些函数是这样写的：
__vbaUbound ： UBound 的对应API；
__vbaFileOpen ：Open 语句的对应API；
__vbaStrCmp ：比较两个字符串：If String1 = String2 Then ......
__vbaVarOr ：Or 运算符的对应API；
__vbaRedim ：Redim 语句的对应API；
__vbaRedimPreserve ：Redim 语句加上 Preserve 参数的对应API；
__vbaGet、vbaPut ：Get、Put语句的对应API……
在运行时，VB程序就调用它们完成工作。
2.其它DLL的调用
第一部分解决了。我们知道了VB程序实际上不是一个真正的可执行文件，它只是机械性地调用MSVBVM50.dll中的API执行程序。那么VB程序既然只调用了MSVBVM50.dll，它又是怎样调用其他DLL中的API呢？
注意这个API。它能引起我们的注意：
DllFunctionCall：看到了吗？它就是我们的主角。
从字面上看就能看懂了：它用来调用其它DLL。这样可以使程序使用的函数集中在MSVBVM50.dll里(怎么有点像封建制度，中央集权……)。
3.重中之重：VB程序的启动
我们已经知道了VB程序的运行方法。那么它是怎样启动的呢？
再看看程序调用的API。其中有一个API雷打不动，每个VB程序都有：
ThunRTMain
首先，VB程序调用ThunRTMain。ThunRTMain为程序初始化进程，并获取进程ID。
随后它加载vb5chs.dll，为打开新窗口准备。然后它开始用LoadString等API 获取窗口属性，比如字体、标题、颜色等。再调用IMM32.dll，开始利用它打开新窗口。然后使用GetModuleFileName获得VB程序名，随后用CreateSemaphore增加信号机。信号机的作用是：当监控值大于0时，信号机工作。再调用OLE32.dll，使用CreateWindowEx打开一个叫做“DDE Server”的隐藏窗口，让它从中作梗。退出OLE32.DLL，MSVBVM50又开始调用程序管理器。
前面的工作为我们的VB程序注册了一个类名：VBFocusRT5，下面就可以使用这个类名创建VB窗体。首先使用大量循环读取半角/全角字符，然后读取各个控件的属性，再使用Local_Function把这些属性、方法、事件等“拼”成一个完整的控件，最后把上面做的所有工作综合起来，开始VB程序。
从过程来看，使用时间最多的自然是加载控件了，其次是加载字符集。VB程序速度慢主要是指启动速度慢。这是难以避免的，希望VB7推出时能改进这一点。
不知大家看没看出来，编译后的VB程序只是源程序的翻版，连控件属性、方法和事件名都一模一样。VB程序的慢就是来自这里，它们只是机械地、无休止地调用MSVBVM50.dll里的API来运行程序。要想彻底摆脱这一点，只能改革VB程序编译时的方法，使其成为一个标准的资源性Win32程序。
附：VB程序与VC++程序启动速度大火拼
注意：这里提到的只是“启动”速度。实际上，VB程序启动后的运行速度与其它程序语言编译出来的EXE速度差不多(甚至更快)，只不过是启动速度太慢而已。
我们知道，Windows附带的计算器是用VC++编制的。我编了一个示例计算器程序，流程很简单，单击Command1时把Text1与Text2相加，再赋值到Text3。
代码只有一行：
Private Sub Command1_Click()
Text3 = CStr(Val(Text1) + Val(Text2))
End Sub
把它编译为EXE。为了表现出速度差异，我选择了一台比较慢的电脑：
Pentium 166 MMX + 80M EDO + 3.2G硬盘。
启动速度对比：为了结果公平，共测试五次，取平均值。
单位：秒
运行次数 VB计算器 VC++计算器
1 2.43 0.87
2 0.85 0.74
3 0.92 0.92
4 1.02 0.78
5 0.87 0.84
平均速度 1.22 0.83
你会发现，VB计算器第一次比较慢，剩下几次就快了。这是因为ThunRTMain 把所有控件信息写入内存，每次打开程序时检测是否有可用控件信息而且符合本程序(大概比尔也知道VB慢吧)。另外，我们只能算加法的计算器启动速度就和功能众多的Windows计算器差不多，更可以知道我们如果用VB编出一个和Windows计算器功能相同的计算器的启动速度了。:( VB也不全是缺点，至少它的程序设计环境是其它程序语言所不具备或不擅长的。
像VB这样简单易学，可以像画图一样构造程序界面的程序语言可以说只有VB 一个，它为编程初学者指明了方向。VB是有它存在的理由的，至少，我SuperAPI还在用它。:)
后记：
写这篇文章的灵感来自于两天前VB论坛里cy72提出的问题。昨天半夜没上网，集中精力调试一个VB程序，终于找出了答案。在DLL里转来转去的感觉真的很难受，加之我对汇编还不太懂。以每秒3条语句的速度进行，调试了49218 步，共用了4个半小时。我自从接触VB以来从没感觉过VB程序是这样复杂。
尤其值得一提的是，4个半小时中4个小时是泡在近似无限的循环中，这种长时间重复一件枯燥而乏味的事情我可总算是见识到了，各位调试VB程序时大可不必心烦意乱，你只要想想长时间按着F7、F5键，在迎面扑来的一堆堆成山的天书般的汇编语言中寻找有用东西的滋味你就知道调试VB程序是最简单的了。:)
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
