msvcr100 dll（msvcr100.dll已加载,但找不到入口点）

谈谈VB/VBA中的万能API动态调用1、VB/VBA的可玩性不仅在于语法语句层面有仅在咫尺的编译器和解释器，也更在于WIN32API这个巨量的资源库。但凡能够轻松干WIN32API的编程语言，在Win平台上都是狠角色。毕竟在Win平台上，WIN32API才是底层的砖石。要比轮子，还有谁比WIN32API更能滚呢？2、VB/VBA调用Win32API，通常是采用Declare机制。虽说Declare机制有那么一丢丢费内存和低效，但的确可以给使用者带来很多灵活性。BtOfficer也给大家介绍了Declare里可以提高性能的方法。这在以往的文章中，已有详细分析，感兴趣的网友，不妨空了的时候去翻一翻。3、但眼尖的网友发现，要是经常用VB/VBA写东西，Declare这玩意儿就成了一大败笔。因为，每个工程里都需要重新Declare，这就导致了大量的重复。那有没有Import啊，Include啊之类的东西，把这玩意儿一下弄进来？其实，VB/VBA里也有，引用就是啊！但是很多网友就要问了，引用不就是前期绑定么！那不是对象么？的确如此，引用要和对象捆绑。那有没有万能动态调用API的呢？有啊，其实Declare机制本身就是万能动态调用API呀。不然，你逆向VB/VBA的应用程序，咋只有MSVBVMXX.DLL呢。4、有网友评论以前的文章说，既然动态调用api那么肯定是尽可能追求高效率，首先就应该把variant踢出局，16字节的封装入栈编译器能生成多少无效代码你知道不？一样动态调用api的万能call仅需要2个参数functionapicall(byvalpfnaslong,params()aslong)aslong看上去，有几分道理，尤其是Variant，在VB/VBA中已经是谈Variant色变的程度了。BtOfficer也曾多次提醒网友，要想提高性能，要谨慎使用Variant。但是，很多网友还是曲解了BtOfficer的意思，认为Variant是低效之源，应拒绝使用。其实，Variant的低效主要来自VB/VBA中隐含的类型转换，因为会导致转换函数的调用。这是为工具层面的灵活和任性而准备的服务（代价）。但声明Variant类型的变量，在栈上分配16字节内存，并不会导致额外的指令。如果能够避免Variant的类型转换，Variant带来的灵活性，以及灵活性带来的指令节约，是拒绝使用Variant所不能比的。所以，Variant并不能同低效划等号。5、WIN32API的参数列表都是数值类型，其中大部分都是指针。32位Win中，VB/VBA这种弱类型语言，混同了很多数据类型，最典型的就是指针和4字节整数。该环境下的VB/VBA，API的参数的确都可以视为1种类型（也即Long）。因此理论上讲，万能动态调用API，仅需函数指针及其Long类型参数列表两个元素就行，也就是网友所列举的示例。接下来，让我们继续看看，是不是『理想很丰满，现实很骨感』？函数指针好办，有现成的API，直接调用即可获得。参数列表呢？如果传递1个Long数组，是简单，就1个地址（指针）。但是，你得先定义这个动态数组吧，还要初始化这个动态数组吧。有多少个参数，每个参数的具体类型，是不是都得判断呢？如果是人为判断，为何不直接使用Declare呢？如果是代码判断，最后还得取址，那产生的指令数岂止Variant能比的？这些实参都还好办，那形参呢？谁来接收你的参数呢？自己实现，那可不得寻址取值么？而且动态数组的数据不是在堆上么？和栈上的Variant比高效啊？所以，别小看VB/VBA，别以为VB/VBA的语法像个玩具，这个最难精通语言排行榜上的常客，可不是玩具那么简单。欢迎关注BtOfficer，学好VB/VBA，再浪JSA，办公无敌手，摸鱼亦自然。