From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri Jan 16 2004 - 14:49:54 EST
From: "Michael (michka) Kaplan" <michka@trigeminal.com>
> From: "Philippe Verdy" <verdy_p@wanadoo.fr>
>
> > Exactly. However the conversion to UTF-8 from UTF-16 (the Windows
> > "WideChar" encoding used in the Win32 Unicode API) is supported natively
> > in MultibyteToWideChar() as if it was a SBCD/DBCS character set, even on
> > Windows 95.
>
> This is incorrect. UTF-8 support did not exist until Win98 for the Win9x
> family, and did not exist until NT4 for the WinNT family.
Even after system updates? It's true that all my tests showed the
MultiByteToWideChar() and reverse conversion working with the UTF-8
"codepage", but it's also true that I had support code to use direction
conversion between UTF-16 and UTF-8, so this was not a problem, as long as
Win95 supported the conversion of OEMCP and ACP codepages, needed to support
the LFN extension in FAT and later in FAT32. I also avoided using this API
with some simple codepages (like Windows-1252 and CP850 easily implemented
with a very small table) whose support were still needed on non Western
European versions of Windows.
You're right for NT 3.5x, but I never needed to support it as NT4 was my
minimum since long when I wrote this support code. I have never had any such
problem with UTF-8 on Windows 95, or nobody asked me about it (probably
because we needed other support libraries which required installing system
updates, or because this system support was installed with Internet
Explorer; I have no clue for the old retail version of Windows 95 which had
many other networking problems needing such system updates, should it be
only for security reasons and to solve instability problems in the initial
kernel).
This archive was generated by hypermail 2.1.5 : Fri Jan 16 2004 - 15:27:34 EST