Mechanics of .dll loading

Development Labview
1

Hi all, I’m getting onboard. Basically all I’ll need to do in the near future amounts to interfacing with an existing tango server, but since I’m at it I’d like to get some insights and possibly contribute. I’m not yet deep enough into it yet for offering some code overhaul; there are aspects of the labview binding though that I feel like that could improved, at first gut feeling.

I have a couple of questions, I’m splitting them in different threads for good order.

First one, windows only: I noticed launcher\windows\start-labview.bat, required otherwise the CLN is not able to load vis\tango_binding.dll. I suppose that this is because further dependencies to the dlls in runtime. However, is it the right way to proceed? What exactly searches for what? Could the dll just all sit in some support directory? How to proceed with projects, and building standalone executables?

2

Hi,

My name is Nicolas Leclercq and I’m the author and maintainer of the Tango binding.

there are aspects of the labview binding though that I feel like that could improved, at first gut feeling.
That’s a quite subjective and very vague remark. What you are talking about? The VI side or the C++ side? Please be a bit more factual. This binding works like a charm for 10 years now. It’s known to be very stable and fast. Moreover, it now allow to write a full Tango device in Labview which is a quite advance and tricky stuff to implement. Please, dive a bit more into the code before posting such a ‘first gut feeling’. That said, feel free to submit a PR on github. I’ll be happy to review it.

launcher\windows\start-labview.bat…
The starter script is provided as an example to demonstrate how the runtime env. must be setup in order to load the binding and its dependencies properly. We have plenty of standalone executables running in our control room (mainly on linux) and each one is launched by a dedicated script. Our operators develop the applications and provide the associated launchers. Simple and efficient - cause it allows to deal with multiple versions of labview, the binding and tango.

3

The VI side or the C++ side? Please be a bit more factual.

Ok - with no intention of being polemic, sorry if I sounded so.

I have only looked cursively at the LV code proper. I haven’t looked at the c++ code, on which I’m not competent at all. I acknowledge that it may well be the substantial part of this package, and don’t mean to slander it in any way. And agree on the hard need for stability and backcompatibility of the code.

My general remarks on the code as it looks are:

Initially I tested the packaged versions downloaded from http://tango-controls.readthedocs.io/en/latest/tools-and-extensions/bindings/labVIEW.html. I have some issues with them vs. what I find on github:

The github snaphot differs from the packaged version of labview-binding in that llbs don’t contain lvlibs

The github snapshot contains .mnu palette files, the package not.

The snapshot Makefile suggests a canonical installation directory, the package not.

Storing llb in a SSC is BAD, because it is not granular at all. Should definitely use compiled code-removed single VIs.

Many VIs have the same, non eloquent icon.

BDs need cleanup: non straight wires, not typedefd enums, unnecessary sequences, frames hiding wires (in the very little I have looked at).

I suspect (but so far just suspect) that the code of polymorphic VIs could be refactored, in a way that it is easier to maintain. Less repeated cases, perhaps merge VIs which provide compatible outputs. Bringing it very far, perhaps .vim could be used - but I agree that since .vim have been disclosed only in LV2016 (though being present much earlier), backcompatibility is at stake.

4

the runtime env. must be setup in order to load the binding and its dependencies properly

In my style of building executables, I would dump all the dynamic libraries in a single application support library, and I would include them in the labview project tree. I think that this eases the build of standalone installers (in the LV application builder sense). Here I think that the mechanism doesn’t work, maybe because tango_bindings.* is instructed to search for its dependency only using the PATH (is it so?). Am I wrong?

5

Once again, you’re right the Vi part of the binding could have been better written.
I’m not a labview expert and absolutely don’t want to become one. The fact is that this binding works perfectly and all you’re are proposing is - from the user point of view - purely cosmetic. Moreover, you’re the first in 10 years complaining about such minor imperfections. Please, start by using this binding then we can talk.

BTW, I suggest you rewrite the Vi part of the binding maintaining full backward compatibility.
Let me known when you’re done.

6

maybe because tango_bindings.* is instructed to search for its dependency only using the PATH (is it so?). Am I wrong?
Please, recompile the source code providing any linker options you want. FYI, the tango_bindings.* (.dll in your case) use the standard Windows PATH method to search for its dependencies.

7

[quote=“nleclercq”]> maybe because tango_bindings.* is instructed to search for its dependency only using the PATH (is it so?). Am I wrong?
Please, recompile the source code providing any linker options you want. FYI, the tango_bindings.* (.dll in your case) use the standard Windows PATH method to search for its dependencies.
[/quote]
Once I’ll be ever able to build. My bad in expecting it to work the LV way? I’m really not an expert here, may be off target.

8

I see… I just had a look to the “LV way”. Ok, that’s the way labview searches for a dll when the dll is installed the labview way. My advice would be to write a ‘labview way’ installer to copy everything at the ‘labview right place’. Contributions are always welcome.

FYI:

  1. we don’t use the ‘labview way’ cause it’s not flexible in term of deployment and maintenance. We, for instance, have to share a given version of the binding among several versions of labview. We clearly prefer to launch LabVIEW (or any standalone app it generates) using a dedicated launcher (i.e. a very simple script setting up the runtime env. be launching the actual application).

  2. I can’t provide a binary distribution for every single labview/windows/msvc combination. Recompiling the binding is trivial as far as the provided runtime (binaries) is compatible with your env. Please, see How to build on Windows using Microsoft Visual C++ for details.

9

Forgot to mention. The right link to the latest version of the binding is the git repo. I don’t maintain [url= http://tango-controls.readthedocs.io/en/latest/tools-and-extensions/bindings/labVIEW.html]that one[/url] and I even don’t know who created it. Anyway, it should redirect the reader to the git repo.