LabVIEW
Pharlap ETS DLL and Driver Questions
Solved!
Which version of LabVIEW? If you use a recent version you can use Visual C 6.0 (works always as that was the last Visual C version that did not have version specific runtime libraries but directly interfaced to the standard Windows C runtime API).
Other versions supported are
MSVS 7.1 (Visual Studio 2003)
MSVS 9.0 (Visual Studio 2008)
MSVS 10.0 (Visual Studio 2010)
The reason that you can't just go and use any Visual Studio version is that you can not install the redistributable C runtime that comes with Visual Studio onto Pharlap. The Pharlap Windows API is at about the level of Windows 2000, exclusive features that make little sense on an embedded realtime system such as user management, and access rights based on that. Also no .Net or ActiveX is present.
But a DLL created with Visual Studio is heavily dependent on the matching MSVCRxxx.DLL. So NI licensed the C runtime source code from Microsoft and ported it to the Pharlap system for the Visual Studio versions they decided to use for Pharlap development (They also need to compile the LabVEW realtime runtime system to run on Pharlap and since the Windows version is compiled with Visual Studio it is easiest to use the same compiler for the Pharlap version).
Above mentioned versions are the versions that NI has standardized on in subsequent LabVIEW realtime versions and ported the MS C runtime library to. While it would be of course nice if they supported all Visual Studio versions, that is not really an option. Creating and maintaining a port of the Microsoft Visual C runtime library is a major investment in time for development and even more so testing, so they limited it to the versions they needed as new important features got supported in the Visual C compiler. Visual Studio 2010 seems to be more than enough for even the most demanding features, which is not so surprising. C and C++ hasn't changed much with the exception of new features from the newer C11 and such versions but those are mostly academic, syntactic sugar or template related (shudder). Newer Visual Studio versions may be necessary if you want to use the newest .Net version but since .Net is not an option on Pharlap anyways, why bother!
Other compilers like MinGW or similar are unfortunately even more complicated to get to properly run on Pharlap as their C runtime library has similar problems as the Microsoft ones. You can't simply install it on Pharlap and porting a C runtime library to another target is not trivial.
As to Winsock support, yes Pharlap has a Winsock compatible implementation but if that supports IPv6 I wouldn't be able to confirm.
Correction: This link says explicitedly that there is no IPv6 support on realtime controllers that use Pharlap or VxWorks.
Well the problem is that any library that requires a newer compiler has almost certainly little chances to run on Pharlap ETS anyhow. If a newer compiler is used that usually also means that new Windows features are used. Any API introduced after Windows NT 4 is almost certainly not available on Pharlap ETS in any way.
And that is not something NI can change. Pharlap ETS is an outdated platform by nowadays means and even Interval Zero doesn't support it beyond maintenance mode. The only way NI is able to really fix that with reasonable effort is by moving their VXI controllers to NI Linux Realtime too.
@Krid wrote:
Most features introduced in C++11 should not require new operating system API calls. It's just that the VC++ versions that (partly) support C++11 also make unsupported API calls (but for different reasons, not to implement the C++11 features). In other words, it would be possible to write a C++11 compatible compiler that targets the VC++ 2010 CRT (or even older).
Well, NI does sell LabWindows/CVI but I'm positively sure they do not intend to replace the Visual C compiler. What they rather did in the past is create a VC CRT library that could load and run on Pharlap, using the VC CRT source code. While it's not exactly rocket science to do that (Visual C does come with that source code) it's fairly tedious and encumbered with license questions, since Microsoft does not deliver that code with any rights for you to use it, other than for debugging your application.
So NI had to license it from Microsoft in order to be able to distribute the CRT for Pharlap for the VC versions they support. And porting the code to Pharlap is most likely not even the most difficult and time consuming part. Testing and validating it is likely a much more time consuming work.
I'm aware that C11 has little to do with the underlaying OS but only with the actual compiler. However getting support for a certain feature in VC means you have to go with the VC version that supports it and believe me, trying to convince a VC version to link to a different CRT version than the one that it comes with it is an almost impossible adventure. I tried at some point to make a shim layer that replaces the VC CRT library by directly interfacing to the standard Windows MSVCRT.DLL. Getting code to link with such a library instead of the standard CRT library seems even with lots of low level mockery almost impossible.
