I put the DLL and OCX into the resource file, which can be loaded without decompressing it to the hard disk, but the file size was mistaken by the compiler. As a result, the DLL cannot be loaded in the memory.
I PUT A FILE TO Res file,
size=377093
dim bt2() as byte
BT2 = LoadResData(ResNameOrId, ResGroup)
ubound(bt2)+1=377096
Why is it adding 3 bytes? Its so weird
===================
Other people on the Internet have also encountered this problem：
When you plan to add a text file to the resource file and release it while the program is running, you will definitely think of using the resource editor. Okay, the program is ready, load the text file with the byte array loadresdata, and then use open/ Put/close or use API to write this text file to the hard disk, press F5 to run, open the text file to see, uh, no problem, ok, compile the program to EXE, then run it again, open the text file to check, uh , Still the original content.
Many people will think that the program is normal when they see this. In fact, you can use the HEX editor (ULTRA EDIT or other) to compare the text file generated by running in the IDE environment and the text file generated by running after compilation, you will find There are 2 more bytes (00 00) at the end of the text file generated after compilation. These two bytes will not have a big impact on general text files, but for files like XML that need to be strictly interpreted , Two more unnecessary bytes is a fatal injury.
Wonder, how did these two bytes come into being? Analyze the process of file generation:
First look at the results of running under the IDE
The first is loadresdata to load the text file data in the resource file into a byte array
Will there be a problem here? Run in the IDE, set the interrupt, check the value of ubound (byte array), and find that it is the same as the original number of bytes in the text file, so it is excluded from the loading process
Then output the file through VB's own file writing statement or API function
Run in IDE, use OPEN/PUT/CLOSE and CREATEFILE/WRITEFILE/CLOSEHANDLE to generate files. Normally, they are the same as the original file bytes, so it can also be excluded.
Then look at the result of running the compiled EXE file
The same is to loadresdata first to load the text file data in the resource file into a byte array
You cant see the result here. You can set a msgbox prompt ubound (byte array) value in the program. You can see that the array is 2 bytes more than in the IDE. I cant explain whether there is a problem here, and continue.
Then output the file through VB's own file writing statement or API function
After inspection, the files are more than 2 bytes, eliminating the possibility of function errors
So where is the problem? Keep watching
Then use PE explorer to check the internal resources of the EXE file, you can find the text file we put into the resource file, we select this resource, and then click the resource property to view the size of the resource, the shortcut key is (shift+ctrl+P), you can see The number of bytes displayed is 2 bytes larger than the original file. It turns out that the culprit we are looking for is here. It is already so big. No wonder the output will be larger than the original file. The function is not wrong. The function is just for you to output honestly, or from the resource The data coming out of the file doesn't have to be messed up, so why is the IDE output correct, but the EXE output is wrong? It is because the EXE has been compiled and the resource files are compiled into the EXE file. The problem lies in the compiler. The text files in the EXE resource files that are handed out by it are all 2 bytes larger. As for why there are any Conclusion, waiting for the master to answer us. However, it's better to come out and give us a lecture, and send us a new compiler by the way.
