Shared library generator - The name of the ini file used by the library should be configurable

[alanturing]

This is a suggestion a bit technical and is posted here following the suggestion of the National Instruments support center. 

When building a shared library from a vi, the run time engine make use of a configuration file which has the following name: <name of the executable program which links in the DLL>.ini .

The fact that the name of this file is not configurable by the users is EXTREMELY annoying in my application (the LV DLL is a plug-in of third party software) because causes the corruption of the calling program configuration file.

It seems very easy to me solving this problem by making user-selectable the name of the ini file used by the DLL produced by LV. It also would improve the interoperability of LV with third party software.

I really hope to see this upgrade already in the next release of the software.

Thank you very much.

[AristosQueue (NI)]

Wouldn't that create a fairly high burden on users of the EXE if they had to remember which file to edit to change settings?

And what settings are you using where you want the EXE configured differently than the DLL?

What if you had two DLLs in the system and you tried to give them conflicting .ini settings (since many settings affect the entire EXE)?

Usually if something is going to be a shared component like that, the shared library would have some sort of Initialization.vi that the EXE would call in order to supply the configuration settings to the DLL, rather than the DLL using its own method for looking up configuration. I take it that isn't an option in your case because of the third-party framework?

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined. 

[alanturing]

Dear AristosQueue,

I am sorry to have completely missed your reply years ago. Here is my reply now that the request has been dismissed, for the records.

Let me restate the problem. I produce a DLL with LabView which is a plug-in of a third party software (it happens that the software is written in Fortran, however, who cares? It is an exe and I do not have the source code.) It happens that the Program make use of a configuration file called <name of the exe>.ini that is NOT a valid ini file (the extesion is evidently accidental). When the prgrams loads my LabView plugin, the labview runtime get access to the same ini file and tries to modify it (as if it were an regular INI file). Obviously, that results in the corruption of the file. Note that even if I had the source code of the program, I would not dig into it  to cange things to comply with LV conventions. All I want and need to do is running the program with the LV plugin, which is a DLL with a single function with a certain signature. That's it. I think it should be working seamlessly (BTW you can do plugins for such program in Fortran, C, C++, Python, Matlab and even Haskell).

Regarding your questions:

1) What burden are you talking about? By default the current naming convention could be used so 99.99% of the users would barely notice the difference. The rest of the users would be happy to configure the name of the INI file of the DLL to sove a problem like mine.

2) I have absolutely no need of the INI created by LV. It just annoys me. All I want is that the INI file of the calling program remains intact. Also, it seems to me pretty normal that the two things are different. For example in the program INI one could store configuration of the main program. In the DLL INI one could store the configuration of the plug-in. Main prorgam and plug-in are different things so they require different options.

3)  I do not understand this point. Can you make a couple of example of DLL and DLL configuration that affect the calling exe not via the DLL code itself?

4)  Exactly. The calling program has no such mechanism, because the DLL has nothing to configure, it consists of just a single function.

Sincerely,

[AristosQueue (NI)]

Dear alanturing,

I believe you when you tell me you're seeing this issue... in the comments below, I explain why I cannot replicate your claim and why I don't think what you're claiming is quite accurate. I am NOT trying to dismiss your claim... I assume that I have misunderstood something about your scenario... please read through and then explain to me what I've misunderstood.

First: As far as I can tell [on MS Windows... are you maybe on another OS?], our EXEs and DLLs never write to the config file, they only read from it, so I am not sure how your EXE's ini file is getting corrupted, unless you've put code in your DLL to explicitly save settings. If that's the case, you can use the config VIs to write to any file you choose. (Use vi.lib\Utility\config.llb\Open Config Data.vi and the related VIs found in the palettes). I've tried several variations -- an EXE's ini file is not modified by running a LV-built EXE nor an EXE calling a LV-built DLL, so far as I can tell. Are you sure it is our built in code that is causing the problem?

As for the rest of your idea...

> What burden are you talking about?

You build a DLL "X.DLL".

I write a DLL "Y.DLL".

A third party (let's call her Rachel to avoid confusion) creates "Z.EXE" which uses both of our DLLs.

If every DLL starts using different configuration files, how does a user know which config file to use for a given EXE? The point of a config file is that it is the one place where all the tokens for a given executable are stored.

That's the burden that I'm talking about -- the EXE author and the EXE user having to figuring out the file needs of your particular DLL. In particular, from the EXE user's perspective, the DLL should be a private implementation detail. Having it expose its private needs in terms of requiring a different config file is not generally a good idea.

> 2) I have absolutely no need of the INI created by LV. It just annoys me. All I want is that the INI file

