Re: [xml] LoadLibrary needs to be LoadLibraryA

[Roumen Petrov <bugtrack roumenpetrov info>]

Darko Miletic wrote:
> 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


On 9x LoadLibraryW should trigger error "function is not supported".
On NT LoadLibraryW on fat system should try to convert  UCS-2LE  
sequence of bytes to 8-bit depending from user locale. If system switch 
to a new but incompatible locale, file(library) cannot be found, more 
since in this case convertion UCS-2LE->new locale will fail.
The short file name/path may not help to resolve problem since the same 
file/path (at application level) name is stored with different name on 
file system (fat or nfts) and as result short name will differ too.



What about libxml (only for win32) to define xxxA and xxxW functions always.
First (xxxA) to use LoadLibraryA and  second xxxW - LoadLibraryW.

Also for binary compatibility function xxx should exist too and to use 
LoadLibraryA, i.e. to call xxxA.
The header can define xxx to xxxW if UNICODE is defined otherwise - xxxA.


Roumen