Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

[Dmitry Timoshkov]

"Shachar Shemesh" <iglu-web at sun.consumer.org.il> wrote:

> As far as I can see, the only solution will be to formally seperate wine 
> from winelib in aims. Wine should support UTF-16, as it handles binaries 
> that use UTF-16. Winelib should support UTF-32, as that's what the 
> compilers support. We do nasty workarounds for the wine sources, but do 
> not require nasty workarounds from the winelib users.

Personally I do not consider using explicit unicode strings such as 'f','o',o',0
as nasty workarounds. It's a quite acceptable approach.

For the record: until the very recent time Unicode standard had only 65536
defined characters, i.e. UTF16 covered most of the applications requirements.
Nowadays it has slightly more, but they are not likely to be used too wide,
and there are surrogate pairs for 16-bit unicode.

And what's wrong with using Wine internal unicode library and huge number
of Win32 APIs dealing with wide (W) characters? As far as I understand it,
if Wine would wait till Linux community creates a working unicode implementation
we would still had nothing working at hands. Especially taking into account
a more wide spreading idea of using UTF8 (i.e. 8-bit unicode) instead of
16 or 32 bit version. It's ugly IMO: and performance is the very first argument.

Not to sound offensively, but I don't know (at least) any of the Linux
libraries (except glibc) that has (only) unicode APIs, or require usage of 32-bit
unicode from client applications, or has a slight idea about code pages.
It seems that everyone invents its own wheel, even XFree86 guys invent their
own internal unicode support...

-- 
Dmitry.