LabVIEW
ADVAPI32.DLL
I'm very sorry, but etsapi.dll is a DLL that comes either with the Ardence Pharlap system or has been provided by NI. So the issue about the DLL not being supported on the real time system is IMO simply moot.
etsapi.dll was used in LabVIEW 7.1 by some functions in vi.lib/addons/vi.lib/addons/rt/ETS/rtutility.llb (and I do believe by the Real-Time System Manager) and the functions in that DLL seem to be documented by Ardence/Pharlap in their SDK. In LabVIEW RT 8.2 some of the functions in the rtutility.llb have disapeared so it could be that the poster was using one of them and really pulled the stub DLL from RT 7.1 in, while the DLL distributed on an 8.x RT Target does not support the same functions.
Rolf Kalbermatter
parthabe wrote:Hi All,
Sorry for hijacking the thread to some other DLL, but I feel this is also related to the topic under discusssion...
Can anybody please tell me whether a DLL built using FORTRAN will be compatible with LV RT 8.6?
I have not tried this, but customer wants to make sure thatthere wont be any problem after migration code to LV from some other language. Thats why...
I haven't seen this message and it is a bit old now, but the recommendation by Jon S is probably the best. Quite likely the Fortran DLL will reference some runtime library which might relay on specific Microsoft Visual C runtimes somehow and there is a good chance that this could fail.
Also note that Windows DLLs will only be potentially compatible with Pharlap based RT system. cRIO and some other newer systems are all VxWorks based and they will not be able to use any DLL at all but have their own shared library image format which needs to be created using the according VxWorks toolchain (a gcc based system).
Rolf Kalbermatter
If the DLL Checker for your LabVIEW version reports an error this means you usually can't make the DLL work under Pharlap ETS without source code or linker modifications to the DLL itself. Without access to the source code this is usually impossible.
In your specific case it could be that your DLL depends on Fortran runtime library functions, and theoretically it may be possible to copy them manually to the Pharlap system. However if those runtime libraries are fairly recent, they most likely make use of Windows runtime APIs that are not present on the Pharlap ETS system either.
Another option might be to select in your Fortran project to link all runtime libraries statically into your DLL instead of relaying on them being present on the host system. But again, these runtime libraries may make use of Windows APIs, that are not present under Pharlap ETS.
imagehlp.dll is a Windows DLL and you can't replace the one on the Pharlap ETS system with one from your Windows system without catastrophic consequences to your RT OS. and it seems it is the actual cuplrit for the bad imports. Without the list of actual bad imports in the second tab it is impossible to determine if that is the only problem.
Also the stubs could be also a problem, eventhough they don't prevent the DLL(s) from loading. If your DLL ever calls a function that calls such a stub, it could result in a runtime error since the expected functionality is not performed.
