"Shachar Shemesh" iglu-web@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...