Options for run-time dynamic linking with CVI

[kcoggins]

I am trying to determine which methods are available in LabWindows/CVI 8.1 to link to external entities (DLLs) without using import libraries.

So far, it appears that the LoadLibrary method is the only option available that meets my primary objective that the calling application does not have to be rebuilt if the external entity (DLL) changes, so long as the interface functions to the entity do not change.

[JonathanN]

Hi kcoggins,

Check out another post here that I replied to describing your options of linking to DLLs in CVI. It points to several tutorials and knowledgebases as well.

Best Regards,

Message Edited by Jonathan N on 10-30-2007 02:49 PM

[kcoggins]

Jonathan:

Thanks for your response.  Thanks for the links to the tutorial and other post on this topic.  I am familiar with the tutorials - I was just looking to see if there were any other known methods.

I noticed that if you use an import library that it is no longer needed after you compile your application.  Further, I modified the target DLL by adding both functions and increasing the content of existing functions, and the application could still access the original functions.  In other words, I did not have to rebuild the application when I updated the DLL.  Is this behavior normal when using an import library, or is there risk to this approach?

Kevin C.

[menchar]

That's how DLL's work.  So long as you don't change the function signatures, previously built client applications won't fail to call the function as before.   This way the versioning of the DLL is decoupled from client applications.

E.g., when you update the CVI run time (which is a set of DLL's), you don't have to rebuild all of your CVI applications.

Menchar

[kcoggins]

Menchar,

Thanks for your reply.  That is the exact information I was looking for.

Best regards,

Kevin Coggins

[menchar]

Kevin -

I may have steered you wrong about the implicit linking (.lib) and DLL versioning.

I have a reference which claims that implicit linking (.LIB) breaks if you add a function to a later DLL version.  But as you discovered, you could add a function to the DLL and previously linked apps work fine.  It could be it depends on where in the DLL you add the function(s).

Did you happen to add the new function at the very end of the DLL?

I need to track this down.   Sorry about the confusion.

Menchar

Message Edited by menchar on 11-01-2007 01:50 PM

[menchar]

Kevin -

It looks to me that if you don't change the export ordinal of any of the previously existing and exported DLL functions, you don't have to relink the client app with a new .lib file after changing the DLL.

I see a file named "exports" in the build folder for my DLL, it is a text file that lists all of the DLL functions being exported.  There's no explicit "export ordinal" listed for each function, the functions are listed by name in alphabetical order.

I can't get the DUMPBIN.EXE Visual Studio utility to dump the function ordinals of the DLL - not sure why it's not working.    If it was working, it would be a simple matter to see the effect of adding functions to the DLL on the ordinals.

It looks like you could fix up some glue code to maybe mitigate the pain of retrieving and using function pointers when explicitly (dynamically) loading and linking the DLL. 

My apologies over this - I have to say I don't know the answer.

Menchar

[menchar]

Does anyone know:

1.  What determines the "function ordinality" of the functions within a DLL created with CVI?  There's an export file in the build folder for the DLL but it just lists the functions in alphabetical order and doesn't indicate a "function ordinal" that I can see.  Is function ordinality the alphabetical order of the exported functions?  Is it the lexical order of the functions?  MSDN says that so long as you don't change the function ordinal of any of the previously exported functions, you can modify the DLL without needed to relink the application with the new export library.  Is "function ordinal" a synonym for "function signature" ? 

2.  Has anyone used bindump to look at a dll's exported functions and the function ordinals?

I've read all of the tutorial info both NI and MS and there's no answer - I understand completely why Kevin was asking the question - where's the answer?  Surely someone at NI knows ...

Menchar

[menchar]

It looks like this will work OK after all.

I used dependency walker to look at ordinals and function names in a DLL.  I verified that you can alter the DLL, changing the ordinal of a particular function, and an executable built with an old import library still finds the correct function in the new DLL despite its ordinal having changed.

I think this works because I'm using the the DLLEXPORT which is the macro __declspec(dllexport), and it exports the DLL functions by name, not just by ordinal.  And at runtime, the executable fixes up the address of the function when the DLL is implicitly linked and loaded by matching names between the import library and the DLL's export table, not ordinals.

There's some conflicting info out there, that's for sure.  If the code is C++, the function names get "decorated" (the P.C. term for mangled) and different compilers mangle in different ways - so the name matching could break if the mangled names for the same function were different due to compiler version or vendor.  But then I found something that made me think the name matching could work despite the mangling.  I didn't bother tracking this down since I'm using C for client and the DLL.

It will still break if you change the signature of a function, but it seems we're able to add functions to the DLL, and change the internals of previously exported functions, without having to rebuild every client application.

And with .NET and "side by side" assemblies, it's all different.  Now that we're mastering DLL's, they're obsolete.  I told my boss I'm leading the charge into the '80's.

Menchar

[kcoggins]

Thanks for chasing that one down.  I ran some test cases and achieved the same results as you did.

Kevin C.