Re: [xml] LoadLibrary needs to be LoadLibraryA



Roland Schwingel wrote:
Hi...

When I tried to compile libxml on Windows along with my application that
is built with 'UNICODE' defined (i.e. as a Unicode
application rather than as an "ANSI" application), I came across a
problem in xmlmodule.c.
With UNICODE defined, LoadLibrary is resolved to LoadLibraryW which
expects to get 'const wchar_t*' rather than 'const char*'.
To avoid the problem, we have to use LoadLibraryA explicitly.

Below is my trivial patch:
[...]

I agree that the explicitely stating LoadLibraryA or LoadLibraryW would be best. But IMHO LoadLibraryA would be a bad idea. This would not allow to load modules
located in pathes containing unicode characters.

IMHO interpreting the path as utf-8 and then converting it to wchar would be better and then trying LoadLibraryW(). If the path cannot be converted or LoadLibraryW() fails a second attempt can be made using the original argument of the xmlModulePlatformOpen function passed to LoadLibraryA(). For the utf-8 -> wchar thingy there is already code
in xmlIO.c doing these things it should be recycled here.

Roland

First why libxml is compiled with -DUNICODE  ?
If final application is unicode (in microsoft terminology) what is problem to work with library compiled without UNICODE flag to be defined ?

Please could identify all external function by libxml libraries that this definition impact.
Show apply similar modification to them ?
May be proposed patch is enough.

If file system is fatNN can we use LoadLibraryW ?
If file is on network file system how to detect at run time that LoadLibraryW will succeed ? And what about OS like 95x ? Did Microsoft Windows 95x support unicode/wchar_t ? May be on those OS-es function LoadLibraryW exist in kerne32.dll(?) but I guess that it is just a stub.

"modules located in pathes containing unicode characters" - I cannot understand this. If LoadLibraryA is called with file name in "short format" (microsoft terminology) should expect to succeed ?

Many questions but well designed OS should care for this transparently to the user.

Roumen




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