Specify dll locations using a configuration file

[m3rl3n]

In our very complex world, we have a virtual machine that simulates a number of different system configurations. Because of this, each system is contained in a high level folder on the local machine and we then map a Z: drive to that location using a startup batch file.  This way my software (and a number of others) can be generic and reference the Z: drive.

Since some of these systems are radically different, sometimes the dlls that I need for my program to run are placed in different folders for various reasons. We try to maintain a similar directory structure between the system level folders, but...

I was wondering if anyone has developed a means or can set me in the right direction where if I start the executable, the first thing it does is reads maybe an ini file and it sets the path for the dlls.  The issue that is in the back of my head is that LabVIEW needs to know the locations of those dlls when the program is compiled, so I'm not sure that approach would work.  Making a new compile for each of the various system folders is not a viable option.

Any thoughts?

[altenbach · Accepted solution]

---

@m3rl3n wrote:

The issue that is in the back of my head is that LabVIEW needs to know the locations of those dlls when the program is compiled, so I'm not sure that approach would work.

You can call a dll by a path given at run time, just check the box and provide a path to the new path input connector.

[m3rl3n]

Specifying the path is what I was thinking about / planning on. As I said, I had the inkling that I needed to have it specified at compile.  Thanks for the affirmation!! 

[altenbach]

As an example, here's what I do to "parallelize" a non-reentrant dll written in FORTRAN. I have a 32bit and 64bit version of it in my "data" folder, selected by the type specialization structure according to bitness. Then I create (at first call only, cached on later calls, only if they don't already exist!) N differently named copies in the temp folder, one for each CPU core, and call them in a parallel FOR loop by "parallel instance ID"). This gives me a 16x speedup on my 16 core dual xeon and even more with more cores (list of tested computers) 😄