Fast File Format causes application to ask for DDE.lsb

[Mads]

The enticing but undocumented "Fast File Format" option introduced in LabVIEW 2015 seems to break this and that...

Previously we discovered its effect on front panel behaviour. Today we discovered that it will break applications that employ DDE functionality (yes, it's old tech...but still has its use cases):

If you have an application that includes DDE VIs and check the Fast File Format checkbox the resulting application will show a Find-dialog upon startup asking you to locate a CIN: "DDE.lsb". The error occurs while loading DDE Master Control.vi.

Perhaps this error affects all code that has CIN nodes? Without the fast file format option checked everything works fine (including the DDE communication).

[AJost]

Thank you very much for reporting this bug and figuring out where the error messages come from, especially as someone might run into the same troubles and is still looking for a solution.

It really seems that Fast File Format is not working well with some of the features of Labview 

Andreas Jost

Applications Engineer

National Instruments

[dadreamer]

---

@Mads wrote:

Perhaps this error affects all code that has CIN nodes?

---

Yes, that's the case! I have just made sample CIN and built an exe w/ "Use fast file format" option. The application goes one of three ways:

- crashes immediatily (when it's on the Desktop);

- shows the dialog "Find the CIN named ..."; if I select the original *.lsb file, it successfully loads and works; if I don't, it says that "The VI is not executable. The full development version of LabVIEW is required to fix the errors" (when the app is in its own folder);

- shows the message "LabVIEW: Generic file I/O error. The file '' could not be loaded." and then the second message "The VI is not executable. [...]" (when the app is in C:\ root dir, in My Documents etc.)

I will try to suggest that the problem is related either to path building of final CIN library (*.lsb -> *.dll) or to the lack of the whole LVSB resource in exe's VIs. Well, I tried to check that but there seems to be some new LEIF resource instead of traditional ones.

[dadreamer]

The newest LabVIEW 2016 still has that bug not fixed. The behavior of the compiled EXE w/ CIN is the same as I have written above. I've also tried to check some details of this "Fast file format" option and noticed that it does modify final LVSB resource being built into the final EXE. For that I did two EXEs: one with "FFF" option enabled and one without it. Then I have extracted DLLs from both EXEs' resources and compared them in Total Commander tool. It shows many differences between original and "fast" CIN DLL. Finally the debugger shows that the crash happens in some new function of modified DLL, which was added there by "Fast file format" conversion process whatever it is.

So, for now there's the only way: not to use "Fast file format" option if your application contains CINs.

[rolfk]

---

@dadreamer wrote:

The newest LabVIEW 2016 still has that bug not fixed. The behavior of the compiled EXE w/ CIN is the same as I have written above. I've also tried to check some details of this "Fast file format" option and noticed that it does modify final LVSB resource being built into the final EXE. For that I did two EXEs: one with "FFF" option enabled and one without it. Then I have extracted DLLs from both EXEs' resources and compared them in Total Commander tool. It shows many differences between original and "fast" CIN DLL. Finally the debugger shows that the crash happens in some new function of modified DLL, which was added there by "Fast file format" conversion process whatever it is.

So, for now there's the only way: not to use "Fast file format" option if your application contains CINs.

---

It's very unlikely to be fixed. CINs are legacy technology for at least 10 years already. They are not supported on any 64 bit platform nor any other new platform introduced in the last 10 years (NI Linux RT for instance). LabVIEW has not been shipped with any tools to create CINs for many versions already.

CIN's are dead, only supported for compatibility but no active support. Same about the DDE functionality. It has been depreciated and hidden away many versions ago. All the active tools have been ported to use DLLs instad and only legacy technology like the DDE VIs still use a CIN.

So while you declare it a bug that the packed format doesn't support CIN resources, it is not going to be changed as the whole technology about CINs was basically depreciated many years ago already.

[dadreamer]

rolfk, generally I agree with you on that as I've been reading your words about CINs a million times here and there. But I do believe NI still maintains CINs because they still are not cut out from recent LabVIEW releases even they're not officially supported anymore. LabVIEW has had many internal changes over these years (say, switching to mgcore and frequent reworking of those manager functions) but CINs are still alive and do work correctly.

---

@rolfk wrote:

They are not supported on any 64 bit platform nor any other new platform introduced in the last 10 years (NI Linux RT for instance).

---

Again, not officially supported but do work on all LabVIEW 64-bit versions for Windows when there are no ready-to-use cintools for such 64-bit CINs. Having some deeper knowledge of CIN construction mechanism I have created a few just for fun: http://forums.ni.com/t5/Machine-Vision/LabVIEW-and-Halcon/m-p/3315500#M47866. They work without any error and aren't very different from their 32-bit counterparts.

---

@rolfk wrote:

 CIN's are dead, only supported for compatibility but no active support. Same about the DDE functionality. It has been depreciated and hidden away many versions ago. All the active tools have been ported to use DLLs instad and only legacy technology like the DDE VIs still use a CIN.

---

Why such old-fashioned VIs are not removed from LV? In my LV 2016 I see that DDE VIs are still there. That's not the only CIN out there. LabVIEW uses CIN to create data link to data base, for example (Tools -> Create Data Link) (look at C:\Program Files (x86)\National Instruments\LabVIEW 2016\project\database.llb\Prompt and Save UDL.vi file). I could give you some more examples of those hidden CINs in LV.

On the basis of my words I hope NI will take it into account and fix CIN branch. In fact, even I use CINs very rarely though. But as Mads already said CINs potentially may have their use cases. Moreover LabVIEW should have all its components working rightly if they exist there, or completely removed if they consider to be obsolete.

[rolfk]

---

@dadreamer wrote:

On the basis of my words I hope NI will take it into account and fix CIN branch. In fact, even I use CINs very rarely though. But as Mads already said CINs potentially may have their use cases. Moreover LabVIEW should have all its components working rightly if they exist there, or completely removed if they consider to be obsolete.

---

I would have to agree to disagree. You don't remove something simply because you declared it depreciated. Otherwise Windows would have long ago removed ActiveX, DDE, Active thit and Active that and many more things. They didn't becuase there are still software products developed somewhere in the 90ies actively used today. LabVIEW is in a similar boat.

CINs have many disadvantages and really no advantage anymore to other alternatives. That you need an extra external shared library I definitely wouldn't consider a disadvantage. It's a lot easier to manage the different platform dependant versions in external shared libraries than to have to maintain one copy of every VI that contains a CIN for every supported platform. And as soon as you have more than one external code function, the maintenance gets a real burdon as you end up with one VI per function and per platform. A shared library can contain all the functions your interface library needs, so you end up with one shared library per platform and one VI per function, which scales a lot better for maintainance.

Another reason why CINs are not really great anymore is that you limit yourself automatically to certain toolchains for each platform, with none of them being really multiplatform capable. If you want to use something else it can sometimes be done with lots of thinkering and a good chance to break at random points because of little changes to you system but I have more interesting things to do with my time than that.

While NI didn't seem to disable the CIN support in 64 bit Windows and maybe also NI Linux RT (it's after all a Linux version for most of it) they definitely do not test it anymore, and do not develop according 64 bit versions of the DDE CIN anymore.

And they do everything to discourage its use such as hiding the according functions from the palette and not shipping any cintools executable anymore. Removing may happen at some point but that will happen when someone determines that keeping the functionality working requires more work than removing it.

You may think that removing some funcitonality from a software is a simple step but the reality for a product like LabVIEW is a lot more complicated. It is often easier to leave the code in and just depreciated instead of janking it out althogether. Both because there may be other functions that actually still depend on part of the infrasturcture for this feature, but also all the little titdbits you mention that would either have to be yanked too or need an alternative to be developed. That makes the decision to remove such functionality pretty hard, and is why Microsoft still support technology that was introduced in Windows 3.0 and has been declared discontinued for a decade and more.

[Bob_Schor]

---

@dadreamer wrote:

The newest LabVIEW 2016 still has that bug not fixed. \

---

So I'm curious how you managed to get "the newest LabVIEW 2016" before NIWeek.  I assume you are not an NI employee, and if you were part of the Beta program, the Beta should have ended (which, in my experience, disables the Beta software sometime in July).

We have an Academic license, and I'm tasked with setting up a lab of Laptops for Biomedical Engineering for a September start.  We often don't get our (single) "Kit" until mid-September, and I've had "issues" with the downloads from NI.  I'd prefer starting with LabVIEW 2016, obviously ...

Bob Schor

[dadreamer]

rolfk, well, I got your point. So, I really don't think that CIN interface will be removed from LabVIEW in the future. There are tons of deprecated things in LabVIEW from the very first versions, which can still be pulled out from the attic. Often they don't work as they should. But they are visible and can be called some way. It's well known serpdrv, for instance, that Brian of R&D promised to remove from all future LabVIEWs but it's still alive and works (tested it on LV 2016 also). It's all Device Manager functions that still operate properly on 32-bit LabVIEWs (but not work on 64-bit). That's Handle Peek / Handle Poke / Size Handle VIs from 16-bit platforms that had to be erased starting from LV3. I guess, CINs face the same fate - to be hidden "zombies" in LV "forest".

OK, maybe such things as CINs are only of interest to software archeologists and oldfags like me... But I worry that they begin to not work properly. For now it's just "Fast file format" which I may use and may not. Things may become worse in the future. What to do if I or someone else will need to use that DDE library or some CIN specific (legacy) software that is not working anymore? I see the one and the only variant here - use of older LV versions where that functional is not vanished. A similar situation occurred once when external subroutines were axed. Many people then got into trouble with their applications. It would be fine if CINs will live a few more years. If they not... Well, it's sad but we'll let it go at that.

---

@rolfk wrote:

---

CINs have many disadvantages and really no advantage anymore to other alternatives. That you need an extra external shared library I definitely wouldn't consider a disadvantage. It's a lot easier to manage the different platform dependant versions in external shared libraries than to have to maintain one copy of every VI that contains a CIN for every supported platform. And as soon as you have more than one external code function, the maintenance gets a real burdon as you end up with one VI per function and per platform. A shared library can contain all the functions your interface library needs, so you end up with one shared library per platform and one VI per function, which scales a lot better for maintainance.

---

There's not so much reasons to create DLL with 1-2 simple functions and attach that library to the project. When talking about dozens of functions, then yes, there is a reason for it. What about platform independence... As I know for each platform there is specific library format and specific compiler (DLL for Windows, SO for Linux, Framework for Mac). For real independence you need to create all those libraries for each OS as for a CIN. In case of libraries LabVIEW just uses some additional asterisk magic that not applied for CINs. Not so much of a difference here. I agree with you that one CIN for one function is not comfortable. We can use some selector as input parameter, but that becomes not so easy to maintain the code as in DLL case.

What else to say here?.. If I had a good think of it I could find some "cosmetic" advantages of CINs over DLLs.

- CINs have more entry points than DLLs. We have three EPs in DLL: Reserve, Unreserve and Abort which correspond to CINInit, CINDispose and CINAbort of any CIN. Additionally CIN provides CINLoad, CINUnload and CINSave EPs. Practically I've never dealt with them, but in theory they *might* be of some use. And they were in the past when LV was giving real RsrcFile cookie to CINLoad / CINSave.

- There's no need to adjust any parameters of CIN: you just pass the wires to it, generate a C template and start the coding. In DLL case you need to set up a calling convention, specify correct function arguments, their order and return value. The parameters' data type is defined by the settings of CLFN. I know there's "Adapt To Type" setting, but it's not so transparent for users as in CIN case.

- This may seem strange but CIN may be easier to create than DLL. If you have already set up all IDE parameters for CIN toolchain you may copy-paste the whole C project, just altering CIN template only. CIN may be generated with common LV template but not DLL which need some more changes in its template to be successfully compiled.

In all other cases DLL is the preferable way of external code connection to LabVIEW. That's not so much yet to say about it. I'm sure these "cosmetic" pros even don't make anyone to think about them as DLLs are standard thing nowadays and is used everywhere.

[dadreamer]

---

@Bob_Schor wrote:

---

@dadreamer wrote:

The newest LabVIEW 2016 still has that bug not fixed. \

---

So I'm curious how you managed to get "the newest LabVIEW 2016" before NIWeek.  I assume you are not an NI employee, and if you were part of the Beta program, the Beta should have ended (which, in my experience, disables the Beta software sometime in July).

---

No, I'm not. I'm just a curious guy who went on their servers too early. I know that new LV version is being out on mid-July - August. So, I checked out and it's there. Now I have real entertainment of testing all those new features that NI did there.