LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Labwindows CVI "obj" problem loading external library

Solved!
Go to solution

Hello Community,

I'm facing a new problem:

I have created an c file to be used as an obj and inside I am loading an external library (setupapi).

I have tryied to load the DLL by LoadLibrary() or the lib by LoadExternalModule 

Then When I execute it in debug mode there is no problem, but when I try to use it in release I've got "unable to verify test XXX in c:\YYYY\file.obj (GetExternalModuleAddr error: undefined references)

If someone have an idea on this subject.

Thanks,

Best regards,

Zergios

0 Kudos
Message 1 of 7
(2,167 Views)

It would help in being able to see the code. As far as trying to load setupapi.lib with LoadExternalModule() that seems pretty useless. setupapi.lib is simply a so called import library. It is not much more than a collection of tiny wrappers for each exported function that does nothing more than LoadLibrary() for the DLL in question and then a GetProcAddress() for the function. So it is really just a detour to doing this yourself directly in your C code.

 

And if you use LoadLibrary() you really should also use GetProcAddress() on that module handle.

 

LoadExternalModule() and GetExternalModuleAddr() are LabWindows/CVI specific functions that exist mainly for historical reasons. Before LabWindows went Windows, it was a DOS application and there did not exist anything like DLLs for DOS. And memory was SCARCE, with 640kB being the standard limit, which could be extended to 1MB with some trickery. There it was very helpful to be able to load and unload obj files at demand in order to safe some memory. LabWindows was pretty unique in how it did it, basically inventing what DLLs later did in Windows. Turbo Pascal had its own way of using overlays, which had the same intentions but in a somewhat different way. Nowadays DLLs do the same in a more standardized way and should be used whenever possible.The LabWindows/CVI module API is really more of a legacy feature.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 7
(2,125 Views)

After more investigation it seems that it is the "lstrcpy" that cause this problem. 

When replaced by strcpy it work both in debug (.c) and with the (.obj)  

I don't really understand why.

0 Kudos
Message 3 of 7
(2,119 Views)

lstrcpy() is also a Windows API function and is implemented in kernel32.dll but not as lstrcpy() but rather as lstrcpyA() and lstrcpyW() for 8bit ASCII and Widechar Unicode16LE implementation.

 

Did you link with kernel32.lib?

Did you make sure to include the right Windows headers which define lstrcpy as either lstrcpyA or lstrcpyW depending on the UNICODE preprocessor define?

 

See here for the documentation.

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 7
(2,114 Views)

Hello Rolfk,

First, thanks a lot for your response.

It is probably where my problem is.

 

Did you link with kernel32.lib?

=> I am making a 32 bit exe but didn't precise in my project that I want explicitely link with kernel32.lib, I don't know how to do that.

In "target settings" I've got 

               - Configuration "Release"

               - Application File "Test.exe"

               - Run-time support "Full run-time engine"

 

 

 

Did you make sure to include the right Windows headers which define lstrcpy as either lstrcpyA or lstrcpyW depending on the UNICODE preprocessor define?

                => I am including "Windows.h" which include "winbase.h"

                - Not sure what was to use to precise that I don't want to use the UNICODE format.

Best regards


Serge

0 Kudos
Message 5 of 7
(2,110 Views)
Solution
Accepted by topic author Zergios26

Well, you can add extra libraries to the linker settings. But the online help for LabWindows/CVI states that it searches automatically for these libraries when linking a project:

 

kernel32.lib
gdi32.lib
user32.lib
advapi32.lib
uuid.lib
winmm.lib

 

As to not wanting to use the W functions: You either must make sure that UNICODE is NOT defined anywhere or you can alternatively directly reference the A function by specifying the whole name. So using lstrcpyA() instead of lstrcpy() in your source code will always link with the ASCII version of the API irrespective of any UNiCODE define.

Rolf Kalbermatter
My Blog
Message 6 of 7
(2,088 Views)

Thanks a lot for your help

Best regards,

Serge

0 Kudos
Message 7 of 7
(2,078 Views)