vb6 0企业版（vb6.0企业版官方下载win8 贴吧）

VB/VBA（代表32位）如何继续在64位Win上抖机灵？

1、前篇给大家伙探讨了64位Office的VBA编译DLL的问题，从中我们至少可以引出以下几个有用的信息：

A、64位可以编译32位(前篇已介绍)，难道32位就不能编译64位吗？这不仅是VBA的问题，更是32与64之间鸡和蛋的问题。否则，64位的东西从何而来？64位若是需要64位的编译器，那么64位编译器又是从何而来？

B、大家或许应该知道，2001年Intel推出的Itanium（IA-64 ）就是一个纯种的64位处理器，基于这货的一切都是全新构造的，系统和编译器自然也是。但是它与X86指令完全不同，自然无法兼容X86的32位应用，所以也没能在大众市场取得成功，到现在几近消失。

2003年AMD推出兼容X86的AMD64，迅速获得的市场的拥抱。后来Intel基于相互授权，将AMD64抄了遍，才得以保住颜面。所以通常所说64位PC，可以简单地理解为X86-64。

这就意味着，系统、编译器、应用等各层面上，无需重大修改就可以轻松升级。

C、熟悉Win上PE结构的朋友，就不难得出32与64之间的兼容性。简单地说，把EXE/DLL等文件视为代码存储的外壳容器，那么这个容器的结构是兼容32和64的。要知道，这套结构是在DOS时代成型的。表面上看，是微软工程师的天才设计，但实际上是对X86吃得很透而已。所以笔者总说，微软的兼容只不过是捡了X86的便宜，其他使用X86或类似架构的系统，都能营造出良好的兼容性。

事实上，也有很多极客，直接使用指令来手动生成各种高效的EXE/DLL，不仅可以兼容32/64，还可以避免编译链接器的某些缺陷。各种高级开发工具也都有现成的选项，以满足32/64位程序的编译。

D、如果再深入一点，也很容易发现一些蛛丝马迹。比如线程的TEB，其中就有一个叫WOW32Reserved的成员，有没有眼前一亮呢？对滴，是当年用来解决16/32位兼容的（叫WOW32），现在沿袭下来用于解决32/64兼容的（叫WOW64）。

其实套路，早在VB4.0时代就准备好了。所以，VBA编译64位DLL，不是什么有无的问题。

2、虽然VBA已完美融入64位，但其实大家更想要能在64位Office上抖机灵的VB6。有人说，为何要死抱着VB6不放呢？其实并非抱残守缺，专业人士完全可以借助这些研究项目，了解更深层面的知识。因为其他工具，都给你封好了，绝大部分使用者，也不见得就很了解背后的机制。

当然，对于广大业余爱好者而言，要是能有现成货，无需继续加码学习，便能让旧知识持续有效，简直不要太好！毕竟，吃饭领域的活计够多了，到了一定年龄，上有老下有小，哪有那么多时间精力来学习专业编程。拿来能用，帮助更好恰饭，才是王道！

更何况，不用死抱，VB6所代表的32位，兼容到64位的机制，就摆着的呢！抱与不抱，都在那里，哪为何不多看一眼呐？反正都那么熟了！

3、在64位平台上，从来都不应该在专业上有32/64的说法。虽然VB6编译的叫32位PE，但是他们在64位机器上，都是实打实64位的东西。更确切地说，是同一进程兼具32位和64位特征，最终都是64位的。之所以在64平台上流行32和64的说法，更多地是出于简单粗暴的商业布道。

所以，能编译32位DLL的64位OfficeVBA，没啥大改动，就直接与64位一起耍了。但是，大家见过64位VBA能使用32位API么？微软官方也只是提示到，32位DLL不能加载到64位进程，当然32位进程也不能加载64位DLL。于是大家遵循便是了，但更深层次的原因呢？

偷懒，没错就是偷懒。但是，这个懒是很巧妙的。简单地说，就是旧程序使用旧代码，新程序使用新代码，二者开发时互不干扰。分一下，方便代码资源的挂载。但是，挂载机制，是老早以前（vb4.0那个时代）就定好了，这就是进程那一系列机制。所以，Win与Linux相比，Win因为兼容机制的存在，实际上是不鼓励使用开销巨大的多进程来解决类似于多线程任务的，而是单进程多线程的方式。知道为何大家要骂VB/VBA多线程了吧？

<哎，又到字数上限了，接下篇哈>

欢迎支持并关注BtOfficer，更多精彩仍在继续，有严肃的技术，也有轻松的唠嗑，期待你的加入！