VB/VBA更注重如何用，作为系统脚本更中！

前言

在《VB/VBA为何不需要所谓的标准DLL？》中给大家伙解释了什么是标准DLL，为何VB/VBA不需要这样的标准DLL。简单总结下，标准DLL就是导出了指定函数的DLL，方便直接通过函数指针的方式进行调用。在VB/VBA中呢，就是可以通过Declare机制进行声明和使用。但VB/VBA通过COM接口，要远比Declare方式高效灵活，所以VB/VBA不需要所谓的标准DLL。

Declare相关讨论可以参考《VB/VBA的Win32API声明中，不得不了解的真相》《来聊聊VB/VBA函数》《VB/VBA中Declare声明API时，这样用效率又会增加一点点哦！》...

但是VB/VBA是COM的语言，编译的DLL天生就是ActiveXDLL，也即是说天然就会有4个标准的COM导出函数，那为何还在强调是否标准与否呢？网友一针见血地说，标准DLL才不是为了让VB/VBA方便Declare呢，想想其他编程语言要怎么调用VB/VBA的DLL？这就是今天要跟大家分享的，『为何VB/VBA不需要标准DLL，其他语言也不需要VB/VBA的标准DLL?』。

一、为何VB/VBA不需要标准DLL？

《VB/VBA为何不需要所谓的标准DLL？》也解释了利用COM接口，在VB/VBA的IDE中，通过对象+『.』，非常便捷，使用上也很高效。从使用Dll函数的角度，无论是Declare还是直接使用函数指针，这都是没法比的。

Declare不仅需要自己写声明，而且会内建一套类导入表的机制。就为了避免用户直接面对函数指针，可谓是绕了一大圈。要在VB/VBA中直接使用函数指针，方便是方便，但得懂如何用才行，不然也不会让Declare处心积虑地隐藏它。

这显然与VB/VBA的定位和用户群，是不符的。但无论怎样，最后大家都是奔向函数指针而去的，因为指令层面就认这个超级GOTO+行号(Call/跳+函数地址)。

前面也说了，ActiveXDLL会导出4个函数，这4个函数就是COM对象使用函数的关键，也同样是奔着函数指针去的。事实上，其他语言使用DLL函数指针是通过导出/导入表，与COM对象使用成员函数的机制是一样的，这便是VTable绑定。这是VB/VBA唯一可以和其他语言平起平坐讲专业性的地方，不过很可惜，VB/VBA还是通过类和对象将其遮盖得严严实实。

需要了解VTable相关知识点的朋友，请继续关注后续文章，VB/VBA的很多高阶用法都离不开这一机制，比如函数指针动态调用，处理C调约（调用C调约API，提供C调约回调函数），IDE和编译均适用的嵌入汇编等。

VB/VBA的COM接口中的VTable绑定机制，不仅兼顾了源码编写上的便捷和高效（对应IDE的智能提示和自动补全），而且也同样兼顾了代码运行的高效率，与其他专业语言不相上下（比如C/C++）。所以，VB/VBA中确实是不需要所谓标准DLL的。

二、为何也不需要VB/VBA的标准DLL？

1、先问VB/VBA的先人BASIC是干什么的？

其实，一开始BASIC，就以教员的方式，盯着如何让文科一类背景的人使用计算机，所以如何操作计算机便是后来VB的核心基因之一。这个使用当然不是专业程序员那般细腻的控制，而是在更粗糙的粒度上的操作体验。早期的BASIC没有现在的鼠标视窗环境，这种使用，大抵跟很多人心中的黑客风，是差不多的吧。

如果调整下字体和背景色，还以为是黑客在搞事！

要拿到现在，是不是会劝退很多人呢？但在那个年代，这已经很亲民了，毕竟学生们不用刻意去负担半导体专业知识也能让机器跑起来。后来，微软加入了鼠标驱动的视窗环境，BASIC再一次脱胎换骨为VB/VBA，以一夫当关万夫莫开的气势，撑起了大家对Windows的好奇，微软自然也赢得了小白们的选票，真正演绎了『得小白者得天下』的真理！

2、再问VB/VBA是什么？

如果说MS-DOS是微软背靠IBM积累家底的量变阶段，那后来的VB/VBA就是微软翅膀硬了，与IBM分道扬镳各奔前程的资本。以现在的计算机环境，是很难理解VB竟然这么牛叉的。相信不少上个世纪80/90年代过来的程序员，是很清楚当时编程的门槛有多高。

专业程序员，都是宝啊，可遇不可求的那种。突然来一个，拖拖拽拽，三五分钟就可以弄个示例软件出来的工具，那必然是爆炸性的。不仅仅因为可以在广袤的普通百姓心里种下编程的种子，为后来的程序员职业的繁荣立下汗马功劳。更因为微软千方百计地通过VB，向广大小白们演示着Windows的优越性。

