网管小贾 / sysadm.cc

告诉大家一个坏消息，我又遇到了问题。

再告诉大家一个好消息，我把问题给解决了！

哈哈，没错，前不久我遇到了一个奇葩问题，头毛都快掉完了，现在很怕别人对我说“谢”字！

凡是撸过代码的小伙伴们一定知道，有一种将第三方文件打包到当前程序的方法。

这种方法可以使得在需要的时候将之前打包好的文件释放出来，然后再加以利用。

这样做的好处有很多，比如可以用来制作单一绿色程序，不用拖泥带水跟着一堆文件，用时就拿出来，不用时再收回去，方便异常。

而在这种方法中，被打包进程序的第三方文件就被称作为资源文件。

而资源文件是通过资源编辑器等方式打包绑定到当前程序中的。

说到这儿，那么具体的这个资源文件是怎么打包进来的呢？

最简单的做法就是利用资源编辑器了。

你看哈，比如打开 VB6 的 IDE ，就可以看到有这么一个小图标，那就是传说中的资源编辑器了。

打开看看？

好，打开了，可以看到上边工具栏里靠右边有一排小图标。

它们分别是字符串、光标、图标、位图，还有自定义资源，就是这么样来添加不同的资源文件的。

通常我用的最多的就是自定义资源了，因为这玩意是万能的啊，啥格式类型的文件都能整，万金油一枚啊！

只要轻轻点它一下，它立马问你要添加哪个漂亮的倒霉蛋。

只要你说话，好咧，就是它了，它就乖乖地进来，成了当前程序的一部分了。

不过嘛进来才发现，好像有点不太人性化哈，每进来一位都用编号表示，类型名称一律为 CUSTOM ，整得跟太平天国一个尿性。

光看编号不看脸，这叫天王我咋记得住谁和谁，到了晚上怎么翻牌子？

其实可以通过修改属性把类型给改了，类型可以叫任何的名字，CUSTOM 就是一种类型。

当然在调用的时候要注意可别写错了。

最后该进来的都进来了，保存资源文件，后缀名就是 RES 。

别看多了一个 RES 的资源文件，在编译生成 EXE 文件后是不需要它的，它的作用就是将之前添加的文件都打包进 EXE 文件。

利用资源编辑器挺方便的，不过还有一种通过命令行调用 RC 程序来制作的方法。

只要安装了 VB6.0 编程环境，就可以很容易地找到一个程序命令：rc.exe 。

这玩意就是用来制作 RES 资源文件的，当然不仅是 VB ，像 VC++ 之类的也大概其是这么玩的。

简单地说，打开记事本，输入以下代码，单词之间用 TAB 或空格分隔。

然后将其以 rc 为扩展名保存到需要打包文件所在的文件夹内。

比如保存为 1.rc ，然后将它和 FOO1.DLL 及 FOO2.DLL 两个文件放到一起，再加上个参数 /r 执行打包命令。

如果没放到一起，它就会找不到打包目标对象。

正常情况下就不会报错。

一旦成功，会在文件夹内生成一个 RES 资源文件，这和资源编辑器的效果是一样一样的。

接下来添加这个资源文件也是小事一桩。

哎，啰嗦了这么多，可能有的小伙伴想要打哈欠退场了。

抱歉，现在重点来了！

按理说资源文件添加没问题，只要用的时候调用就行了，对吧？

可偏偏事与愿违，有时调用并不顺利，甚至频频出错，让人抓狂！

大家请看，如下是通常释放资源文件的代码，简言之就是利用了写二进制文件的办法。

然而这里却暗藏着一个惊天的大 BUG ！

代码本身没啥问题，可是当你在查看释放后资源文件的大小时，它居然……不……正……确！！

怎么不正确？

它会多出几个字节！

有些情况下，文件多几个字节无伤大雅，并不影响使用。

但是有的文件就不能出现这种情况，这样会导致程序无法运行，甚至是崩溃！

后来我这么一查，这释放资源文件大小不正确的问题，我去，还真是 VB6 的一个 BUG 。

据说在 SP6 时已被修复，这个 BUG 所呈现的现象是，它会在释放出来的文件屁股后边随机加上 1 个到 3 个空字节 vbNullChar 。

你看看，你看看，它喵地还是随机的，这还怎么玩！

为啥会这样，大神给出了解释，可能是由于 DWord 对齐。

至于这个所谓的 Dword 对齐到底是什么东东又到底发生了什么，作为小白一枚啥都不是的我连问都不敢问。

或许是为了确保某些文件格式的正确性吧，比如 HTML/XML 类型的文件。

因而像这类文件的尾部，如果混入了 vbNullChar ，那么可能就没办法正确读取了。

其中官方说到 SP6 已修复此 BUG ，我呵呵，这纯属大虾扯蛋，大神在后来的帖子中也验证了这个荒谬的说法。

按官方文档所说，VB6.exe 在 6.0.91.15 及 VBA6.dll 在 6.0.0.8965 版本以上就算修复了。

放P都不带眨巴眼儿的，我都测试过，根本就没有修复嘛！

如下图，我使用的版本肯定是高于官方文档所述的版本。

可结果还是出现了释放文件大小不正确的问题，也别怪我一顿输出。

其实这个问题现象吧，严格来说应该是在编译前（即 IDE 环境下），输出文件的大小是正确的。

而在编译后，也就是生成了 EXE 文件后，输出文件的大小就有了偏差。

那位说，是不是你添加资源的姿势不对？

哎，起初我还真怀疑过！

不过就像前文介绍的那样，不管我用什么方法添加的资源文件，都有这个 BUG 存在。

结论也反向验证了这个 BUG 和添加方式没有关系，毕竟问题只在编译后的 EXE 文件中才出现。

看来看去，期待官方来修复这个 BUG 已然是不太可能了，毕竟都已经2024年了！

怎么办？

伟大的领袖毛主席教导我们：独立自主，自力更生，艰苦奋斗！

人总是要有点自主精神的，遇到困难不要被轻易吓倒，要就地躺下，吃饱喝足休息一会儿再起来想办法。

时间紧任务重，我可没说躺平哈，我只是躺了71小时59分60秒。

好，骂也骂了，歇也歇了，开始干活！

既然 BUG 客观存在，那么我们就另辟蹊径，在释放文件时手动修复不就欧了呗！

方法原理也不难理解，只要知道文件的原始大小，在释放文件时控制它以正确大小写入输出即可。

网管小贾的释放资源文件大小修正示例程序源代码

下载链接：https://www.123pan.com/s/bI7Mjv-5XAH3.html

提取码：<关注公众号，发送001087>

相比较之下，这个方法比网上大神说的办法更容易操作，也更简单，不用额外加入配置或其他什么设定，一切都在程序内搞定。

小伙伴们也可以找来自己的文件放进去试一试。

别看广告，看疗效，最后只要确认文件大小，以及哈希值即可验证正确性！

将技术融入生活，打造有趣之故事

网管小贾 / sysadm.cc