> of the calling program remains intact. Also, it seems to me pretty normal that the two things are

> different. For example in the program INI one could store configuration of the main program. In the

> DLL INI one could store the configuration of the plug-in. Main prorgam and plug-in are different things

> so they require different options.

Ah. I see where the confusion is coming from.

From the point of view of a user of the EXE, no, the two things are not different. Whether some functionality of the EXE is packaged in the DLL or not makes no difference to the user of an EXE. The configuration of the EXE is supposed to be all in one place -- in the ini file. This is why ini files have sections -- so that private details inside the various components can be segregated but still be in the same file.

> > What if you had two DLLs in the system and you tried to give them

> > conflicting .ini settings (since many settings affect the entire EXE)? 

> 3)  I do not understand this point. Can you make a couple of example of DLL and

> DLL configuration that affect the calling exe not via the DLL code itself?

One config setting for example:

       server.vi.callsEnabled=True

Either VI Server is enabled for the process or it is not. If the port is open and listening then it is open for the whole process, not for a single DLL in that process -- if you want that, you have to build them as separate processes. But when a LV-built DLL loads, it needs to know if that access is enabled so it knows whether to load that part of itself. So all the DLLs pull from the same config file to get such information.

> 4)  Exactly. The calling program has no such mechanism, because the DLL has

> nothing to configure, it consists of just a single function.

Then as far as I can see, there shouldn't be a problem. The config tokens that LV looks for are obtained by reading the config file, but they never write to the config file. If you have your own configuration information, you can write it to any file you choose using the Config VIs that I mentioned above.

I welcome your feedback if you can show me what I've missed.

-- AQ

PS: Interesting name choice, btw, alanturing. If this is really his ghost I'm typing with, I'm honored. 😉

[alanturing]

Dear AristotsQueues,

here is my original request, posted apparently in the wrong place. In my case, on windows 7 with LV 2010, the ini file of the calling program was modified with the introduction of the line [LVFFRT] at the beginning and an extra return in the middle. That was not coming from the main program. If it wasn't LV alone, surely was a bad interaction between the two main program and the LV-produced DLL.

As the ini file was re-created from scratch by the main program if not existing when needed, a collabrator of mine wrote a workaround based on a service deleting the file every minute. This allowed us to keep working on our project.

Now, you don't need to be the spirit of Alan Turing to find this workaround totally disturbing. 😉  In the end however, as the work was being done, I stopped thinking about this problem. Probably, that's why I have missed your reply years ago. 

Having said this, If you tried to reproduce the problem and you couldn't, it could well be that it has been solved in newer version of LV. I am happy to know it.

Regarding your comments:

1) I understand now how the INI files SHOULD be used in windows. I think it is reasonable. Evidently, the program I am using is not a well behaved windows application caring much of using the INI file in the proper way. I cannot change that. Despite this, I think this is not enough to ascribe to application all the responsibility for not being integrable with LV-produced code.

2) Also I can agree with you about the library not requiring a special configuration file. In fact I never needed it nor desired it. It was LV somehow messing up the ini file of the main program, not me.

3) I understand your example of configuration. Two different DLL created by LV could have two different INI files with inconsistent server configurations.

To conclude, I think that the only point wrong in your post is the assumption that LV does not modify the INI file of the calling executable. Maybe not in your case, but it was so on my laptop (and the laptop of my collaborator) when I raised the point. I should check if now the problem is disappeared, but in the meanwhile we gave up implementing plug-in for that program in LV. I have understood that LV is not as much as an appropriate language for such jobs. 

Sincerely,

[AristosQueue (NI)]

> To conclude, I think that the only point wrong in your post is the

> assumption that LV does not modify the INI file of the calling executable.

I did actually try to reproduce the bug, but I could not. I was testing with LV 2015. If you can reproduce it in any version, you can share the reproducing case with one of our AEs on the main forums and they can check if it is fixed in the latest version. But it sounds like you encountered a bug as far as I can tell, one that may be fixed.

> I have understood that LV is not as much as an appropriate language for such jobs. 

I have seen LV used successfully as a plug-in language for several large projects both inside NI and among our customers. You encountered one bug there; I don't think that invalidates LV for use in similar situations (situations where the config file isn't malformed). 🙂

Like I said -- we might have a bug. If you can reproduce it, please post it to the forums for an AE to diagnose.