Re: [xml] LoadLibrary needs to be LoadLibraryA

[Roumen Petrov]

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_castLPSTR(lpMsgBuf),
0U,
NULL ))
 {
 result = reinterpret_castLPSTR(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

___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Cory Nelson]

On Sat, Feb 23, 2008 at 7:58 AM, Roumen Petrov
[EMAIL PROTECTED] wrote:

  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.


FAT supports UTF-16 in long filenames - only short names are encoded
in an ANSI codepage.  NT has used UTF-16 (as opposed to UCS-2) since
2000.


  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.


This would be nice, but is a breaking change.

-- 
Cory Nelson
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Roumen Petrov]

  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.
 
 This would be nice, but is a breaking change
Only if new application build with new library is run with old library.

Roumen

___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Darko Miletic]

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_castLPSTR(lpMsgBuf),
0U,
NULL ))
{
result = reinterpret_castLPSTR(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


___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Daniel Veillard]

On Wed, Feb 20, 2008 at 08:01:43AM +0100, 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.

  I have no idea what the difference is between LoadLibrary, LoadLibraryA
and LoadLibraryW ...


 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

  Okay, I can't test this, someone comes with a complete patch and I can
review and apply it,

  thanks,

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard  | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Jungshik Shin]

2008/2/19, Roland Schwingel [EMAIL PROTECTED]:


 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.



Yeah, I thought about suggesting that, but didn't because it was not clear
to me whether the argument is the full path or just a leaf filename. I have
done exactly the same thing in another project  and I fully agree with you
that we'd better do it.  It's not a perfect but a 'work-most-of-time' method
(and, certainly  better than just calling  LoadLibraryA).

I'll make a new patch.

Jungshik

Roland




-- 
Îñţérñåţîöñåļîžåţîöñ 신정식, 申政湜
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Roumen Petrov]

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

___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

[xml] LoadLibrary needs to be LoadLibraryA

[Jungshik Shin]

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:

-Cut-Here

--- xmlmodule.c.old
+++ xmlmodule.c
@@ -300,7 +300,7 @@
 static void *
 xmlModulePlatformOpen(const char *name)
 {
-return LoadLibraryA(name);
+return LoadLibrary(name);
 }

--

Thank you,

Jungshik
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Jungshik Shin]

2008/2/19, Jungshik Shin [EMAIL PROTECTED]:

 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:


 -Cut-Here

 --- xmlmodule.c.old
 +++ xmlmodule.c
 @@ -300,7 +300,7 @@
  static void *
  xmlModulePlatformOpen(const char *name)
  {
 -return LoadLibraryA(name);
 +return LoadLibrary(name);
  }


 --



Ooops. I took the patch backward. It should read


--- xmlmodule.c.old
+++ xmlmodule.c
@@ -300,7 +300,7 @@
 static void *
 xmlModulePlatformOpen(const char *name)
 {
-return LoadLibrary(name);
+return LoadLibraryA(name);
 }

-

By explicitly calling LoadLibraryA, we can avoid a compilation error whether
UNICODE is defined or not.

Jungshik

Thank you,


 Jungshik






-- 
Îñţérñåţîöñåļîžåţîöñ 신정식, 申政湜
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml

Re: [xml] LoadLibrary needs to be LoadLibraryA

[Roland Schwingel]

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

___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml