devices.util.load_lib: unintuitive load order

[PoroCYon]

On Windows, I noticed that devices.utils.load_lib.load_lib has an unintuitive order to search for DLLs: the last DLL found is actually the one used. This means the effective order is:

1. %PATH%, C:\Windows\System32\ etc.
2. Application-specific install directories (in C:\Program Files\ etc.)
3. The custom directory specified in pylablib.par

This has two issues:

• It is the opposite order of what I expected
  • This led to a fun afternoon of debugging after updating the UC480 drivers and noticing things stopped working. Turns out, pylablib was still using an old version of the DLL in System32, while the new version was only in C:\Program Files\
• It opens file descriptors for and loads all available DLLs but only ends up using one.

I don't know if this is the intended behavior, but even if it is, this should probably be documented in a better way. For example, the generic docs leave the actual order very vague, and only say that System32 will be searched in "many cases" while also saying the "requirements are described in detail for the specific devices".

(FWIW, I'm willing to open another PR if you have a clear vision of how it should work.)

[AlexShkarin]

I'm sorry to hear that it didn't work properly. Could you describe in a bit more detail how you used this method, what was the outcome, and what did you expect to happen? I have tried it just now, and the order seems to be as would normally be expected: first the pll.par["devices/dlls/uc480"] value, then Program Files/Thorlabs/Scientific Imaging/ThorCam, then "generic" path (i.e., loading it just by the name, which uses PATH system variable). Perhaps, there could have been some path in PATH which interfered with the loading order in your case?

The part that you have pointed out indeed shows that it loads all the libraries from the paths list and only returns the last one, but this list only includes the target path and the depends DLLs. The idea here was to pre-load some DLLs, so that the target one (loaded last) would already have access to the prerequisite DLLs by the time it loads. In certain cases that seems to be the only reliable way to load a DLL which depends on other DLLs.

What is confusing in the documentation is what happens when both name and location are lists, since both of these allow to search for different libraries in different locations, and the method cycles over all possible combinations according to the check_order parameter. In addition, whenever the DLL can not be loaded, it is silently skipped and the next possible location is tried; this is the desirable behavior in most cases (as this usually just means that the DLL is absent and one needs to check in the next place), but it might also mask other problems with loading (e.g., if it depends on some other libraries which are not present, or if the bitness is off) and obscure which exact location was successful, which makes debugging process more complicated. For this, I will most likely add some kind of verbose parameter to pll.par in the next release to allow explicit indication of the paths tried and the exact problems with loading.

[PoroCYon]

I'm sorry to hear that it didn't work properly. Could you describe in a bit more detail how you used this method, what was the outcome, and what did you expect to happen? I have tried it just now, and the order seems to be as would normally be expected: first the pll.par["devices/dlls/uc480"] value, then Program Files/Thorlabs/Scientific Imaging/ThorCam, then "generic" path (i.e., loading it just by the name, which uses PATH system variable). Perhaps, there could have been some path in PATH which interfered with the loading order in your case?

I basically used an editable install (pip install -e) of pylablib and sprinkled the code with print() statements, and this showed it was loading from System32 each time.

Unfortunately I didn't check the contents of PATH, and that was on a work lab machine I can't really run tests on in the next few days (holiday thanks to the lasting legacy of catholicism). Plus, we had to install a different OS/version on this machine to try to work around some annoying bugs with its USB 3.0 controller, so I don't know if this exact behavior can be recreated...

[mashamellow]

I believe I encountered this issue as well. When attempting to import "Newport", ctypes failed to load ftd2xx.dll. I know the file is present in C:\Program Files\ but for whatever reason it was not loaded. I had to direct it to load the ftd2xx.dll file I placed in the directory by using the os.add_dll_directory() function:

libpath = Path("<path to directory with ftd2xx.dll>")
os.add_dll_directory(libpath)

pyLabLib was also attempting to load the 32 bit ftdxx.dll file, but returned an error. I had to re-name the ftd2xx64.dll file to ftd2xx.dll for it to work