vb中copymemory函数的问题?

Question

如题所述

Answer 1

针对您在VB中遇到的`CopyMemory`函数问题，实际上是由栈上数据的互相覆盖导致的。让我们逐步深入理解这个现象。

在VB6中，`Integer`类型的数据长度为2字节。然而，当您使用`CopyMemory`函数复制4字节的数据时，后一条`CopyMemory`命令可能会导致越界，进而引发覆盖问题。

具体来说，当执行第二条`CopyMemory`命令时，它会将4字节的数据复制到`NumPoints`变量的地址上。然而，由于`NumPoints`变量实际只有2个字节的空间，这会导致后面的`Num`变量内容被覆盖。我的分析是，`pByte`中从148到152的区域应被看作是填充了00的，因此最终输出的`Num`值被设定为0。

如果我们将代码逆向运行，情况会有所不同，但在逆向代码中，第二条`CopyMemory`命令实际上会覆盖其他数据，具体取决于代码的编写方式。同样，第一条`CopyMemory`命令也会影响到`Num`的值，您可以先给`Num`赋值，然后执行逆向操作后打印`Num`值，结果同样会是0。

若您对C语言有所了解，这类问题的解决思路会更加直观。

对于VB而言，使用`CopyMemory`函数存在一定的风险，推荐采用`len`函数来确定要复制的内存大小，这样可以提高代码的可靠性。

昨天填了这个坑后，我意识到可能需要对我的理解进行修正。经过反汇编分析，我发现尽管`Integer`的大小是2字节，但VB在编译时通常以4字节对齐。

观察运行结果，我发现结果与预期有所不同。通过逐一尝试编译选项，我确认除了生成P代码外，其他生成本地代码的运行结果均为1，反汇编也证实了尽管`Integer`的大小为2字节，但在生成的汇编代码中都以4字节对齐。

我推测，如果您未曾尝试生成EXE文件，您可能会发现EXE文件的结果与VB环境中的结果不一致。

至于为什么P代码以及在VB运行时的结果与本地代码的生成结果不同，通过反汇编P代码的方法可以进一步定位问题。P代码作为解释型语言，大部分实际代码都运行在VB的DLL中，通过反汇编仍然可以定位到`CopyMemory`函数的位置。

通过适当的代码修改，可以清晰地观察到，在P代码模式下，两个`Integer`变量确实没有按照4字节对齐，而是相邻放置。

综上所述：

1. 您在VB中遇到的情况可能是不正确的，但生成EXE文件时可能会出现不同的结果；

2. 在VB中和P代码模式下，VB采用了解释运行的方法，与直接生成本地代码的运行结果有所不同；

3. 不同编译模型下栈上数据的对齐方式存在差异。