I doubt the change I made to be able to use the wide versions of functions (when UNICODE is defined) actually fixed anything besides compiling on systems that don't have an ANSI method available. (It'd be cool if it did though!).
UTF-8 (which is passed around using char *) is still Unicode, even though it represents many characters (ASCII) with a single byte. My change just converted char * (which I assume to be UTF-8) to wchar_t * (UTF-16) before invoking SSPI functions. I think there is no change in the range of characters that are represented with the conversion. Does Windows do anything differently on the backend when you use the wide version of one of these functions? Mark -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Stenberg Sent: Wednesday, June 20, 2012 7:20 AM To: libcurl development Subject: Re: Unicode and NTLM On Wed, 20 Jun 2012, Christian Hägele wrote: > recently SSPI support was added to libcurl on windows I just checked. We added that in 2005... ;-) > and additional to that Mark Salisbury added support for the > wide-character-functions on Windows. > > I looked through the code a bit and it seems like that fixes the > limitation curl had that no Unicode user names and passwords are > supported. But this is only true if SSPI is used. > > My question is if that also fixes Known Bug 75? > (http://curl.haxx.se/docs/knownbugs.html) > If not, could the same technique be used to address that issue? Can you just test and figure it out? And if it does fix it, it is still only for SSPI-enabled builds so known bug 75 would still remain - just need a little update to clarify for which builds it doesn't apply! -- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
