"Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=" wrote:
I have only a doubt:
- Is it possible to implement the ANSI version by converting to unicode then calling the wide version, rather than duplicate it?
How can I convert an ansi string to a unicode one and reverse? So I can redo the patch with the calls :)
Typically you use MultiByteToWideChar() for any input strings and then WideCharToMultiByte() for possible output strings. You can look at shlwapi/path.c and other files in there to see how this is usually done.
Depending on the place where you do it, it might be preferable to use dynamically allocated buffers instead of using stack space as Wine is already using quite a lot of stack. Principle:
WCHAR *textW; INT countW = MultiByteToWideChar(CP_ACP, 0, textA, -1, NULL, 0); if((textW = HeapAlloc(GetProcessHeap(), 0, countW * sizeof(WCHAR)))) { MultiByteToWideChar(CP_ACP, 0, textA, -1, textW, countW);
/* Do the Widechar call */
HeapFree(GetProcessHeap(), 0, textW); }
Rolf Kalbermatter
Le lun 06/09/2004 à 14:04, Rolf Kalbermatter a écrit :
"Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=" wrote:
I have only a doubt:
- Is it possible to implement the ANSI version by converting to unicode then calling the wide version, rather than duplicate it?
How can I convert an ansi string to a unicode one and reverse? So I can redo the patch with the calls :)
Typically you use MultiByteToWideChar() for any input strings and then WideCharToMultiByte() for possible output strings. You can look at shlwapi/path.c and other files in there to see how this is usually done.
Depending on the place where you do it, it might be preferable to use dynamically allocated buffers instead of using stack space as Wine is already using quite a lot of stack. Principle:
WCHAR *textW; INT countW = MultiByteToWideChar(CP_ACP, 0, textA, -1, NULL, 0); if((textW = HeapAlloc(GetProcessHeap(), 0, countW * sizeof(WCHAR)))) { MultiByteToWideChar(CP_ACP, 0, textA, -1, textW, countW); /* Do the Widechar call */ HeapFree(GetProcessHeap(), 0, textW); }
Is it best to use MultiByteToWideChar() or RtlCreateUnicodeStringFromAsciiz()? I find that latter function much easier to use (no need to mess with string lengths, etc.).
Vincent
Vincent Béron wrote:
Is it best to use MultiByteToWideChar() or RtlCreateUnicodeStringFromAsciiz()? I find that latter function much easier to use (no need to mess with string lengths, etc.).
iirc, RtlCreateUnicodeStringFromAsciiz has a limitation due to use of the UNICODE_STRING structure - it can only deal with strings up to 2^16-1 bytes in length. Input to edit controls and other strings may be longer than that, so be careful where you use it.
Mike
iirc, RtlCreateUnicodeStringFromAsciiz has a limitation due to use of the UNICODE_STRING structure - it can only deal with strings up to 2^16-1 bytes in length. Input to edit controls and other strings may be longer than that, so be careful where you use it.
It also makes our DLLs depend on ntdll so we can't drop them into a Win9x install, I guess.
Not sure if we care about that though.
Vincent Béron wrote:
Is it best to use MultiByteToWideChar() or RtlCreateUnicodeStringFromAsciiz()? I find that latter function much easier to use (no need to mess with string lengths, etc.).
Well for system DLLs this shouldn't be a problem. But for other DLLs this might create an undiserable dependency on ntdll.dll and this way cause additional problems for mixed builtin/native DLL setups.
Rolf Kalbermatter
-
Mike Hearn -
Mike McCormack -
Rolf Kalbermatter -
Vincent Béron