Re: [xml] LoadLibrary needs to be LoadLibraryA

[Darko Miletic <darko uvcms com>]

Roumen Petrov wrote:
> If file system is fatNN can we use LoadLibraryW ?

Yes. Difference between so called unicode and ansi functions is 
primarily in input/output string parameters.
> If file is on network file system how to detect at run time that 
> LoadLibraryW will succeed ?
>   
You detect any problem by checking result value of API call and by 
calling GetLastError() API.

Like in these two functions

#include <windows.h>
#include <string>
#include <iostream>

std::string GetSysMsg(DWORD err) {
std::string result;
LPVOID lpMsgBuf = NULL;
if (FormatMessage(
   FORMAT_MESSAGE_ALLOCATE_BUFFER |
   FORMAT_MESSAGE_FROM_SYSTEM |
   FORMAT_MESSAGE_IGNORE_INSERTS,
   NULL,
   err,
   MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
   reinterpret_cast<LPSTR>(&lpMsgBuf),
   0U,
   NULL ))
{
result = reinterpret_cast<LPSTR>(lpMsgBuf);
LocalFree( lpMsgBuf );
lpMsgBuf = NULL;
}
return result;
}

bool CheckLoadLibrary(const std::wstring &filename) {
HMODULE mod = LoadLibraryW(filename.c_str());
bool result = (NULL != mod);
if (!result) {
  DWORD err = GetLastError();
  std::cerr << GetSysMsg(err) << std::endl;
} else {
  FreeLibrary(mod);
  mod = NULL;
}
return result;
}

> And what about OS like 95x ? Did Microsoft Windows 95x support 
> unicode/wchar_t ?
>   
win 9x has very small subset of unicode API implemented and rest are 
just A versions that accept common char*. To support unicode API on 
these system it is possible to use MSLU 
(http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx).
There is a reason why it would be convenient to pass windows version of 
libxml2 to unicode API. All Windows versions from Windows NT are 
internaly UNICODE, so their native API are with W extension. When you 
call Ansi API on UNICODE OS it internaly converts common string to 
unicode and than call's unicode version of API. Since win9x line is 
basically dead and 64-bit is already with us there is no much reason to 
keep non-unicode version floating.
> "modules located in pathes containing unicode characters" - I cannot 
> understand this.
>   
This basically means LoadLibraryW can load dll's that are located in 
path that may contain chinese, russian or whatever non-latin characters 
and this is because it's input parameter is unicode string.

> If LoadLibraryA is called with file name in "short format" (microsoft 
> terminology) should expect to succeed ?
>
>   
If the path is correct it will. That goes for the LoadLibraryW too.
> Many questions but well designed OS should care for this transparently 
> to the user.
>   
There is a very good reason why are things as they are on windows. You 
can find digest version on this url:
http://www.jorendorff.com/articles/unicode/windows.html

--
Darko Miletic