hardware DLL path / directory

[qku]

Some hardware modules require a DLL to communicate with the hardware. Sometimes this DLL is put automatically into a folder like C:/Windows/System32 during installation of manufacturer software, but sometimes the user has to manually place it somewhere.

In this case, a path to the DLL must be specified e.g. as a config option, as is the case for aptmotor, iXon897_ultra, and a few custom modules I have written myself.

Could this be handled more elegantly? Options I am considering are:

1. just ask the user to copy the DLL to C:/Windows/System32
2. specify a global qudi DLL path in the config file

Has anyone thought about this before?

[Neverhorst]

Yes, there was some thought put into this. However, DLL path resolution in windows is infamous and quite complex (see e.g. the official MSDN article about DLL search procedures).

I see a couple of problems setting rules about DLL paths in qudi:

• Device vendors install DLLs all over the file system. There is no single rule where to put them.
• Moving DLLs afterwards by hand can lead to unexpected behavior and is also quite a hurdle for most qudi users.
• DLLs can not be distributed by the qudi repositories because they are third party IP that is (in general) not for redistribution. So automatic integration into the qudi package hierarchy is impossible because every user needs to install the third party software (including the DLL) by himself.
• And finally, coming up with a custom set of rules for automatic DLL path resolution in qudi will in my opinion just add to the confusion. The ruleset from MS is already quite complex but at least it is widely known and documented.

So, considering the points above, I would propose the following course of action;

• In case the device vendor installer places the DLL in a way it can be found by the MS path search, there is no need for qudi to customize anything. ctypes could make use of MS mechanics and find the DLL without specifying an explicit path in the config.
• In case the device vendor installs the DLL in a random location that can not be resolved by the MS search algorithm, giving the path as ConfigOption seems the most general and transparent way.

Assuming I have not overlooked more cases, each hardware module can abide to one of the two options, depending on the vendor software.