Dynamically load nianlys.dll

[baker_matt]

I am trying to dynamically load nianlys.dll rather than link directly to analysis.lib. When I try to load a function using GetProcAddress the funtion can not be found.  I looked in the Dependancy viewer and it shows all of the exported symbols as AALFuncxxx (where xxx is a number).  Is there some mapping to these symbols that will let me know which functions they represent (for example: WhiteNoise) ?

[JonathanN]

Hi baker_matt,

We don't allow our customers to dynamically load the underlying analysis DLL and thus that's why you see those "unusual" exported functions names.  I'm not sure why you are trying to do this as the nianlys.dll is already dynamically loaded upon your first call to any analysis function. Of course from that point on, that DLL stays in memory. 

Maybe you could explain why you think you need to load this DLL yourself and perhaps we can come up with a good solution for you.

Best Regards,

[baker_matt]

I am curious as to why you would not want people to dynamically load the analysis dll (although not relevant). I suppose my reason for loading the DLL at runtime is the same for everyone who dynamically loads a dll.  My code needs to compile and run in circumstances when the .DLL and/or  .LIB is not present.  We are creating a joint library that will be distributed with all of our software, however not all of our software needs the dependencies of the NI Libraries.  We are creating a math library that contains several different routines some of which use some the NI analysis routines and some that do not.  However we would like to distribute the same math library with both of our software packages (one that would require analysis.dll and one that would not). In the end it is a rather silly attempt to prevent people from dynamically loading the DLL in theory all one would have to do is create another dll that statically links to analysis.lib that exports the required symbols and then dynamically load that one.  All this does is cost me more time, effort, and dependencies which is exactly what I was trying to avoid in the first place.

[JonathanN]

Hi baker_matt,

Historically, our analysis code has been implemented as a static library and thus what you are wanting to do wasn't possible then. The nianlys.dll is shared across multiple NI products and in particular, its shared across CVI Full and CVI Base. This means that we need to encrrpt the contents of this DLL so that Base users can't run Full analysis functions.  Your best option is to create your own wrapper analysis DLL for NI functions and load that dynamically based upon some condition.   

Best Regards,

[menchar]

I'm with baker_matt on this one.

Microsoft says dynamic loading is the only way to guarantee you're going to match up function signatures when the dll is revised to add new functions, so that you can do call by name.  I think Microsoft also says that the dll's DllGetVersion function, which is required in order to be an ***official*** windows dll, should always be called by name, which means a dynamic load, unless I'm mistaken about all of this.

However, I've found, that if the main app and the dll were both developed in CVI, I can revise the dll to add a function, and still not break previous dll clients, there's no need to rebind the app to the new export lib.  I'm not sure I'd bet this is true if app / dll were developed with different frameworks.

I suppose you might say this doesn't apply to a canned NI dll, or who cares about creating a fully windows-compliant dll.

Menchar