LabWindows/CVI
CVI/2017 new installer issues (customResource0009.dll not found, but is there) - suddenly showing up on LTSC and Windows Arm.
You can have zig runtime installations next to each other. And they don't automatically get removed and are usually not even listed itself, since they can and usually are a dependency of some other compiled LabWindows app. That could be anything you installed and was at some point created with LabWindows. And that developer might have gone to great lengths to try to hide that they used LabWindows for it.
There were for instance NI Max versions that included test panels that were in fact created as LabVIEW or LabWindows executables. And somewhere around 2020/2021 the according Installer Framework of NI had a change that simply prevents creating installers that can be still installed on Windows 7 and 32-bit Windows OSes. It doesn't matter that you use LabWindows 2017, if any NI software from 2021 or later is installed, the according framework is updated and your LabWindows Installer Creater lost its ability to create Windows 7 or older compatible Installers. Even just upgrading NI Package Manager to a version newer than that is enough. And in order to install NI software of a certain version your NI Package Manager has to be that version or newer.
This time around, it is failing on a different file, but that file sure seems to be there. Am I just visually impaired right now???
Those tmp files are actually DLLs too. It was mainly a LabVIEW thing back in those days, with so called Code Interface Nodes (CINs) that were in fact also just DLLs but embedded in a VI. In order to be able to load and execute them LabVIEW would extract them and copy them as a tmp file to the temporary directory and load them from there.
Why LabWindows/CVI 2017 would use that mechanism is however a miracle. CINs have been declared depreciated in LabVIEW since version 8.0 which was released around 2006 or so. And the latest LabVIEW versions don't even support it anymore.
Since it is a DLL, it has of course dependencies and if it is a historical CIN based solution, it was created with an ancient Visual C compiler. That ancient Visual C compiler has ancient C runtime library dependencies that you would be very hard pressured to find on a Windows 10 system. In fact there is a very serious chance that the according C runtime can't even be installed on the latest Windows systems, definitely if it is underneath ARM based. Windows does not distinguish between a DLL not being present on the system or it not being able to load the DLL because of missing dependencies. The according LoadLibrary() call simply fails with a File Not Found error. So yes the DLL file can be there but Windows still will fail to load it if a dependency such as a C runtime library (in the exactly correct version until Visual Studio 2015) is installed on the system. In LabVIEW they did at some point try to distinguish between these two cases by checking after such an error, if the actual DLL file is present or not as a file, but that was at some point apparently removed. Likely because it was not fool proof either and therefore to remove obscure, not always well working code paths.
Trying to run any NI for Windows software on an ARM system always has been an unsupported feature until today. It's possible that it can be made to work, with the exactly right moon phase, and your favorite magical incantation, but it is not designed for that and was never tested.
