Re: Wine Developer Cheatsheet, v1

[Rolf Kalbermatter]

"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

Wine Developer Cheatsheet, v1

[Vincent Béron]

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

Wine Developer Cheatsheet, v1

[Mike McCormack]

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

Wine Developer Cheatsheet, v1

[Mike Hearn]

> 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.

Wine Developer Cheatsheet, v1

[Rolf Kalbermatter]

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