LabWindows/CVI
FTDI: Failing to load libMPSSE.dll
Solved!
First the #ifdef _MSC_VER is absolutely wrong.
_MSC_VER is if you are using a Microsoft compiler or not, the code difference you have is dealing with the fact that by default when using a Microsoft Compiler, the UNICODE define is active. You should never attempt to work around compiler problems by depending on only loosely related precompiler defines. If you compile this program with a Microsoft compiler where you have UNICODE undefined this will cause problems.
More correct would be something like
#ifdef _WIN32
h_libMPSSE = LoadLibrary(_T"libMPSSE.dll");
#else
h_libMPSSE = dlopen("libMPSSE.so");
#endif
The _T expands to an L if UNICODE is defined, and to nothing if it is not defined. And LoadLibrary expands to LoadLibraryW with UNICODE defined and LoadLibraryA with UNICODE not defined. This is how Microsoft has designed these macros to work, and will basically cause the C compiler to see the equivalent of this:
#ifdef _WIN32
#ifdef UNICODE
h_libMPSSE = LoadLibraryW(L"libMPSSE.dll");
#else
h_libMPSSE = LoadLibraryA("libMPSSE.dll");
#endif
#else
h_libMPSSE = dlopen("libMPSSE.so");
#endifYour code without UNICODE defined, will call LoadLibraryA() with a Unicode string. That obviously can not result in a valid path for the LoadLibraryA() function as the Unicode string will be interpreted as an ASCII string and converted to Unicode before being passed to the relevant Windows kernel APIs. Basically this will result in an Unicode string only containing the first character of the path being passed to the kernel API. And LoadLibrary("l") obviously can not point to a valid DLL at all.
Also the else case in your code is at least questionable. Any compiler claiming to support Win32 programming should come with the according Windows SDK headers and therefore be able to expand the standard Windows Unicode macro magic, or it is a very useless Win32 compiler.
Have you installed the Windows SDK support for LabWindows/CVI? Although I think LabWindows won't support Unicode anyhow, it didn't last I really used it, which is many years ago.
But since you say that even the LoadLibraryA() call returns NULL, this basically means that Windows was not able to load the libMPSSE.dll. Have you installed the FTDI drivers properly?
Windows will only search for DLLs loaded with a relative path in a few specific locations. The first is the process executable directory which is where your LabWindows CVI created executable is located. The other meaningful location is in the <System> directory, usually "C:\Windows\SysWOW64" for a 32-bit application and "C:\Windows\System32" for a 64-bit application. Another location it will search is any directory mentioned in the PATH environment variable. If your DLL is located anywhere else you have to pass the full path to LoadLibrary() or Windows will not find it. Also libMPSSE.dll is only a higher level library that depends and requires the FTDI low level d2xx driver library to be installed as well on your computer, which will usually be installed in the according <system> directory.
Sorry, just realised I'm not sure whether that Windows 8 machine is running Windows SDK version 6.3 or 8.1...
Above is a screenshot of the relevant registry entry.
Well, don't get to involved with the SDK. It's mostly about the UNICODE define only and I don't think LabWindows/CVI even supports Unicode, so it is a pretty moot point.
However, when you just specify the DLL name to LoadLibrary() the DLL needs to either be in the same directory as where your EXE file is, so not alongside the sources but besides your EXE file, or it can also be in the <System> directory. You also can add the directory where your DLL resides, to the PATH environment variable but that it very much MS-DOS time.
There is likely something else going on than what you think.
The source code folder of an application is totally irrelevant for Windows to find a DLL when you pass a relative path to the LoadLibrary() function. Windows has only a few locations it will search for such a DLL.
1) check for the DLL name in memory
2) check in the process directory (where the executable for your current process is located)
3) check in the <system> directory
4) check in the <windows> directory
5) check in any directory that is contained in the PATH environment variable
Depending on Windows version and flags configured for the DLL loader though there is one other directory that is searched either early on or late in this list which is called the <current directory>. This is IMHO a stupid idea to use as the <current directory> is a process global variable that is initialized by default to the process directory, unless the CreateProcess() call received a specific default directory to use and this can also be changed with a Windows API call. But the most stupid thing in Windows is that the File Dialog also changes this directory to whatever directory it was in whenever it is dismissed by the user acknowledging the file or directory selection.
So when your last file dialog in LabWindows/CVI was selecting a file (no matter what type of file) in the same directory as your DLL is located, the LoadLibrary("libMPSSE.dll") call will happily succeed. If you selected a file in a different directory (or none at all, since then the current directory will still be set to the directory where your cvi.exe is located), it won't!
Another option might of course be that someone "smart" added that directory to the PATH environment variable on your Windows 8 machine and everything worked magically. Until some other person comes along and installs everything on a different machine and nothing works anymore.
Possible solution are twofold:
1) Keep using your relative DLL path but don't rely on Windows finding it in any other location than one of the 5 in above list.
2) Build an absolute path to the DLL where you know you placed it and pass that to LoadLibrary().
