Francois Gouget wrote:
Clumsy but this is the only way.
(for Winelib we play tricks with WINE_UNICODE_TEXT but these are not perfect and must not be used in Wine. That's why they are in an #ifndef __WINE__ anyway)
didn't you just spot a serious problem with winelib?
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.
Then again, rebutting my own claims, this will break binary compatibility between data files generated with winelib applications and windows applications.
Then again, rebutting my own rebuttal, binary compatiblity will not happen without explicit winelib users effort anyways, because of endianity issues.
So, after having proven my own claims null and invalid, what are we left with?
Shachar