Calling DLL in CVI2013

[Wolfgang]

Sorry for this basic question but I am not very familiar with external DLL's...

I have some older code where I used

typedef void ( __stdcall *fp_SPNDLdllTYPE )( double *, double *, double *, double *, long *, char *, long );

I need this to assign the address of a function in the DLL using LoadLibrary and GetProcAddress.

Everything was fine until I recompiled this code with CVI2013,.the address obtained now is zero... ?

Since the compiler has changed I tried both default calling conventions in the Build options, but it did not help...

What do I need to change? Thanks!

[LuisG]

So you declared a variable of type fp_SPNDLdllTYPE, and you are storing in this variable the value returned by GetProcAddress, as in this code snippet, right? But GetProcAddress is now returning NULL even though you are passing it the same exact arguments that you used to pass before?

I assume that the LoadLibrary call succeeds?

Is this DLL also a CVI DLL that you've since rebuilt with CVI 2013?

The GetProcAddress documentation states that you can use GetLastError to get some more info when GetProcAddress fails. Have you tried this?

Luis

[Suse]

Hi Wolfgang,

have you checked if the "LoadLibrary-" and "GetProcAddress-" functions are working properly?

These functions both return NULL if they fail, for example if the handler or path are wrong. See here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx

Best regards

Suse

[Wolfgang]

Hi Luis,

thanks for your questions, this is the code which has not changed while the version of CVI has changed from 2012 to 2013:

typedef void ( __stdcall *fp_SPNDLdllTYPE )( double *, double *, double *, double *, long *, char *, long );

fp_SPNDLdllTYPE SPNDLdll;

rp_dll = LoadLibrary ( "rp" );
if ( rp_dll != NULL )
{

    SPNDLdll = ( fp_SPNDLdllTYPE ) GetProcAddress ( rp_dll, "SPNDLdll" );
}

LoadLibrary succeeds, other function addresses are found, GetProcAddress returns zero for the given code, and GetLastErrors says that "The specified procedure could not be found." The DLL is a commercial one.

Thanks!

Clueless, Wolfgang

[LuisG]

That's very odd. Since the CVI compiler has played no role in building this DLL, I can't imagine what difference 2013 vs. 2012 could be making.

So, what you're saying is that you can run that exact code with CVI 2012, and GetProcAddress works fine, but when you run it with CVI 2013, while using the same exact DLL, it does not? Is it possible that you could have more than one copy of this DLL in your hard-drive, and the search path used by LoadLibrary could be finding different copies (I believe the current working directory affects the search). To confirm this, you can use GetModuleFileName to make sure that you're loading the DLL from the same place. (By the way, is the name of the DLL really "rp"? Not "rp.dll" or something?)

Do you have access to Visual Studio? If you do, you could try running this code from Visual Studio to see if it makes a difference. It would also be useful to try the dumpbin.exe utility that comes with Visual Studio to make sure that SPNDLdll is really being exported:

    >dumpbin /exports foo.dll > exports.txt

[CVI-User]

Hi,

If this DLL is build with (e.g.) Visual Studio I'd expect the entry point to be called _SPNDLdll@28 (or sth. like that), since it's __stdcall and not __cdecl.

This is an other tool which shows the DLLs entry points: http://www.dependencywalker.com

[Wolfgang]

A 'Thank you' to both of you, I'll try depency walker as I don't have Visual Studio.

@Luis: Indeed I do have several copies of the DLL around, but all are the same version, I have checked this several times 😉

By now I have also realized that I had upgraded the DLL last year, too, so I contacted the company if there were some undocumented changes... But it's a good opportunity for a first dependcy walk

[Wolfgang · Accepted solution]

Let me again thank you all and apologies for this off-topic... As it turned out the issue is not related to CVI, it was the dll that had changed...

I was told that in the latest version the missing subroutine was divided into two pieces (with different names, of course)...

[LuisG]

Ah, a non-backwards compatible DLL... schrecklich!

[Wolfgang]

---

@LuisG wrote:

Ah, a non-backwards compatible DLL... schrecklich!

---

Not with your help Did your time zone change??