"Rein Klazes" <[EMAIL PROTECTED]> wrote:
> I am planning to create a patch that fixes MultiByteToWideChar and
> WideCharToMultiByte, as well as removing the symbol code page from the
> code page table.
Please don't forget to remove the special case for CP_SYMBOL
in dlls/kernel/locale.c,IsValidCod
On Thu, 15 Jan 2004 19:24:25 +0800, you wrote:
>
> > > Apparently Windows uses something different. Probably we have to change
> > > our internal map for Symbol encoding
> >
> > I will try a few other Windows versions first. It looks to me that
> > Symbol encoding is not a real encoding at all
"Rein Klazes" <[EMAIL PROTECTED]> wrote:
> [?? Probable Spam]
>
> Your spam filter needs to be educated about wine-devel ;-)
That's not my spam filter (it behaves differently), some host in
e-mail chain marks every e-mail from you on this list with that
addition in the subject line.
> > Appar
On Thu, 15 Jan 2004 16:20:28 +0800, you wrote:
[?? Probable Spam]
Your spam filter needs to be educated about wine-devel ;-)
> >
> > Is there any reason why in this case MultiByteToWideChar should not do
> > w = c + 0xf000 ?
>
> Wine is using the following source for its Symbol to unicode m
"Rein Klazes" <[EMAIL PROTECTED]> wrote:
> Wine's implementation of MultiByteToWideChar() does something quite
> complicated based on standard unicode tables and returns Unicode
> characters in all kind of ranges.
>
> The loop above is basically what Win2K's charmap.exe does. Of course it
> does
Hi,
Trying to fix a problem with Win2K's charmap.exe, I have a question for
the unicode experts.
If I convert character code's 32 to 255 using codepage SYMBOL on a Win2K
system, like in this snippet:
char c;WCHAR w;
for( c = 32; c; c++)
MultiByteToWideChar(CP_SYMBOL,0,&c,1,&w,1);
I get that
