::LoadLibrary not working on my Windows XP machine

[WhatNow46]

I wrote a C++ program way back on Windows 95 with Visual C++ 4.0/6.0 compilers long ago.

I have now upgraded the old project .mdp files to Visual Studio 8.0's .sln files. That process went very smoothly as there is a converter built in to the compiler.

Now, on my Vista machine, the program runs fine. It's an executable and calls one other dll. No problem there.

But on the XP machine, a call I make to LoadLibrary((LPCWSTR) "MSVCRT.dll") fails with error code 126 (more or less this is file/path not found). Now there are about a dozen or so versions of that dll on my XP machine, in addition to the usual one in C:\WINDOWS\system32. Perhaps of the 12, 4 or 5 have different dates. Well anyway, I tried running ProcessMonitor, and I 've tried other stuff, but to no avail.

Does anyone have a huge, grand strategy that I can take to resolve this issue. My ultimate purpose is just to do this kind of thing (and this works fine on my Vista machine which also has Visual Studio 5.0/8.0, likewise my XP machine setup).

So ultimately, it's, provided I've gotten a nice m_hDll_ handle from the LoadLibrary call:
pFun = (pfMyFunc)::GetProcAddress(m_hDll_, "sin");

I just cannot get the LoadLibrary call to work on my XP machine. Any help appreciated.
Thank you.
WhatNow46

[VictorN]

But on the XP machine, a call I make to LoadLibrary((LPCWSTR) "MSVCRT.dll") fails with error code 126 (more or less this is file/path not found).

Why do you cast LPCSTR pointer to LPCWSTR? It is a wrong casting. And you do NOT need any casting here at all (I presume your build is an ANSI one)

Now there are about a dozen or so versions of that dll on my XP machine, in addition to the usual one in C:\WINDOWS\system32. Perhaps of the 12, 4 or 5 have different dates.

The you have to pass inn the full path name of the dll you want to load!

[WhatNow46]

