Many SW vendors still keeps supporting the DDE interface, it would be nice to go with newer versions of LabVIEW but now we need to use 2024 Q1 which is the latest version with working DDE VIs. INI-file mods to support CodeInterfaceNodes not work.
2. The DDE library was implemented with CINs, which have recently been completed deprecated.
3. DDE was replaced with ActiveX, which is another tool Microsoft was been trying to deprecate because of .NET Framework and now .NET Core.
If we add in the EU CRA, DDE is a security risk that I doubt NI will want to carry around.
Considering I never heard of DDE until 10 minutes ago, I can only imagine this is a very niche use case. I would argue that NI should not be worried about this niche cases. This is where a good open source community can fill in the gaps NI cannot.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Good points that I already know and agree with but for those who still need this interface it would be helpful to have instructions how to fix the broken DDE VI library, replace CINs with CLFNs or some kind of working option to enable the old VI library as long as e.g. Microsoft supports it.
DDE was used a lot, but I haven't needed it for 20 years.
Maybe LabVIEW shouldn't natively support it. LabVIEW can't keep adding new things without every now and then obsoleting things.
That doesn't mean DDE shouldn't be used at all. It probably shouldn't, but reality is you sometimes interface with legacy software.
There's no reason DDE support can't be provided in a (3rd party? Open source?) library.
DDE is window message based and those messages should transfer between 32 and 64 bit applications. Being almost 40 years old, the protocol is pretty small and looks well specified. It will be messy since you'd probably need a windows message hook. I'd look at a .NET wrapper, but those are usually libraries, not assemblies.
I believe I'm not the only one who still miss the DDE library. There are reasons why it is required in my projects but won't go into details here, instead I would be happy to receive private any real suggestions for a possible e.g. 3rd party solutions.
Have you tried copy-pasting the LV24 dde.llb to a newer version? (From C:\Program Files (x86)\National Instruments\LabVIEW 2024\vi.lib\Platform\) I'd try but am stuck in LV24 for now.
AFAIK, The cin's make the code self contained.
CIN support is discontinued, I doubt they won't work at all. Maybe they don't though.
If the cin's break the code, I wander want will happen if you'd make a 2024 dll (or ppl?) with support for future versions and use that in newer versions.
Of course a) it won't be supported and b) this will stop working when 32 bit is discontinued (in a few years).
In the meanwhile there is a tiny, tiny change the DDE code is shared... ?
Well, the statement that many software vendors still support DDE is "slightly" over-exaggerated. If you talk about industrial automation applications and interfaces released 20 years ago and longer, then yes that is a valid statement. But recently released software applications with DDE support are few and very far between. Funnily, Windows Explorer is an application that still supports DDE, to implement the old Windows 3.1 File Manager functionality.
The DDE VIs will not work in the newest LabVIEW versions since NI has definitely and completely gutted the CIN support. It already didn't work on LabVIEW 64-bit since the CIN support was never really ported to 64-bit and LabVIEW for Windows 64-bit did not have any official support for CINs, as there were no tools to create the according CIN resource. Some of the code to load and execute CIN resources was still present in the 64-bit version of LabVIEW until around 2019, but since there were no tools to create such a CIN it was pretty much useless. Some curious person on lavag.org did investigate into creating 64-bit CINs and was successful with quite a bit of trickery and low level hacking but eventually accepted defeat when LabVIEW 2019 or thereabout simply gutted any CIN support in the 64-bit version.
The DDE functions were implemented somewhere around LabVIEW 3 or 4 and the person who did that has long been gone. Supposedly the code used to write that CIN has been lost, so just recompiling it was never an option and for a new development the DDE functionality was already considered a legacy technology more than 25 years ago.
The 32-bit DLL solution created in 2024 might work but only if you prevent that DLL in the build settings to load in newer LabVIEW runtimes.
The DDE functionality is in fact based on Windows messages send between applications. And there is an API around it in User32.dll. The DDE CIN did access the API since that was a better documented method to implement DDE functionality in a Windows application. In the current documentation in above link, those APIs are only documented in the context of the header file but not as official API anymore, but they still exist and probably will remain there until the universe collapses or Windows stops working, whatever is earlier.
Since the original code is supposedly lost, and considering the legacy state of this functionality - Microsoft really would love to gut it if they could - chances that NI will develop something to replace the CIN functionality is about 0.00000%. And while there has been some cries for it, nobody in the community so far has felt enough need to develop a replacement.
So yes it would be possible to interface to the Windows DDE API. Theoretically this could be even done directly with Call Library Nodes, but some of those APIs use relatively involved parameters that would be easier handled in C code, so an intermediate DLL would be better in the longer run. I have at some point considered writing such a thing. But not having any direct need for it, and the fact that DDE really is slooooooow - and did I already mention very legacy - I never could get myself to spend more time than to see what might be needed to do it.
