1、VB6代表的Win32位开发，不仅依托WOW64兼容层可以继续以32位的姿态苟活在64位Win平台上，而且还可以直接利用WOW64兼容层的机制跨入64位的世界，白嫖各种64位的二进制资源。

2、相信很多VB6老玩家们，都玩过Hook注入、跨进程内存读写一类的奇技淫巧。32位Win上跑得顺溜的代码，到了64位平台上，却总会出现这样那样的问题。搜一搜，查一查，微软那句32/64位Dll互不能载入，是不是让人心凉半截？随着64位硬件的全面普及，迟早都是64位应用的天下，32位还能苦撑多久呢？

VB6若不能使用64位的库资源，走路的腿就短了，那这条道注定就是一条看得见终点的死路。那还吹什么VB简答易用，吹什么VB里的乾坤奥妙？即便再适合业余玩家，那也不能玩一个指不定什么时候就没法用的工具呀。

语言可以有自己的生态，可以在这个生态上衍生出一系列茶余饭后的鄙视链，但干活的工具至少得有啊，可用、能用是最起码的吧。VBA升级到了64位，对于VB家族而言，也算是保证了核心支持，不至于整个VB被砍掉。但作为提升VBA代码性能的VB6（为什么？），却没有得到升级支持。

这让很多爱好者有些难受，也有些灰心。因为VB6也是VBA实现商业价值的最便捷的途径，而VBA又是事实上的开源，没有利益的驱使，VBA就要真的成为自留地上的锄头了。因为，闭源体系下讲开源，那才叫人品。

3、虽然笔者在前面也分享了64位OfficeVBA编译DLL的方法，但限于资源问题，要实现起来就很复杂了，对于大多VB/VBA用户而言也不具备普适性（当然后面会有现成的工具，那就很普适了）。所以想通过64位VBA给VB6拉光环，就需另辟蹊径。

不过，笔者在前面也给大家伙分享了，64位Win上的32位，其实就是64位。既然其他64位都可以使用64位库资源，32位的VB6就不行了呢？要想行，还得深入WOW64机制才行。

4、通过以前的介绍，我们大致知道无论32位还是64位，在64位Win上都是共用一套内核。其中WOW64兼容层，最核心的作用就是转换CPU模式，从32位进入64位模式，完事后再回到32位模式。

既然如此，那VB6何不直接使用这套机制，自己控制呢？若如此，VB6就可以使用64位DLL了，真正地实现32位即64位，岂不美哉？然而，个中原理也是非常复杂，并不适合广大VB/VBA人士。

5、所幸，这个世界上有人品的大牛还是大有人在。今天，笔者就给大家或介绍一款开源扩展库（wow64ext），作者是rewolf。不仅有源码，还有二进制的32位库，才9K哦。源码就不介绍了，都是汇编和C，而且需要对WOW64机制有深入了解，才能看懂。

来看看都有哪些函数：X64Call、GetModuleHandle64、GetProcAddress64、VirtualQueryEx64、VirtualAllocEx64、VirtualFreeEx64、VirtualProtectEx64、ReadProcessMemory64、WriteProcessMemory64、GetThreadContext64、SetThreadContext64、SetLastErrorFromX64Call。看见这些名字，是不是有点激动呢？赶紧去搜索、下载试一试吧，谁说VB6不能继续豪横呢！