从VBA(64位Windows)访问DLL函数的麻烦 [英] Troubles accessing DLL functions from VBA (64-bit Windows)
问题描述
我正在64位环境中开发Windows DLL(Visual Studio 2017,Windows 10)。
I am developing a Windows DLL in a 64-bit environment (Visual Studio 2017, Windows 10).
我有一个声明如下的简单函数:
I have a simple function declared as follows:
ulong __stdcall foo(char * buffer,ulong buffer_size);
ulong __stdcall foo(char *buffer, ulong buffer_size);
我有其他函数以相同的方式声明,到目前为止我没有遇到任何问题。直到上周,我发现VBA(在Excel下)输入的第二个参数(buffer_size)的地址完全错误。
I have other functions declared in the same way and so far I did not encounter any issue. Until last week where I figured out that the address of the second parameter (buffer_size) given in input by VBA (under Excel) was completely wrong.
尝试了很多东西来解决问题,我看了一下生成的地图文件。以下是报告如何在MAP文件中导出foo()(请注意,我使用.def文件导出我的DLL函数):
After trying out many things to solve the problem, I had a look at the generated map file. Here is how foo() is reported to be exported in the MAP file (note that I use a .def file to export my DLL functions):
;    10    ?foo @@ YAKPEADK @ Z(unsigned long __cdecl foo(char *,unsigned long))
  ;      导出名称:foo
所以虽然我强制调用约定为__stdcall,但似乎(?)函数是用__cdecl导出的。这可能与我遇到的问题有关(但不是100%肯定)。
So although I am forcing the calling convention to __stdcall, it seems (?) the function is exported with __cdecl. This could well be in relation with the problem I have (but not 100% certain).
对此问题的任何想法/反馈都将受到高度赞赏!
Any idea / feedback on this problem would be highly appreciated!
推荐答案
根据文档,在64位处理器上
__ stdcall 和 __ cdecl 已被接受,但通常会被编译器忽略。
缓冲区在 RCX 寄存器中传递, buffer_size - 在
RDX 。
According to documentation, on 64-bit processors __stdcall and __cdecl are accepted but typically ignored by the compiler. Buffer is passed in RCX register, buffer_size — in RDX.
因此,这似乎是一种误报。也许VBA声明是错误的。
这篇关于从VBA(64位Windows)访问DLL函数的麻烦的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!