> "Dimitrie O. Paun" <dpaunÉe-solutions.com> writes:
>
> > In any case, we need some guidelines on how to deal with Unicode
> > in a consistent manner. The current situation is a mess of 1 & 2
> > which will need cleanup. Alexandre?
>
> The long term solution is clearly 2 (Windows Unicode format
> internally). It's the only viable solution to remain reasonably
> compatible with Windows dlls.
Alexandre, can you describe what you dislike so much about _my_ solution?
Your argument that the Wine binary is large enough as it is,
is not very persuasive even though, I do admit you have a point.
I think having a cleaner, more maintainable and faster solution
is worth the somewhat larger binaries. Note that it doesn't
hurt embedded system, my solution allows an ASCII only Wine.
> With your solution you'll need to convert encodings on every cross-dll
> call, because you might be calling a Windows dll that doesn't support
> your internal functions.
True, I didn't realize that. But then I don't think the cross-dll
cases are worth optimizing anyway. But you are right with that
solution we must be careful which functions call cross dlls.
Fortunately I think winapi_check easily can be taught to check that.
> Converting A->W->U for file I/O may seem wasteful but it isn't really
> since we need to support code pages; you can only do A->U directly for
> 7-bit ascii which is not enough. And supporting code pages without the
> Unicode step means NÜ2 conversion tables instead of 2*N (where N is
> the number of code pages).
It is not the double conversion that seems wasteful it the extra
memory allocations. Of course the actual conversion can/will be done
in two steps. In addition delaying it as much as possible
makes it possible to optimize the 7-bit ASCII -> UTF8 case by
checking for a 7-bit only string it cost close to nothing compared
to the cost of converting. Other common cases might also be optimized.
Now I still don't like Dimtrie's solution, but it is more
a gut feeling than anything else.
