从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屋！