Here is the output in Visual Studio (I've substituted MyApp for my application and ADll.dll for a dll that gets loaded.
I've tried LoadLibrary on the 9.0 stuff, also to no avail.

'MyApp': Loaded 'C:\MyAppD.exe', Symbols loaded.
'MyApp': Loaded 'C:\WINDOWS\system32\ntdll.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\kernel32.dll'
'MyApp': Loaded 'C:\ADll.dll', Symbols loaded.
'MyApp': Loaded 'C:\WINDOWS\system32\user32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\gdi32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\shlwapi.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\advapi32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\rpcrt4.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\secur32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\msvcrt.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\oleacc.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\msvcp60.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\ole32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\oleaut32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\winspool.drv'
'MyApp': Loaded 'C:\WINDOWS\system32\comdlg32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\comctl32.dll'
'MyApp': Loaded 'C:\WINDOWS\system32\shell32.dll'
'MyApp': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcr90d.dll', Symbols loaded.
'MyApp': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcp90d.dll', Symbols loaded.
'MyApp': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll'

I wrote a C++ program way back on Windows 95 with Visual C++ 4.0/6.0 compilers long ago.

I have now upgraded the old project .mdp files to Visual Studio 8.0's .sln files. That process went very smoothly as there is a converter built in to the compiler.

Now, on my Vista machine, the program runs fine. It's an executable and calls one other dll. No problem there.

But on the XP machine, a call I make to LoadLibrary((LPCWSTR) "MSVCRT.dll") fails with error code 126 (more or less this is file/path not found). Now there are about a dozen or so versions of that dll on my XP machine, in addition to the usual one in C:\WINDOWS\system32. Perhaps of the 12, 4 or 5 have different dates. Well anyway, I tried running ProcessMonitor, and I 've tried other stuff, but to no avail.

Does anyone have a huge, grand strategy that I can take to resolve this issue. My ultimate purpose is just to do this kind of thing (and this works fine on my Vista machine which also has Visual Studio 5.0/8.0, likewise my XP machine setup).

So ultimately, it's, provided I've gotten a nice m_hDll_ handle from the LoadLibrary call:
pFun = (pfMyFunc)::GetProcAddress(m_hDll_, "sin");

I just cannot get the LoadLibrary call to work on my XP machine. Any help appreciated.
Thank you.
WhatNow46

[WhatNow46]

Hi Victor, my latest run looks like this, and it gives the same null handle and error 126. The compiler is mapping LoadLibrary to LoadLibraryW so I must use the cast.

m_hDll_ = ::LoadLibrary((LPCWSTR) "C:\\WINDOWS\\SYSTEM32\\MSVCRT.dll");

[VictorN]

Hi Victor, my latest run looks like this, and it gives the same null handle and error 126. The compiler is mapping LoadLibrary to LoadLibraryW so I must use the cast.

m_hDll_ = ::LoadLibrary((LPCWSTR) "C:\\WINDOWS\\SYSTEM32\\MSVCRT.dll");

No, you must not use such a cast. It is just a fake and you fake yourself!
If your build is a UNICODE one then you have to pass in a UNICODE string:

m_hDll_ = ::LoadLibrary((LPCWSTR) L"C:\\WINDOWS\\SYSTEM32\\MSVCRT.dll");

or better would be using _T() macro to make your code both UNICODE and ANSI aware:

m_hDll_ = ::LoadLibrary((LPCWSTR) _T("C:\\WINDOWS\\SYSTEM32\\MSVCRT.dll"));

[WhatNow46]

Thank you so much Victor, for solving the problem. I am too lax with string knowledge. The one with the L
worked. The compiler did not recognize the one with the _T macro. I don't know why it worked on my Vista
machine. Strange.

Problem solved - I now get a valid handle, thank you.

[VictorN]

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx
http://forums.codeguru.com/showthrea...acro-Confusion.

[Paul McKenzie]

Thank you so much Victor, for solving the problem. I am too lax with string knowledge.

First and formemost, casting one string type to another is not converting the string. What you assumed was happening (which wasn't happening) is that the cast was magically converting an ANSI string into a Unicode or wide string.

To convert from one string to another requires you to call functions such as MultiByteToWideChar or WideCharToMultiByte. Doing simple 'C' style casts on string-literals doesn't convert anything.

Also, why did you apply the cast to begin with? Was it to "shut the compiler up"? If so, that is a huge mistake to make, regardless of what you're trying to accomplish. If the compiler gives you an error that "types are not compatible" or similar error, the last thing you should even consider doing is to "cast away the error". The compiler is trying to tell you something very important, and ignoring it by casting is done at your own peril.

Regards,

Paul McKenzie

[WhatNow46]

Wow, the original project had /D "WIN32" /D "_DEBUG" /D "CONSOLE" ... and other stuff while the converted project
on my XP machine had:

/D "WIN32" /D "_DEBUG" /D "CONSOLE" /D "_UNICODE" ... and other stuff hence my sudden problem with the build. Had I swiped away the UNICODE I would have been fine.

In response to Paul, yes a literal is a literal and a conversion of something is a conversion and requires a call to the runtime functions you mention. I was just trying to get this thing to compile - should have realized that _T/_TEXT are the most general and will compile to the correct thing depending on _UNICODE or not being present in the build flags.
I can use _L if I already know that I want to build unicode.

http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx
The above should get me going and will also help me when I need to count chars and when I need to use the sprintf_s, fopen_s, and _wfopen_s types of functions.

I think I will just go back and change all my code to UNICODE - with the justification that I may want to internationalize my code right away. If I did NOT need to internationalize, then I guess I could leave a lot out of it by changing the compile flags to the non-unicode. But if I use the _T/_TEXT macros, I should be able to go either way (hopefully).

Thanks for the help - it shouldn't take me too long to pretty up all of my strings - whether MFC CString or old-style TCHAR/char.

[WhatNow46]

One slight challenge comes to mind right away. My code uses hash tables - I hash strings such as sin, cos, fft, or whatever. Suppose I want to hash the Japanese versions of these words - I think I might just have to have a rule for now that functions are all called in English!

[WhatNow46]

I added #include <tchar.h> just as a guess and now I can use _T("astring") around my strings to get either way - I didn't want to leave Viktor confused why I had used L for the compile-time literal macro. I simply hadn't known where that macro was defined. The help in Visual Studio 2008 is not as under my mastery as in the old VC4.0 - VC6.0 days.