Hi, I have recently changed to Visual Studio 2010 and Windows 7 64bit.
I have an existing RT desktop system running RT 2009. This system calls a DLL that I previously built using Windows XP and Visual Studio .net 2003.
Since I recompiled the DLL I get an error 7 file not found error when I call the DLL from RT, even though I simply replaced the old DLL with the new one in the filesystem thus the path has not changed.
I also noticed the message on the monitor connected to the RT system when it boots up:
error loading 'achieveworldpeace.dll': Missing export 'DecodePointer' from 'Kernel32.dll'.
Any ideas on this problem? Maybe it is as simple as a switch in the compiler?
Solved! Go to Solution.
I'm not sure it is a simple switch in the project settings in Visual C. The problem clearly is in the standard C runtime library that gets linked into your DLL and that references Windows exports that are not available on the RT system. Remember that the RT system is a limited Win32 API emulation.
I usually avoid these problems by using Visual C 6 to create DLLs for LabVIEW projects. Those standard C runtimes libraries are sure to not reference newer Windows API exports since they supported running even under Win95. So unless your code explicitedly references unsupported RT APIs you wouldn't have problems. If you don't use standard C File IO functions and memory management functions in your DLL, you could also try to link the C runtime libraries statically into your DLL, or vice versa depending what you did now. It may or may not work. Otherwise there is not much else but using an older Visual Studio version.
Thanks Rolf, I've gone back to my earlier version of Visual Studio .net 2003 and all is well again.
I will investigate this further when I get the opportunity (i.e. never). When Visual Studio 2010 converted the 2003 project to 2010 it might have added dependencies that the original did not have. I will start a blank project in VS 2010 with a single .c and .h and a dummy DLL function and work my way back to the something more substantial.
Will post here again when I have made progress, but for now I will continue with 2003.
Most likely it's simply the version of C runtime library Visual C links with. This is whatever is the version that comes with the actual Visual C compiler. Even if you don't call any C runtime function yourself the DLL startup code implicitedly linked in will always pull in some C runtime functions. And that startup code is compiler version specific. One might feel some conspiration here that Microsoft is trying to force people to use new versions of the OS , but the truth is most likely they just didn't think about this. Somewhere it should be possible to specify in the linker options to use different startup link symbols but I never ventured into that, since I had my old and trusty Visual C 6 installation available, and unless you want to develop .Net and Silverlight, there is no real need to abandon that.
Yes I'm sure there must be a way to use the latest Visual Studio as I cannot imaging all the NI programmers who create the DLL's that implement the RT system are using Visual Studio 6!
But as I said above I will continue with 2003 and experiment with 2010 on the side. If anyone has a quickfix (i.e. linker options to use) please post it here.
By the way it isn't completely straight forward to run Visual Studio 2003 on Win7 64bit. There are several compatibility issues, noteable if you try to compile your previously flawless DLL project using XP SP3 as the compatibility mode OS, you will see the error fatal error C1033: cannot open program database. The trick is to run Visual Studio using Vista SP2 as the compatibilty mode operating system. Even though there then still seems to be some issues with the way the IDE displays, at least you can modify and build your DLL.
I hope this saves someone a couple of minutes of frustration.
The C runtime DLL for Visual Studio 2010, msvcr100.dll, definitely imports DecodePointer and EncodePointer from kernel32.dll. (Try opening it in Dependency Walker, or look at the C runtime source that is installed in the VC\crt\src directory.) Even if you statically link against the C runtime, I doubt that you're going to be able to avoid this without switching to a different C runtime library entirely.
However, Visual Studio 6.0 and .NET 2003 (MSVC 7.1) aren't your only options. You can use Visual Studio 2008 (MSVC 9.0) if you select "Microsoft Visual Studio 2008 Runtime Support" when installing software to your RT target.
This KB contains a DLL checker program that you can use to verify that the entrypoints used by your DLLs are supported and not unexported or stubbed (non-functional): How Can I Verify that My DLL is Executable in LabVIEW Real-Time? If you're deploying any third-party DLLs that didn't ship with LabVIEW RT (msvcr100.dll, for example), you should point the DLL checker at those too.
Thanks Brad this helps a lot. After reading a couple of the links in the KB you mentioned I was considering using LabWindows/CVI to compile the DLL, as this would allow remote debugging of the DLL while it executes on the RT target it seems. But am I correct in understanding that this only supports C and not C++?
I'll install MSVC 9.0 as you suggest and also ask our developers to build using this version if they plan on upgrading from XP to Win7.
Yes, CVI supports C but not C++. Also, it uses a different debug symbol format than Visual Studio, so source-level debugging would require rebuilding your code with CVI.
Aside: I use Visual Studio .NET 2003 on Windows 7 in my day-to-day work and I haven't run into any of the compatibility issues you've mentioned, but that's probably because I only use the command line compiler and linker, not the IDE. When I need to use a debugger, I use either Visual Studio 2008 or WinDbg, both of which can read the debug symbols from Visual Studio .NET 2003.
Thanks Brad, so far I seem to be able to do what I want to do using VS 2003 (Including the IDE), Win7 64bit and Vista SP2 compatibility (and LabVIEW RT 2010).
I've also built a Microsoft Virtual PC that hosts XP SP3 and this of course prevents any incompatibilities, but unfortunately I haven't figured out how to run this Virtual PC and make it use two monitors. Using one monitor alone for development is not ideal. So for now I am living with the odd VS 2003 IDE quirk.