LabVIEW
Pharlap ETS DLL and Driver Questions
Solved!
@Krid wrote:
I think what you say is right and the situation is quite difficult for NI. But this topic is nothing new and NI had many years to work on a solution. Some years ago, we already had the problem that we couldn’t generate Simulink models for PXI because, at the time, PXI supported only VS2008 and Simulink no longer supported VS2008 because it was too old. Back then our NI sales representative told us that they learned from this mess and that it won’t happen again. Then they added support for VS2010 to PXI, which only delays the problem but doesn’t solve it. What I see now is basically the same problem again, just with VS2010 instead of VS2008.
Well the problem here really is that in everyday computers anything older than a year or two is nowadays quickly termed obsolete and discontinued. But embedded control is another story. We expect the hardware (and software) to run even in 10 years from now and to be able to get support for that. There is a solution for that: In controlled industries like atomic plants and the like there are very specific hardware and software solutions that come with a guarantee to be supported even in 25 years from now (and an according hefty price tag where one additional 0 at the end is not enough in comparison to more mainstream hardware and software).
It's not only that you can't rely on software like Windows for such things but it goes much much further than that. Even the used hardware chips are a challenge with chips getting regularly discontinued without a drop in replacement available anywhere. Microsoft basically discontinues support for Visual C more or less after a second new versions has been released. This means currently not much more than 2 years.
You can also use a new compiler like VS2015 and then replace the incompatible API calls by linking to stub-functions instead. I actually did that for a few functions but eventually stopped doing this. It doesn’t feel right to spend a lot of money on these products and then being forced to use some dirty hacks to get it to work.
I'm not quite sure what you are saying here. If it is about using older Windows API calls in order to make the software compatible with older versions rather than using always the latest and greatest API I do that regularly. I even go as far as real dynamic linking to APIs, by trying to load an API explicitly and if that fails, falling back to an older API that might have less functionality but still does the basic job.
What I was refering to however was to not make a DLL or EXE dependent on MSVCRT70.DLL for instance, but instead link to MSVCRT.DLL as was done in Visual C 6.0. That is an almost impossible adventure even if you create your own CRT library since the linking dependencies from autogenerated startup stubs are so deeply intertwined in the actual linker and compiler that it is impossible to remove that without replacing the actual startup stub completely with your own assembly coded version and I'm not quite masochistic enough to try to attempt that.
