VB/VBA的虚拟机（二）

前言

在《VB/VBA的虚拟机（一） 》中，已讲到VB6.EXE进程所加载使用的支持库，为了将VB/VBA的虚拟机给大家伙讲到更清楚，以支持库名为小节点进行组织。那么(一)中的VB6IDE.DLL部分，列为『(1)VB6IDE.DLL』，后续的VBA6.DLL部分列为『（2）VBA6.DLL』，其他以此类推。

诚如已讲，VB6IDE.DLL为VBIDE的资源库，几乎是个纯资源库，不支持自动化COM接口。这进一步证明，该库不是咱们要分析的主角儿，因为VB/VBA的IDE本身就是依赖COM接口的。

好了，接着继续。

三、VB/VBA的虚拟机

（一）VB的虚拟机

2、VB6.EXE用到的库

（2）VBA6.DLL

既然VB6IDE.DLL已被排除，那再来看看VBA6.DLL吧。毕竟对很多人来说，VB与VBA之间总有那么点隔阂，本文也正是要将二者的区别和联系说清楚滴。用PEView打开VBA6.DLL：

咋一看，就知道有事情要发生

看到Engine那样的名称，再看几十K的尺寸(历史上BASIC的虚拟机就几十K)，应该是虚拟机无疑了。再看看导出函数：

是函数好用，还是COM接口好用?

Eb和Tip系列，根据名称可以判断是跟IDE有关的函数。剩下的主要是rtc系列了。再看其导入DLL，包括ole32,oleAuto32,Gdi32,User32,Kernel32和AdvApi32，都是些系统DLL，这说明VBA.DLL对非系统资源没有依赖，是很独立的。也就是说上面的导出函数都在VBA6.DLL中实现。

上述导出函数，是不是没用过，感到很陌生？那我们再来看看其COM接口的情况：

熟悉的配方，熟悉的味道

有没有感觉眼前一亮？这不正是VB语句的原材料么？我特地确认过，每个接口都是在VBA6.DLL中实现的。值得一提的是，前段时间有网友批评VB没有文件系统支持，这下可以实锤了吧！

前面给大家分享的《VB/VBA中的函数，用了那么久，其实是这样的 》里，初步交代了函数在编码中的作用，也初步点出了标准函数与COM接口函数之间的微妙关系。那借着这儿的对比，继续讲讲函数那些事儿。

为什么VB不使用导出函数，而是使用COM接口函数？

要知道使用导出函数几乎是C的标准做法，不兜圈子，不仅高效，也更容易让开发者明白。但是，这就不得不动用函数指针的概念。有了指针，这个门槛就高了N个高度。这就牵扯到了计算机设计中的一个悖论：人容易的，永远没有人不容易的高效。也就是说，离硬件越近，离人就越远，效率越高。反之，离硬件越远，离人越近，效率相对就越低。

其实造成这一悖论的，是计算机硬件发展的技术路线问题。现有的通用计算机，有个通识，那就是冯诺依曼架构，确切地说都是冯诺依曼和哈弗架构的融合体。但，这是针对工业生产而言的，如果从更抽象的角度来理解计算机，从最原始的算盘，机械、机电结构，到现在的超大规模集成电路，其实本质上一直未发生过变化。也就是说，计算机的发展，其实是线性堆垒的。后来者，无论有多么光亮，它都是站在前者的技术上的。

这就是为什么C最后成了各种开发语言的基座。作者，早前讨论了C的精髓是什么的问题，很多人将指针视若圣经，这在战术层面，的确如此。但在战略层面，C的精髓，在于它随时能游走穿插在计算机发展的账本中，找到适合的支撑点。这是更上层封装语言，很难办到的。

扯远了，使用COM接口函数，其实就是为了降低使用门槛。大家觉得VS好用，其实跟VB/VBA的IDE是一个道理，那就是基于COM。COM的特点是，制造它很麻烦，但是使用它却很适合人类。对于VB/VBA的定位，非COM莫属。

前面分享的文章《VB的任性，从Variant开始 》，其实Variant的核心就是COM。VB/VBA能够让各路IT盲，也能玩一手代码，COM在背后功不可没。COM是构造更符合大部分人的人机交互的利器，是机器走向大众的有效技术路线。这就是为什么，COM会始终是Windows的基石。

对于人机交互，业界其实阵营很分明。以Linux的CUI是一派，以Windows的GUI则是另一派。其实，没有必要争论那个好，那个不好！因为这是计算机硬件发展本身带来的。Linux天生就只适合专业技术人员，你的内核架构，就决定了很难做出Windows那样低门槛的技术产品。Windows的内核架构，在纯性能层面，也很难超越Linux。但是，硬件升级带来的巨大性能缓冲，足以让Windows胜任人事儿的方方面面！

<未完待续，请关注本号(BtOfficer多平台同名)，更多VB/VBA虚拟机内容持续更新中。欢迎大家留言讨论。>