Re: [xml] LoadLibrary needs to be LoadLibraryA

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;
if (FormatMessage(
   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 {
  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 ( 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:

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]