要演示系统的优越特性，没有方便之门怎么行。直到今天，仍然有不少老程序员认为，微软为VB倾斜了太多的资源。甚至还有极端者认为，比尔-盖茨只懂BASIC，而不惜改造C/C++规范，就只为VB能用上C/C++库资源。虽然有点夸张，但对于VB/VBA而言，的确将系统的某些特性运用的炉火纯青，这就是VB/VBA在Windows中扎根太深，而难以跨平台的根本原因，同时也是Linux平台上类BASIC语言难以超越VB/VBA，有其形而无其魂的原因所在。

后续会不断分享VB/VBA是如何利用系统特性的，VB/VBA用户又该如何使用这些特性来提升代码的性能和编写效率，欢迎关注哦！

VB/VBA一度是Windows功能的Demo工具，不仅有历史的原因，更有历史的机遇。一方面，当年BASIC的教学设计，就重在普适的人机交互，以BASIC起家的微软，自然门儿清。因为说到底，再牛逼的技术和机器，也是要给人服务的。另一方面，背靠IBM的十余年间，BASIC不仅替微软摸排了市场的真实需求（痛点），更为微软培养了无数BASCI粉。所以，当微软与将IBM分道扬镳时，具有普适性（视窗+鼠标）的VB自然当仁不让地挑起了大梁，并伴随着Windows的不断完善而得到改进。

其实，这是一个相互成就的过程，并非微软一心偏袒VB。虽然，今天的VB/VBA确显老旧，但不可否认VB/VBA一身武艺，都是实实在在的精华。这是不深入Windows和VB，就了解不到的真相。

《什么是脚本语言？为何VBA不算脚本语言？》便是VB的冰山一角，更多背景可阅读《以史为鉴，编程语言，启示录之系统觉醒》《VB前传，从教学到游戏，再到系统，似乎每步都是精心设计》等文章。

VB/VBA作为与系统相伴成长起来的可视化编程工具，是一个前可见古人，后不见来者的历史遗产。笔者之所以，极力推荐那些没有过多精力，但又想通过编程提升效率的职场人士学习VB/VBA，其实就是看中VB/VBA的这种系统功能的胶水能力。在Win上VB/VBA就是那个最强的胶水语言！

3、为何不需要VB/VBA的标准DLL？

弄懂了VB/VBA的背景，自然就好理解为何不需要VB/VBA来制造所谓标准DLL了。在前面说了，VB/VBA本身对标准DLL的需求并非不可或缺，大家责难VB/VBA无法输出标准DLL，大抵是因为其他编程工具，用函数指针的方式来使用VB/VBA编译的DLL函数时，不管用了！

这个原因，其实在前面的VTable关键字附近，已经回答了。不知道如何调用ActiveXDLL中的函数，纯粹是不懂，而并非人家烂。更何况，VB/VBA在编译时，可以导出函数。只是，笔者会认为VB/VBA的标准DLL，会和市场反应一样，并没有人需要。

作为系统特色的表演者，VB/VBA也只是个看菜下饭的家伙，众物不过工具而已，拼凑才是她的本事。它保留了多种代码执行模式，不仅可以作为命令行的终极宿主执行各种系统命令，也可以于码海中随意抽取逐句执行，更可以直接执行指定的机器指令。不仅面向过程，也面向对象，更有函数式。不仅用作脚本，自动化，轻代码化，当好护花使者，也可以编译独立行走江湖。不仅有编译器语句打底，更有内置函数、系统和非系统API的装扮。不仅与所谓标准DLL耍朋友，更是与COM拜把子。但所有这些，都只不过保留了一种能力上的接口，并未过多修饰。

用过的人，都知道VB/VBA在语句和内置函数上表现出来的封装性并不高，它甚至都无法做到IDE的代码折叠。一方面VB/VBA容易使用，容易上手，另一方面VB/VBA又很难精通。所以，她注定无法在代码的流水线上留下自己的职位。

同作为功能的胶水，自然可以拿大家公认的Python来做类比。Python的强大，是因为丰富的库资源，和她的撮合能力。但是，有几个直接拿Python去干轮子的？道理是一样的，VB/VBA擅长的，是使用系统里面各色资源，而非制造资源。VB/VBA在使用上的安全性、包容性无一不是围绕使用资源而展开的，在VB/VBA的编译器（解释器）里充斥着大量让专业人士嗤之以鼻的模板化的指令，就意味着VB/VBA生而不为轮子，她是轮子的用户！

道理还是一样的，这货制造的轮子，性能不咋地啊！虽然可以通过手术方式进行二次加工，让其更优化，但已经脱离VB/VBA的高使用效率和低危错误的立身之本了。所以，其他语言不需要VB/VBA的标准DLL，VB/VBA也不打算提供标准DLL，就这么简单！

欢迎关注BtOfficer（收藏、点赞、关注+转发）,更多精彩仍在继续哦（专栏文章将更系统，更全面，但需要阁下支持哦），有严肃的技术，也有轻松的唠嗑，期待你的加入！