V
VieuxCherokee
Guest
Hi,
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);
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.
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))
exported name: foo
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!
Continue reading...
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);
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.
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))
exported name: foo
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!
Continue reading...