The ANSI C has not suggested to use wchar_t. For Unicode UCS-2, we should use
a user-defined type. IBM ULS uses the unichar as the 16-bit unsigned short
for UCS-2. That should be the approach.
wchar_t is not intended to be a published data type as char or byte.
Oracle has ported our software to more platforms than any vendors. I know the
pain and agree with you.
40P-972 Phone: (415) 506-6954
Manager, Server Globalization Technology Fax: (415) 506-7225
Languages and Relational Technology Email: email@example.com
attached mail follows:
At 05:22 PM 12/17/96 -0800, you wrote:
>You are correct in saying that secondary apps need to be in Unicode. But as a
>developer of such secondary apps on Win95/WinNT, I find it frustrating that
>sdk forces you to go to either MBCS or UNICODE at compile time.
I couldn't agree with you more. I'm deeply mired in attempting to build
a cross-platform product (win,mac,8 unix flavors,qnx,os/9,psos,...) written
primarily in C and consistently use UCS-2 character data throughout. The
most significant problems I face are:
1. lack of compiler support for wchar_t (and wide string literals in
particular); or if a compiler supports wchar_t, then lack of control
over whether 16-bits or 32-bits are used.
2. lack of standard runtime support for wchar_t signatures; i.e., there
needs to be a standard set of wcs entry points for string.h, ctype.h,
stdlib.h, stdio.h, etc.
3. inconsistent API support for wchar_t, here I'm thinking of WIN32 in
its three primary flavors (NT, WIN95, WIN32S), or even no support (MacOS)
or extremely little support (X Window System).
4. lack of support in IDEs for wchar_t string display (MSVC is ok, others
I don't even need to go into the problems with fonts and font technologies
(GX or TT Open? or TrueDoc or ???).
As a practical matter, I'd certainly like to find a way to put pressure
on tool and language and os vendors to get their act together in this
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:33 EDT