03-09-2020 08:53 AM
Hi,
I am in search of a publish-subscribe middleware that could be used for interprocess communication between different platforms. I have a PXIe realtime controller having Pharlap OS. Application software for the PXI will be developed using LabVIEW or LabWindows/CVI. This PXI would be connected to multiple PC's via LAN. PC runs custom app software developed usingc/c++. I would like to use a publish-subscribe middleware that would minimize the effort for the programmer in implementing a multi client communication architecture.
I stumbled across ZeroMQ and its LabVIEW toolkit labview-ZMQ
This seems to be a good choice for the type of application I am developing. I was wondering if ZMQ or its labview toolkit would support LabVIEW Pharlap Realtime on the PXI controller. Has anyone attempted this?
If that is not an option, can anyone suggest any other protocol/middleware that is of pub/sub type?
Regards
DJ
Solved! Go to Solution.
03-10-2020 05:27 AM - edited 03-10-2020 05:31 AM
While Pharlap is Windows binary compatible it isn't exactly Windows. That means you can theoretically use a Windows DLL and copy it to Pharlap ETS and it can work. If it does depends however on a number of things.
First the Pharlap ETS kernel only implements a subset of Win32 APIs. Notably it is at the state of about Windows NT4 and/or Windows 2000, with the exception of OLE functionality, ActiveX, Unicode support, and of course anything .Net based as that builds on top of all these technologies.
Any newer API that was introduced after Windows 2000 is almost certainly not available and a DLL trying to make use of one of these simply won't load on Pharlap ETS.
But that is not all to it. Microsoft Visual C programs are always compiled with a specific C Runtime Library that is Visual C version specific. On standard Windows those C Runtime Libraries are usually already installed but also can be downloaded and installed. But these standard C Runtime Libraries from Microsoft do like to make use of new APIs as soon as they are available so they won't run and not even install on Pharlap ETS.
NI has acquired a license from Microsoft to rebuild and redistribute some C Runtime libraries for their Pharlap ETS targets. The supported C Runtime Libraries that you can install in this way to a Pharlap ETS target are as follows:
MSVS 7.1 Visual Studio .Net 2003
MSVS 9.0 Visual Studio 2008
MSVS 10.0 Visual Studio 2010
In addition DLLs compiled with Visual Studio 6.0 will always load on Pharlap ETS if they don't use unsupported Win32 APIs themselves as Visual Studio 6.0 did not use a version specific C Runtime but the standard Windows MSVCRT.DLL C Runtime support.
If you can compile your DLL(s) in one of these 4 Visual Studio versions and it does not use Win32 APIs that are unsupported on Pharlap ETS, you can copy that DLL to your Pharlap ETS system and load and use it there with the same VIs that also work on Windows.
This most likely means that you will have to rebuild both the ZeroMQ library itself as well as the LabVIEW ZeroMQ specific wrapper with one of the above C compilers.
03-10-2020 05:43 AM
Thank you for the very detailed reply.
I understand the issue. Since ZMQ is available as open source, i can definitely try compiling them in VS 2010.
I tried the same with openSplice DDS but was unsuccessful.
@rolfk wrote:If you can compile your DLL(s) in one of these 4 Visual Studio versions and it does not use Win32 APIs that are unsupported on Pharlap ETS, you can copy that DLL to your Pharlap ETS system and load and use it there with the same VIs that also work on Windows.
Where can i get a list of unsupported Win32API functions in Pharlap?
Regards
Dj
03-10-2020 08:03 AM - edited 03-10-2020 08:04 AM
@djac91 wrote:Where can i get a list of unsupported Win32API functions in Pharlap?
Such a list would be an exercise in vain as the Windows API is a continuously moving target to track. Each new Windows version adds a bunch of new libraries and also new APIs to existing libraries. So a list of unsupported Win32 APIs would be a huge project with many different Windows versions and could never possibly be exhaustive.
The other way around is easier: Check here to find tools that you can run on your DLL to see if they link to unsupported APIs. There is a version for each LabVIEW version since the Pharlap ETS system installed on a target is specific to each LabVIEW version and there are minor differences in supported APIs in each version as NI does maintain and sometimes improve a function in their Pharlap ETS sources.
03-13-2020 02:32 AM
If i were to rebuild the source using microsoft visual studio ver 6, does the generated dll's will have any dependency based on the system on which it is being built? For example if i do the build using the same source and MSVC 6.0 on two pc's say windows 7 and windows 10, will there be a difference in the generated dll's?
03-13-2020 03:35 AM - edited 03-13-2020 03:39 AM
It shouldn’t unless the code itself references APIs not supported by Pharlap ETS. The chance for that is pretty high nowadays as it is very easy to use new APIs.
Another problem is that Visual C 6.0 doesn’t support the C99 standard at all as it was released before that standard was even talked about and Microsoft had for a long time a fairly bad record to track the C standards so even C90 wasn’t fully supported. While you can write code without C90 or C99 features there are a few features in there that are nowadays commonly used so there is a good chance that ZeroMQ is using them, as support for ancient C compilers only very seldomly is even at the horizon of most Open Source developers awareness.
Both issues may require you to make substantial edits to the source code and it is highly questionable that the project would accept patches for supporting such old C compilers as use of them is highly discouraged nowadays due to all kind of security concerns.
05-11-2020 06:57 PM
Hi djac91
Could you implement the solution that was proposal on this forum ?
I am in the same issue/path and I need to know if dll compilation if the only solution.
Thanks in advance.
Regards.