From: "Alexandre Julliard" <[EMAIL PROTECTED]>
> 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.
This is indeed a very good point. And to be honest, it kindda kills
my proposal. However, at least the base DLLs (kernel, gui, user) do
not call in other DLLs so...
> 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).
My main concern are memory allocations. As I was saying, we do not even
try do deal with OOM situations properly.
How we do the conversions, and how many tables we have,
is an implementation detail -- we can worry about this later.
--
Dimi.
