当你打算添加文本文件到资源文件里打算在程序运行时释放它的时候,你一定会想到用资源编辑器,好了,程序编好了,用byte数组loadresdata装载这个文本文件,然后用open/put/close或者用API把这个文本文件写到硬盘上,按F5运行,打开文本文件看看,嗯,没问题了,好,编译程序为EXE,然后再运行一下,打开文本文件检查一下,嗯,还是原来的内容。很多人看到这里就会以为程序正常了,其实大家用HEX编辑器(ULTRA EDIT或者其他的)比较一下在IDE环境中运行产生的文本文件和在编译后运行产生的文本文件,你就会发现在编译后产生的文本文件的末尾多了2个字节(00 00),这两个字节对一般文本文件不会产生很大影响,但是对于像XML这类要经过严格解释的文件来说,多了两个无谓的字节就是一个致命伤。纳闷吧,这两个字节是怎么产生的?分析一下文件产生的过程:先看看IDE下运行的结果首先是loadresdata把资源文件中的文本文件数据加载到一个byte数组这里会出问题吗?在IDE中运行,设置中断,查看ubound(byte数组)的值,发现与文本文件原字节数相同,所以排除在加载过程中产生然后通过VB自带的写文件的语句或者API函数输出文件在IDE中运行,分别用OPEN/PUT/CLOSE和CREATEFILE/WRITEFILE/CLOSEHANDLE产生文件,正常,都与原文件字节数相同,所以也可以排除。然后看看编译后的EXE文件运行的结果同样是先loadresdata把资源文件中的文本文件数据加载到一个byte数组这里看不到结果可以在程序里设置一个msgbox提示ubound(byte数组)的值,可以看到数组比在IDE时多了2个字节,暂时不能解释是否这里出问题,再继续然后通过VB自带的写文件的语句或者API函数输出文件经检查,文件都多了2字节,排除函数出错的可能那问题到底出在哪里呢?继续看就知道了再用PE explorer查看一下EXE文件内部资源,可以发现我们放进资源文件的文本文件,我们选中这个资源,然后点击资源属性查看资源的大小,快捷键是(shift+ctrl+P),可以看到显示的字节数比原文件大了2个字节。原来我们要找的罪魁祸首就在这里,它本来就这么大,难怪输出后会比原来的文件大了,函数是没用错,人家函数只是老老实实给你输出的嘛,要不从资源文件出来的数据不都要乱了,那为什么IDE输出没错,而EXE输出就出错了呢?就是因为EXE经过了编译,资源文件编译进了EXE文件里,这个问题就在编译器上,经它手出来的EXE的资源文件里的文本文件都大了2个字节,至于为什么还有没有结论,等高手来答复我们了。不过,最好还是老比出来给我们演讲一番,顺便给我们送上新的编译器吧。
我是 vb6+sp6和xp sp2简体中文
b = LoadResData(101, "CUSTOM")
Open "c:\t.txt" For Binary As #1
Put #1, , b
Close #1
...
好象没有看到.......
这个小软件如果要做出来,说难不难,说易不易,还是有一点技术性.谁能用VB写出这样子的软件,给我源码,给200元酬谢.
我的QQ 10046870
a= LoadResData(101, "CUSTOM")
'debug.print ubound(a)
ReDim Preserve a(???) As Byte'在這裡的???上用調試時ubound(a)的值來代替。'接下來用a()就沒問題了。